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

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.

-- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com _______________________________________________ keycloak-dev mailing list keycloak-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev