Show / Hide Table of Contents

    Where to return user's claims: access token or ID token

    By default, user's claims are returned along with the access token. However, in some cases, our customer wants the user's 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's 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:

    setting

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

    setting

    Or in the Clients setting tab:

    setting

    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 - "Access Token" or "Id Token".

    Using OIDC client application to verify the tokens

    After specifying the option to return the user's 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's 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:

    result

    You can verify the access token by decoding it:

    result

    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:

    result

    result

    The ID token now contains the user's claims as expected.

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

    userinfo

    Back to top Generated by DocFX