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.

To Configure the OAuth 2.0 Provider Service

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.
Grant Types Reference
```
Implicit
SAML2
Refresh Token
Resource Owner Password Credentials
Client Credentials
Device Code
Authorization Code
Back Channel Request
UMA
JWT Bearer
Token Exchange
```
Related information:
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 /oauth2/authorize endpoint.
Response Type Plugin Reference
```
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
```
- The id_token and none response types are used in OpenID Connect flows.
- The code response type is used in the OAuth 2.0 and OpenID Connect Authorization Code grant flows.
- The device_code response 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 AM.
- The token response type is used in the OAuth 2.0 and OpenID Connect Implicit flows.
(Optional) For configuration options, see "Additional Configuration".

Additional Configuration

The OAuth 2.0 provider is highly configurable:

To access the OAuth 2.0 provider configuration in the AM console, go to Realms > Realm Name > Services, and then select OAuth2 Provider.
To adjust global defaults, in the AM console, 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.

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 AM 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 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, `/path/to/tomcat/webapps/openam/WEB-INF/lib/`) and specify the class name in the Scope Implementation Class field.	"Customizing OAuth 2.0 Scope Handling"
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.	OAuth 2.0 Token Exchange
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.	Dynamic OAuth 2.0 Authorization
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.	N/A
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: `read\|en\|Permission to view email messages in your account`.	About 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.	About 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
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.	"To Change the Attribute Used to Retrieve the User Profile"
Configure client-based tokens Configure client-based tokens so that resource servers can directly introspect the tokens without making a call to AM.	"Configuring AM for Client-Based OAuth 2.0 Tokens"
Configure OpenID-Connect specific options UMA providers also use these options.	OpenID Provider Configuration

To Change the Attribute Used to Retrieve the User Profile

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, mail, perform the following steps:

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, mail.
Warning
If you change the value of Authentication Naming Attribute after you have deployed and configured AM, you must update or recreate all existing identities to refresh user DNs.
Failure to do so could result in unsuccessful authentication or risk of impersonation attacks.
Create an LDAP authentication module or an LDAP decision node to use with the identity repository.
In both cases, configure the following fields:
1. In the Attribute Used to Retrieve User Profile field, set the attribute to mail.
2. In the Attributes Used to Search for a User to be Authenticated list, add the mail attribute.
3. 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:
1. For a specific access token REST request.
  Set the auth_chain parameter.
2. 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.
3. Individually for a realm.
  Navigate to Realms > Realm Name > Authentication > Settings > Core, and set the Organization Authentication Configuration property.
4. 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.

Authorization Server Configuration

Warning