Re: Intended UAA-specific user identity fields in JWT access token ?

Filip Hanik

The access token used to double down as an identity token before OpenID
Connect was standardized, now that we have implemented id_token, we don't
really need it. but removing it would cause an backwards incompatible


On Thu, Mar 31, 2016 at 6:50 AM, Guillaume Berche <bercheg(a)> wrote:


I wonder the rationale for apparenty uaa-specific [0] user-related fields
in the access token (username, email [1]) while they are now returned in a
standard maneer in the openidconnect id token.

Is it something that would change in the future ([2] seemed similar
decoupling) ? Or is it a standard practice that avoids clients to request
the idtoken to get access to basic user identity ?

Thanks in advance,


ps: please let me know if such questions are better suited for a GH issue
on the UAA repo.


Some of these fields are described in the JSON web tokens specification.
However, the vendor may add additional fields, or attributes, to the token



Join { to automatically receive all group messages.