Authorization Server Configuration
Configure the OAuth2 Provider Service in a realm to expose the endpoints specified in OAuth 2.0 Endpoints and OAuth 2.0 Administration and Supporting REST Endpoints.
In the AM Admin UI, go to Realms > Realm Name > Services, and click on the Add a Service button.
From the drop-down menu, select the OAuth2 Provider service. Then, click the Create button without filling any other field.
The OAuth 2.0 provider page appears.
Go to the Advanced tab.
Configure the Grant Types that clients will be able to use to request access, refresh, and ID tokens.
Configure the Response Type Plugins you need in your environment based on the grant type flows you will allow in your environment. Response plugins let the provider issue access tokens, ID tokens, authorization codes, and others, when the client requests a flow that interacts with the
code|org.forgerock.oauth2.core.AuthorizationCodeResponseTypeHandler id_token|org.forgerock.openidconnect.IdTokenResponseTypeHandler device_code|org.forgerock.oauth2.core.TokenResponseTypeHandler token|org.forgerock.oauth2.core.TokenResponseTypeHandler none|org.forgerock.oauth2.core.NoneResponseTypeHandler
noneresponse types are used in OpenID Connect flows.
coderesponse type is used in the OAuth 2.0 and OpenID Connect Authorization Code grant flows.
device_coderesponse type was used for the Device grant flow, but it is not required in the current implementation and will be removed in a future release of Identity Cloud.
tokenresponse type is used in the OAuth 2.0 and OpenID Connect Implicit flows.
(Optional) For configuration options, see "Additional Configuration".
The OAuth 2.0 provider is highly configurable:
To access the OAuth 2.0 provider configuration in the AM Admin UI, go to Realms > Realm Name > Services, and then select OAuth2 Provider.
To adjust global defaults, in the AM Admin UI, go to Configure > Global Services, and then click OAuth2 Provider.
See the "OAuth2 Provider" reference section for details on each of the fields in the provider.
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.
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.
Configure the OAuth 2.0 provider for token exchange
Following the OAuth 2.0 Token Exchange specification, the provider can let your clients exchange tokens.
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.
Configure a custom response plugin
To configure a custom response type plugin, put it on the Identity Cloud classpath, and then add the custom response types and the plugin class names to the list of Response Type Plugins field, on the Advanced tab.
Decide how scopes appear in the consent pages
To change how scopes appear, configure the Client Registration Scope Whitelist 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:
Decide how to 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.
Configure the attribute Identity Cloud uses to retrieve the user profile
This is useful, for example, in cases where the resource owner should log in with their email address instead of with a username.
Configure client-based tokens
Configure client-based tokens so that resource servers can directly introspect the tokens without making a call to Identity Cloud.
Configure OpenID-Connect specific options
UMA providers also use these options.
If you use an external identity repository where resource owners log in not with their user ID, but instead with their mail address or some other profile attribute, you must configure Identity Cloud authentication to allow it.
For example, to configure Identity Cloud so OAuth 2.0 resource owners can log in using their email address, stored on the LDAP profile attribute,
On the OAuth2 provider Advanced tab, add the LDAP profile attribute to the User Profile Attribute(s) the Resource Owner is Authenticated On list, and save your changes.
Navigate to Realms > Realm Name > Identity Stores > Identity Store Name > Authentication Configuration.
Set the value of the Authentication Naming Attribute field to the LDAP attribute required. For example,
Create an LDAP decision node to use with the identity repository.
In both cases, configure the following fields:
In the Attribute Used to Retrieve User Profile field, set the attribute to
In the Attributes Used to Search for a User to be Authenticated list, add the
Save your changes.