Userinfo endpoint

Userinfo endpoint

We reworked the Userinfo endpoint to make it issue proper claims as stated by the specification in version 5.5.

Identify supports requesting claims using scope values . Thus, instead of returning all the user's claims as we did previously, it selectively returns claims granted by users which are determined via access token's scopes.

Therefore, there are 3 groups of claims that can be returned from the Userinfo endpoint:

  • Default claims: those claims always are issued regardless of what the requested scopes are.
    • sub: subject of an access token.
    • name: Identify looks up a claim whose name is "name" on the user's claims. Alternatively, it returns the value of the sub claim.
    • urn:internal:userid: this claim is always available for all local user's requests.
  • Standard scopes: depending on the standard scopes of an access token, Identify returns different standard claims as follows:
    • "email" scope: Identify returns "email" and "email_verified" claims. For the "email_verified" claim, Identify always returns "false" since we don't have a mechanism to verify emails yet.
    • "phone" scope: Identify returns "phone_number" and "phone_number_verified " claims. For the "phone_number_verified" claim, Identify always returns "false" since we don't have a mechanism to verify phone numbers yet.
    • "address": Identify looks up an "address" claim and return it if there is. Otherwise, Identify skips this claim. (Note: the address value must be JSON object)
    • "profile" scope: Identify looks up a set of claims and return them if there are any proper ones. Those claims are "profile", "family_name", "given_name", "middle_name", "nickname", "preferred_username", "picture", "website", "gender", "birthdate", "zoneinfo", "locale", "updated_at".
  • Additional scopes: if an OIDC application wants to request for additional claims from the Userinfo endpoint, it needs to specifically request for them by adding them as requested scopes to the login request sent to Identify. For instance, if you want to request for a fed:local:claim1 claim, the request will look like:

Please note that Identify only returns those claims if it can find them in user's claims. As a side note, our OIDC application samples have a setting to specify what scopes and claims you want to request.

Another change is that Identify OAuth 2.0/OIDC won't issue the user_id claim anymore. Instead, the user's ID is now issued via the urn:internal:userid claim type.

Note: while serializing token (both id token and access token) to JSON strings, some claim types are mapped from JWT to .NET claims as followings:

From claim To claim actor birthdate email family_name gender given_name nameid sub website unique_name oid scp tid acr adfs1email adfs1upn amr auth_time authmethod certapppolicy certauthoritykeyidentifier certbasicconstraints certeku certissuer certissuername certkeyusage certnotafter certnotbefore certpolicy certpublickey certrawdata certserialnumber certsignaturealgorithm certsubject certsubjectaltname certsubjectkeyidentifier certsubjectname certtemplateinformation certtemplatename certthumbprint certx509version clientapplication clientip clientuseragent commonname denyonlyprimarygroupsid denyonlyprimarysid denyonlysid devicedispname deviceid deviceismanaged deviceostype deviceosver deviceowner deviceregid endpointpath forwardedclientip group groupsid idp insidecorporatenetwork isregistereduser
ClaimTypes.PPID ppid primarygroupsid primarysid proxy pwdchgurl pwdexpdays pwdexptime relyingpartytrustid role upn winaccountname
  1. The above claims are mapped when generating access tokens, id tokens, and Userinfo's response.
  2. If a user has more than one email value, the first one is used for the email claim of Userinfo's response.

UserInfo response signing

Identify supports signing for userinfo response as described on spec. When it's signed, its claims are returned in a JWT and the content-type is application/jwt.

Discovery endpoint

You can check the discovery endpoint of your Identify instance to see if the userinfo_signing_alg_values_supported feature has been supported:

Dynamic client registration endpoint

Please visit the Client metadata section for the new supported keys:

Key name


Setting up OAuth2.0 protocol connection for UserInfo response signing

You update the settings below:

  • Enable the option: "Sign UserInfo response".
  • Select the algorithm: RSASigning or HMACSynmetric at JWS Algorithm. If HMACSynmetric is selected, you can alter to generate Symmetric key for HMAC signing: 32-byte key(HS256)/48-byte key(HS384)/64-byte key(HS512).

For the Identify Admin, you can find the options in the OAuth2.0 protocol connection:


For the Safewhere Admin, you can find the option in the OpenID Connect/OAuth2.0 application's security settings:


For the REST API, you can add a property named "signUserInfoResponse" into its "configuration" connection JSON element.

Client side

After specifying the UserInfo response signing, you call POST/GET method to the userinfo endpoint.

Request URL using POST:

Request body example:

Key Value

Response example: