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

From: "Bill Burke" <bburke(a)redhat.com&gt; To: "Stian Thorgersen" <stian(a)redhat.com&gt; Cc: keycloak-dev(a)lists.jboss.org Sent: Wednesday, 3 December, 2014 8:00:51 PM Subject: Re: [keycloak-dev] ID Token claims in Access Token and Refresh Token On 12/3/2014 9:34 AM, Stian Thorgersen wrote: > > > ----- 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. > And that matters because? You're talking about bytes here...not kilobytes, not megabytes. Really, this is a non-issue. Isn't there other things to work on?

-- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com