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
change.


Filip

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

Hi,

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,

Guillaume.

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

[0]
https://github.com/cloudfoundry/uaa/blob/master/docs/UAA-Tokens.md#getting-started

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

[1]
https://github.com/cloudfoundry/uaa/blob/9b5c13d793ebfe358e26559cedc6b528a557b43f/server/src/main/java/org/cloudfoundry/identity/uaa/oauth/UaaTokenServices.java#L493-L497
[2] https://www.pivotaltracker.com/story/show/102090344

Guillaume.

Join cf-dev@lists.cloudfoundry.org to automatically receive all group messages.