Identity Cloud

Authorization server configuration

Configure the OAuth 2.0 provider service to expose the OAuth 2.0 endpoints and OAuth 2.0 administration endpoints.

  1. In the AM admin UI, go to Realms > Realm Name > Services > OAuth2 Provider.

  2. On the OAuth 2.0 provider page, select the Advanced tab.

  3. Configure the Grant Types that clients will be able to use to request access, refresh, and ID tokens. For a list of supported grant types, refer to OAuth 2.0 grant flows and OpenID Connect grant flows.

    Although UMA is on the grant types list, UMA is not currently supported in Identity Cloud.

  4. Configure Persistent Claims.

    Persistence lets you retain custom claims when you refresh an access token.

    In the Persistent Claims field, enter the claims that must be persisted between tokens. When an access token is refreshed, any claims that are listed here will be on the new token.

    • These claims are added before the access token modification script, allowing you to manipulate them in the modification script. For example, if a token has a claim called hostname that you want to be persisted when the token is refreshed, you could add that claim to the Persistent Claims list. You could then modify the script to persist that hostname in the new token, if it exists, or to add a hostname to the new token, if it does not exist.

    • Only custom, non-standard claims can be persisted. Standard claims, such as scope (defined in the OAuth 2.0 specification) and auditTrackingId (defined by default in Identity Cloud) cannot be persisted.

Additional configuration options

The OAuth 2.0 provider is highly configurable:

  • To configure the OAuth 2.0 provider in the AM admin UI, go to Realms > Realm Name > Services > OAuth2 Provider.

The following table describes the high-level configuration of the OAuth 2.0 provider service. For additional details, refer to the OAuth2 Provider reference.

Table 1. OAuth 2.0 provider configuration options
Task Resources

Configure the authorization server to issue refresh tokens

Learn why refresh tokens are useful in your environment, how to configure Identity Cloud to issue them, and how to request them.

Refresh tokens

Adjust the lifetimes of tokens and codes

If necessary, adjust the lifetimes for authorization codes (a lifetime of 10 minutes or less is recommended in RFC 6749), access tokens, and refresh tokens.

Configure them on the Core tab of the provider.

N/A

Configure the OAuth 2.0 service to provide scopes dynamically

The OAuth 2.0 provider can leverage the Identity Cloud Authorization service to grant or deny scopes dynamically.

Dynamic OAuth 2.0 authorization

Decide how scopes appear in the consent pages

To change how scopes appear, configure the Client Registration Scope Allowlist field on the Advanced tab of the OAuth 2.0 provider.

Scopes may be entered as simple strings or pipe-separated strings representing the internal scope name, locale, and localized description. For example: read|en|Permission to view email messages in your account.

OAuth 2.0 scopes

Decide how to manage consent

You can:

  • Allow users to save consent so the OAuth 2.0 provider remembers their consented scopes.

  • Allow clients to skip consent so no consent page is displayed to the resource owners.

  • Allow clients to revoke consent.

Manage consent

Configure a remote consent server

This is useful, for example, when your environment must hand off the consent-gathering part of the OAuth 2.0 flows to a separate service.

Remote consent service

Configure client-side tokens

Configure client-side tokens so that resource servers can directly introspect the tokens without making a call to Identity Cloud.

Configure AM for client-side OAuth 2.0 tokens

Configure OpenID-Connect specific options

OpenID provider configuration
Copyright © 2010-2023 ForgeRock, all rights reserved.