This article explains why an ID token might have an attribute/claim missing from an ID token and how to get all user claims and Okta groups in such a case.

This article assumes that:

• User Attribute
  • Org Authorization Server: The attribute exists and is populated (not null) in the Application User Profile, which can be checked from either the Mappings in Profile Editor or by opening the Provisioning page.
  • Custom Authorization Server: The attribute exists and is populated (not null) in the Okta User Profile, which can be checked from the User Attributes page.
  • For more information on either of these options, please review the article: The Okta User Profile And Application User Profile.

• Implicit flow
• Authorization code flow 
• Resource owner password flow (grant_type = password)

When returned along with the access token, the ID token is considered a Thin Token or Thin ID Token. The Thin ID Token only carries base claims and some scope-dependent claims. For example, if the `profile` scope is requested and a thin token is returned, the ID token payload will contain the `preferred_username` and `name` claims but will not include other `profile` scope-dependent claims such as `given_name` or `family_name`.

Examples of when the ID token and access token are returned together:

• Implicit flow, where response_type=id_token+token.
• Authorization code flow, where `openid` scope is passed in authorize request.
• Resource owner password flow, where `openid` scope is passed in the token request.

NOTE: When the ID token is returned alone (without the access token, for example) in the implicit flow where response_type=id_token, the ID token returned is considered a Fat Token and should contain all profile attributes if the profile scope is passed and groups if the groups scope is passed. 

This behavior is based on the OpenID specifications about scope-dependent claims. See the following quote from section 5.4:

• "The Claims requested by the profile, email, address, and phone scope values are returned from the UserInfo Endpoint, as described in Section 5.3.2 when a response_type value is used that results in an Access Token being issued. However, when no Access Token is issued (which is the case for the response_type value id_token), the resulting Claims are returned in the ID Token."

In these flows, an Access Token is returned along with an ID Token. This Access Token can be used to retrieve user claims (all profile attributes/claims, if the appropriate scopes are passed). 

The Access Token can be sent as a bearer token in the authorization header of the Userinfo request (that is POST ${baseUrl}/oauth2/v1/userinfo), where the base URL will be https://OktaDomain.okta.com or the custom domain.

Related References

• Implicit flow
• Authorization code flow 
• Resource owner password flow (grant_type = password)