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 console, 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, device codes, and others.
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 authorization code grant flow.
device_coderesponse type is used in the device grant flow.
tokenresponse type is used by all flows to issue access and refresh tokens.
(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 console, navigate to Realms > Realm Name > Services, and then select OAuth2 Provider.
To adjust global defaults, in the AM console navigate 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 AM 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 a custom scope validator implementation
Keep the default scope implementation, whereby scopes are taken to be resource owner profile attribute names, unless you have a custom scope validator implementation.
If you have a custom scope validator implementation, copy it to the AM classpath (for example,
Configure the OAuth 2.0 service to provide scopes dynamically
The OAuth 2.0 provider can leverage the AM Authorization service to grant or deny scopes dynamically.
Configure a custom response plugin
To configure a custom response type plugin, put it on the AM 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 AM 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 clients can directly introspect the tokens without making a call to AM.
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 AM authentication to allow it.
For example, to configure AM 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 authentication module or 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.
Ensure the resource owners use the authentication tree or chain where you configured the LDAP module or node.
Specify the chain or tree by using one or more of the methods below. AM checks for the configured value in the following order, using the first value found:
For a specific access token REST request.
Individually for a realm, overriding the realm-level setting below.
Navigate to Realms > Realm Name > Services > OAuth2 Provider > Advanced, and set the Password Grant Authentication Service property.
Individually for a realm.
Navigate to Realms > Realm Name > Authentication > Settings > Core, and set the Organization Authentication Configuration property.
Globally, for all realms.
Navigate to Configure > Authentication > Core Attributes > Core, and set the Organization Authentication Configuration property.
For more information, see Configure Sensible Default Authentication Services.
For more information about authentication trees and chains, see Configuring AM for Authentication.