Request user information

When 10Duke Enterprise has successfully authenticated a user using OpenID Connect (OIDC)/OAuth 2.0, it grants a standard OIDC ID token to your client application. The ID token is a JSON Web Token (JWT) that contains the details of the authenticated end user in a standard format.

The ID token is used when the client application needs user information during the login process. If user data is needed later, the client application can request OIDC UserInfo from 10Duke Enterprise.

ID token content

The content of the ID token granted by 10Duke Enterprise depends on which OIDC scopes were used for requesting for user information. When your client application starts the OIDC authentication flow with 10Duke Enterprise, it specifies the requested scopes.

An example of ID token content:

{
  "iss": "customer.10duke.net",
  "sub": "db940343-589d-4f59-be67-99f67f8dc225",
  "aud": "ClientApplication",
  "exp": 1693214155,
  "iat": 1693214155,
  "at_hash": "J0v8400-YH5Pyy5JxbVZpQ",
  "nonce": "12345",
  "given_name": "Bob",
  "family_name": "Jones",
  "name": "Bob Jones",
  "email": "bobjones@company.com",
  "email_verified": false,
  "phone_number": "555-123-4567",
  "organization": {
    "name": "Customer Organization",
    "id": "a370e481-7f02-4b2a-9e57-52fe3cfed0d2"
  },
  "user_properties": [
    {
      "key": "Property1",
      "value": "1"
    }
  ],
  "client_permissions": [
    {
      "name": "Article",
      "actions": [
        "read",
        "edit"
      ]
    }
  ]
}

Standard OIDC claims:

  • iss: The OIDC issuer URL (the base URL of your 10Duke Enterprise environment).

  • sub: The user ID.

  • aud: The client ID.

  • exp: The time when the ID token expires.

  • iat: The time when the ID token was issued.

  • at_hash: An access token hash value that the client application can use for additional access token verification.

  • nonce: A string value used for mitigating replay attacks.

  • given_name: The user’s first name.

  • family_name: The user’s last name.

  • name: The user’s display name. If no display name is available, this contains the user’s first and last name.

  • email: The user’s email address.

  • email_verified: “true” if the user’s email address is marked as verified in 10Duke Enterprise, otherwise “false”.

  • phone_number: The user’s phone number.

See more details on the OIDC ID token and the standard claims.

Custom 10Duke Enterprise claims:

  • organization: The user’s organization based on the “employees” user group they belong to. If the user belongs to several “employees” user groups, only the organization which the user was first attached to via the “employees” user group is returned.

  • user_properties: The custom properties defined for the user in 10Duke Enterprise.

  • client_permissions: The client permissions that the user has been granted in the scope of this client application.

ID token validity

The maximum validity time of ID tokens granted by 10Duke Enterprise is configurable in your 10Duke Enterprise deployment. The default validity is 1 hour (the same as the access token’s default validity).

For 10Duke Enterprise configuration changes, contact the 10Duke Integration Support team.

ID token signature verification

When 10Duke Enterprise grants the ID token, it signs the token using a private key. Your client application can verify the signature using the corresponding public key to ensure that the ID token was granted by 10Duke Enterprise and the data hasn’t been tampered with.

In most cases, it’s not necessary for your client application to verify the signature of an ID token granted by 10Duke Enterprise.

There may be specific use cases where signature verification is needed, for example, if there’s a need to store the ID token in the client application and read the authenticated user’s details from there later. For these use cases:

  • You can find the public key in the 10Duke Enterprise OIDC Discovery document.

  • We recommend that client applications connected to the Internet always fetch the public key from 10Duke Enterprise, which enables rolling of the keys as needed. Client applications that are deployed in environments with no Internet access must store the public key in a safe location where any application-specific data is stored.

  • For verifying the signature of tokens, you can find libraries for various platforms and languages on the jwt.io website.

Request UserInfo

After end user authentication and API authorization by OIDC/OAuth 2.0, your client application can request for more information about the end user from 10Duke Enterprise, if needed.

Request OIDC UserInfo using the 10Duke Authentication API’s user information endpoint.

An example request (line breaks added for display purposes):

GET /user/info
   Authorization: Bearer OeRIO5cbQkvTFRCgostl8V7xZGU

The request must include the access token in the Bearer token authorization header, as in the example above.

The endpoint returns user information in JSON format according to the OIDC scopes that your client application sent to 10Duke Enterprise when starting the OIDC authentication flow.

The UserInfo response contains the same kind of claims as the ID token (see above).

On this page