I wonder if we can have it configurable if IDToken is sent or not? The
only reason to have it enabled is for specs compliance afaik, but for
Keycloak itself it doesn't need to be needed anywhere as data are on
access token. Also removing user claims from refresh token makes sense
anyway to me. It needs to keep only stuff, which is needed by Keycloak
to refresh new set of tokens (like sessionId, expiration etc).
On 3.12.2014 14:39, Marek Posolda wrote:
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.
For UserInfo we have endpoint on AccountManagement, which is used for
example by keycloak.js (Keycloak.loadUserProfile). Or do you mean
something different?
Marek
On 3.12.2014 08:55, Stian Thorgersen wrote:
> As AccessToken and RefreshToken extends IDToken they contain the ID Token claims. If
I've read the spec correctly those claims should only be in the ID Token. There should
also be a separate UserInfo endpoint which we're missing.
>
> Is there a reason why AccessToken extends IDToken, or can we remove that?
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev