OAuth 2.0 Grant Flows

This chapter describes the OAuth 2.0 flows that AM supports, and also provides the information required to implement them. All the examples assume the realm is configured for CTS-based tokens, however, the examples also apply to client-based tokens.

You should decide which flow is best for your environment based on the application that will be the OAuth 2.0 client. The following table provides an overview of the flows AM supports and when they should be used:

Deciding Which Flow to Use Depending on the OAuth 2.0 Client

Client Type	Which Grant to use?	Description
The client is a web application running on a server. For example, a `.war` application.	Authorization Code	(RFC 6749) The authorization server uses the user-agent, for example, the resource owner's browser, to transport a code that is later exchanged for an access token.
The client is a native application or a single-page application (SPA). For example, a desktop, a mobile application, or a JavaScript application.	Authorization Code with PKCE	Authorization Code with PKCE (RFC 6749, RFC 7636) The authorization server uses the user-agent, for example, the resource owner's browser, to transport a code that is later exchanged for an access token. Since the client does not communicate securely with the authorization server, the code may be intercepted by malicious users. The implementation of the Proof Key for Code Exchange (PKCE) standard mitigates against those attacks.
The client is a SPA. For example, a JavaScript application.	Implicit	(RFC 6749) The authorization server gives the access token to the user-agent so it can forward the token to the client. Therefore, the access token might be exposed to the user and other applications. For security purposes, you should use the Authorization Code grant with PKCE when possible.
The client is trusted with the resource owner credentials. For example, the resource owner's operating system.	Resource Owner Password Credentials	(RFC 6749) The resource owner provides their credentials to the client, which uses them to obtain an access token from the authorization server. This flow should only be used if other flows are not available.
The client is the resource owner, or the client does not act on behalf of the resource owner.	Client Credentials	(RFC 6749) Similar to the Resource Owner Password Credentials grant type, but the resource owner is not part of the flow and the client accesses information relevant to itself.
The client is an input-constrained device. For example, a TV set.	Device Flow	(OAuth 2.0 Device Flow for Browserless and Input Constrained Devices) The resource owner authorizes the client to access protected resources on their behalf by using a different user-agent and entering a code displayed on the client device.
The client has a SAML v2.0 trust relationship with the resource owner. For example, an application in an environment where a SAML v2.0 ecosystem coexists with an OAuth 2.0 one.	SAML v2.0 Profile	(RFC 7522 ) The client uses the resource owner's SAML v2.0 assertion to obtain an access token from the authorization server without interacting with the resource owner again.
The client has a trust relationship with the resource owner that is specified as a JWT. For example, an application in an environment where a non-SAML v2.0 identity ecosystem coexists with an OAuth 2.0 one.	JWT Bearer Profile	(RFC 7523 ) The client uses a signed JWT to obtain an access token from the authorization server without interacting with the resource owner.

Tip

AM supports associating a confirmation key or a certificate with an access token to support proof-of-possession interactions.

For more information, see "Certificate-Bound Proof-of-Possession" and "JWK-Based Proof-of-Possession".

ForgeRock OAuth 2.0 Grant Flows Collection

Use this collection of OAuth 2.0 grant flows to try out the OAuth 2.0 flows that AM supports. The source for the REST calls, including the prerequisites needed to run the collection, is provided as a downloadable JSON file collection. You can open the collection in an API tool such as Postman.

Follow these steps to import the JSON File into Postman:

Open the following link: ForgeRock OAuth 2.0 Collection.
Import the JSON file into Postman, using either of the following methods:
- Download the JSON file, and open it in Postman from the Import File tab.
- Copy the link to the JSON file, and paste it in the Postman in the Import From Link tab.

Once the ForgeRock OAuth 2.0 Collection is open in Postman, you can run the OAuth 2.0 grant flows.

Note that this collection will make changes to your AM configuration. It contains calls which will create the following:

Subrealm called mySubRealm, under the top-level realm.
OAuth 2.0 Provider service in the subrealm.
Demo user called ForgeRockDemo.
Confidential OAuth 2.0 client called forgerockDemoConfidentialClient in the subrealm..
Public OAuth 2.0 client called forgerockDemoPublicClient in the subrealm.

For more information, see the documentation within the collection.