When using a grant type that returns both the Access Token and ID Token, the ID Token is returned in a state known as a "thin" token. The thin token contains only base user claims, a few scope-dependent claims, and any custom claims if using a custom authorization server. User profile attributes are not included in the thin ID Token, even if the profile scope has been requested.
This article explains why an ID Token will not contain a user's profile attributes despite the profile scope being requested in the OIDC authorization request and how to retrieve these values.
- Interaction Code flow
- Authorization Code flow
- Implicit flow
- Resource Owner Password flow
- This is expected behavior. As per the OIDC specifications:
- The Claims requested by the profile, email, address, and phone scope values are returned from the UserInfo Endpoint when a
response_typevalue is used that results in an Access Token being issued. However, when no Access Token is issued (which is the case for theresponse_typevalueid_token), the resulting Claims are returned in the ID Token.
- The Claims requested by the profile, email, address, and phone scope values are returned from the UserInfo Endpoint when a
- The Interaction Code and Authorization Code flows will always return an Access Token and ID Token together.
- The Implicit flow will return the Access Token and ID Token together if
response_type=id_token+token. - The Resource Owner Password flow will return the Access Token and ID Token together if the openid scope is passed in the token request.
The Access Token provided can be used to call the /userinfo endpoint to return all user claims.
- Please refer to the documentation on the /userinfo endpoint for a custom authorization server or the org authorization server.
- If unsure which type of authorization server is in use, please refer to Authorization servers.
Alternatively, if using a custom authorization server, it is possible to create custom claims to return in the ID Token for the profile attributes that should be included without the need to make a /userinfo call.
