AM as the authorization server
As an authorization server, AM authenticates resource owners and obtains their authorization to return access tokens to clients.
Before you configure OAuth 2.0 in your environment, familiarize yourself with the OAuth 2.0 authorization framework and the RFCs, Internet-Drafts, and standards that AM supports relating to OAuth 2.0.
OAuth 2.0 concepts
RFC 6749, the OAuth 2.0 authorization framework lets a third-party application obtain limited access to a resource (usually user data) on behalf of the resource owner or the application itself.
The main actors in the OAuth 2.0 authorization framework are the following:
| Actor | Description |
|---|---|
Resource owner (RO) |
The owner of the resource. For example, a user who stores their photos in a photo-sharing service. The resource owner uses a user-agent, usually a web-browser, to communicate with the client. |
Client |
The third-party application that wants to access the resource. The client makes requests on behalf of the resource owner and with their authorization. For example, a printing service that needs to access the resource owner’s photos to print them. AM can act as a client. |
Authorization server (AS) |
The authorization service that authenticates the resource owner and/or the client, issues access tokens to the client, and tracks their validity. Access tokens prove that the resource owner authorizes the client to act on their behalf over specific resources for a limited period of time. AM can act as the authorization server. |
Resource server (RS) |
The service hosting the protected resources. For example, a photo-sharing service. The resource server must be able to validate the tokens issued by the authorization server. A website protected by a web or a Java agent can act as the resource server. |
The following sequence diagram demonstrates the basic OAuth 2.0 flow:
To use AM as an authorization server, register an OAuth 2.0 client in the AM admin UI. Clients can also register themselves dynamically. For details, refer to Client application registration.
Supported OAuth 2.0 features
As an authorization server, AM supports the following features:
| Feature | Details |
|---|---|
|
|
|
|
OAuth 2.0 token exchange |
|
Other OAuth 2.0 standards |
|
Delegates the consent-gathering part of an OAuth 2.0 flow to a separate service. |
|
Customizable scope grants |
You can customize how scopes are granted to the client, regardless of the grant flow used. AM can grant scopes statically or dynamically:
|
Security considerations
| OAuth 2.0 messages involve credentials and access tokens that allow the bearer to retrieve protected resources. You must protect the messages going across the network and prevent attackers from capturing requests or responses. |
RFC 6749 includes a number of security considerations and requires Transport Layer Security (TLS) to protect sensitive messages. Make sure you read these security considerations and implement them in your deployment.
When you are deploying a combination of other clients and resource servers, pay special attention to the OAuth 2.0 threat model and security considerations before putting your service into production.
OAuth 2.0 sample mobile applications
To try the capabilities of AM as an authorization server, you can download the sample mobile application.
For access to the source code, refer to How do I access and build the sample code provided for PingAM? in the ForgeRock Knowledge Base.