OpenID Connect grant flows

This part describes the OpenID Connect flows that AM supports as per OpenID Connect Core 1.0 incorporating errata set 1, and also provides the information required to implement them. All the examples assume the realm is configured for server-side tokens, but the examples also apply to client-side tokens.

You should decide which flow is best for your environment based on the application that would be the relying party. The following table provides an overview of the flows AM supports when they should be used:

Decide which flow to use depending on the relying party

Relying party Which grant to use? Description

Relying party	Which grant to use?	Description
The relying party is a web application running on a server. For example, a `.war` application.	Authorization code grant	The OpenID Connect provider uses the user-agent, for example, the end user’s browser, to transport a code that is later exchanged for an ID token (and/or an access token). For security purposes, you should use the Authorization Code grant with PKCE when possible.
The relying party is a native application or a single-page application (SPA). For example, a desktop, a mobile application, or a JavaScript application.	Authorization code grant with PKCE	Since the relying party does not communicate securely with the OpenID Connect provider, the code may be intercepted by malicious users. The implementation of the Proof Key for Code Exchange (PKCE) standard mitigates against those attacks.
The relying party knows the user’s identifier, and wishes to gain consent for an operation from the user by means of a separate authentication device.	Backchannel request grant	The relying party does not require that the user interacts directly with it; instead it can initiate a backchannel request to the user’s authentication device, such as a mobile phone with an authenticator app installed, to authenticate the user and consent to the operation. For example, a smart speaker wants to authenticate and gain consent from its registered user after receiving a voice request to transfer money to a third-party.
The relying party is an SPA. For example, a JavaScript application.	Implicit grant	The OpenID Connect provider uses the user-agent, for example, the end user’s browser, to transport an ID token (and maybe an access token) to the relying party. Therefore, the tokens might be exposed to the end user and other applications. For security purposes, you should use the Authorization Code grant with PKCE when possible.
The relying party is an application that can use the ID token immediately, and then request an access token and/or a refresh token.	Hybrid grant	AM uses the user-agent, for example, the end user’s browser, to transport any combination of ID token, access token, and authorization code to the relying party. The relying party uses the ID token immediately. Later on, it can use either the access token to request a refresh token, or the authorization code to request an access token. For security purposes, you should implement the PKCE specification when using the Hybrid flow when possible.

The relying party is a web application running on a server. For example, a .war application.

Authorization code grant

The OpenID Connect provider uses the user-agent, for example, the end user’s browser, to transport a code that is later exchanged for an ID token (and/or an access token).

For security purposes, you should use the Authorization Code grant with PKCE when possible.

The relying party is a native application or a single-page application (SPA). For example, a desktop, a mobile application, or a JavaScript application.

Authorization code grant with PKCE

Since the relying party does not communicate securely with the OpenID Connect provider, the code may be intercepted by malicious users. The implementation of the Proof Key for Code Exchange (PKCE) standard mitigates against those attacks.

The relying party knows the user’s identifier, and wishes to gain consent for an operation from the user by means of a separate authentication device.

Backchannel request grant

The relying party does not require that the user interacts directly with it; instead it can initiate a backchannel request to the user’s authentication device, such as a mobile phone with an authenticator app installed, to authenticate the user and consent to the operation.

For example, a smart speaker wants to authenticate and gain consent from its registered user after receiving a voice request to transfer money to a third-party.

The relying party is an SPA. For example, a JavaScript application.

Implicit grant

The OpenID Connect provider uses the user-agent, for example, the end user’s browser, to transport an ID token (and maybe an access token) to the relying party. Therefore, the tokens might be exposed to the end user and other applications.

For security purposes, you should use the Authorization Code grant with PKCE when possible.

The relying party is an application that can use the ID token immediately, and then request an access token and/or a refresh token.

Hybrid grant

AM uses the user-agent, for example, the end user’s browser, to transport any combination of ID token, access token, and authorization code to the relying party.

The relying party uses the ID token immediately. Later on, it can use either the access token to request a refresh token, or the authorization code to request an access token.

For security purposes, you should implement the PKCE specification when using the Hybrid flow when possible.

ForgeRock provides a Postman collection to try out the flows. See ForgeRock grant flows collection.

Access Management 7.3.1

OpenID Connect grant flows