Where to return user claims – Access token or ID token

Where to return user claims: Access token or ID token

By default, user claims are returned along with the Access token. However, in some cases, our customer wants the user claims to be in the ID token instead. From 5.6 version, The OIDC connection has a new setting that can specify whether Identify should return user claims in the Access token or the ID token.

Setting

The User claims placement setting is only available on the Open ID Connect connection and you can change it using the Identify Admin, the Safewhere Admin, and the REST API. It supports two options:

  1. Access token: This is the default value and is also the current behavior.
  2. ID token: Select this option if you want Identify to return user claims in the Id token instead.

For the Identify Admin, you can find the option in the OAuth protocol connection:

identify-admin-user-claims-placement-option

For the Safewhere Admin, you can find the option in the OIDC application's security settings:

safewhere-admin-user-claims-placement-option

Or in the Clients' setting tab:

safewhere-admin-user-claims-placement-option-on-clients

For the REST API, you can add a property named "userClaimsPlacement" into "configuration" JSON element when doing a POST/PUT on an Open ID connection to set the option value. The property can receive one of two possible values: "AccessToken" or "IdToken".

Using OIDC client application to verify the tokens

After specifying the option to return the user claims, you now can verify it by using one of our OIDC client sample applications.

In this document, we use the ASP.NET MVC sample application to demonstrate the option.

Let's say you want the user claims returned in the Access token by setting the option in Open ID connection to "Access Token". Using the sample application to login by using the code flow, the result will look like this:

access-token-result

You can verify the Access token by decoding it:

access-token-result-decoded

You can see that all user claims are placed in the Access token.

Then, switching the option to ID Token and doing the same flow:

id-token-result

id-token-result-decoded

The ID token now contains the user claims as expected.

In this case, the Access token will not contain any user claims. However, we still can use the Access token to retrieve the user information:

user-info