Re: [keycloak-dev] ID Token claims in Access Token and Refresh Token

----- Original Message ----- > From: "Bill Burke" <bburke(a)redhat.com&gt; > To: keycloak-dev(a)lists.jboss.org > Sent: Wednesday, 3 December, 2014 3:15:05 PM > Subject: Re: [keycloak-dev] ID Token claims in Access Token and Refresh Token > > > > On 12/3/2014 9:01 AM, Stian Thorgersen wrote: >> >> >> ----- Original Message ----- >>> From: "Marek Posolda" <mposolda(a)redhat.com&gt; >>> To: "Stian Thorgersen" <stian(a)redhat.com&gt;, "keycloak dev" >>> <keycloak-dev(a)lists.jboss.org&gt; >>> Sent: Wednesday, 3 December, 2014 2:39:14 PM >>> Subject: Re: [keycloak-dev] ID Token claims in Access Token and Refresh >>> Token >>> >>> The one reason I can think of is bearer authentication. Currently we are >>> doing it with accessToken and if we remove claims from accessToken, then >>> bearer app won't be able to easily retrieve informations about user >>> without sending another request to UserInfo endpoint. I agree that >>> having userInfo in all tokens doesn't makes much sense, but not sure how >>> to improve it. Some options: >>> 1) Remove IDToken (but I guess we need it for OpenID connect support, >>> right?) >>> 2) Send both accessToken+idToken to bearer auth (but there is more >>> network bandwith then) >>> 3) Allow bearer apps to retrieve data from UserInfo, but that's another >>> request to KC needed then >>> 4) Keep as it is. >> >> It would reduce the size of the access token. Could be by quite a few bytes >> when there's more and more claims added. Question is how does REST >> endpoints expect to retrieve these claims, and how many REST endpoints >> actually use the claims at all? Not sure how you would send the token >> separately as it's expected the authorization header contains the bearer >> token only. >> > > You can currently control per client what exactly goes in the access token. That doesn't really help. A front-end app may for example want the full profile, but if it does that means the token it sends with all requests is bigger as well.