Collecting and propagating claims for OAuth and OIDC clients

When using IAM as OAuth or OIDC client, it is possible to use the OAuth 2.0/OIDC configuration to collect claims (i.e., information about the user) from different resources.

In this context, the term resource refers to sources of claims and should not be confused with the Resource Server defined in OIDC.

  • Possible sources of claims are:
  • ID token
  • Remote service endpoints (e.g., userinfo endpoint)
  • Possible types of claims are:
  • User identities (username, sub, issuer, aud, etc.)
  • Roles
  • Context data
  • Information related to authentication and authorization (ACR values, scopes, etc.)
  • Technical information (validity, etc)

Collecting claims from different resources

  • The configuration of resources is organized in the following way:
  • One or more resource requests may be sent to a resource endpoint at login.
    • For each of these resource requests, there is a list of Contained Resources. This allows taking advantage of resource requests that return more than one piece of information at a time.
    • Contained resources may be one of three types
      1. OAuth 2.0 Remote Username Resource– uniquely identifies the username.
      2. OAuth 2.0 Remote User Role Resource– these values are available as authentee roles after login.
      3. OAuth 2.0 Remote Context Data Resource– any other information about the user.
    • To maintain a high level of compatibility, the access token format can be configured differently for each request.

This diagram shows the involved plugins and their relationships:

OAuth 2 SSO configuration

If the user-defined through the resource mappings should be authenticated as is (meaning that Account Linking is disabled), users logging in via OAuth 2.0 do not exist in a local database but reside completely on the authorization server, all components depending on users being in a local database have to be disabled.

Identity propagation

The collection of claims is the only particular part of using IAM as a client. Once the claims are available, they can be used in regular identity propagation.

Identity propagation is configured on the target application and it may combine a subset of the collected claims to be forwarded to that target application to identify the user.