OIDC grant flows

These pages describe supported OpenID Connect (OIDC) flows and how to implement them.

Decide which flow is best based on the relying party (RP):

RP	Grant	Description
The RP is a web application running on a server.	Authorization code grant	The OpenID provider (OP) uses the user-agent to transport the authorization code the RP exchanges for tokens. Use the same grant with Proof Key for Code Exchange (PKCE) when possible.
The RP is a native application or a single-page application (SPA); for example, a desktop or mobile application, or a JavaScript application.	Authorization code grant with PKCE	The RP cannot communicate securely with the OP, so the authorization code can be intercepted by malicious users. The PKCE standard mitigates against interception attacks.
The RP knows the end user’s identifier and gains consent through a separate authentication device, such as a mobile phone with an authenticator application.	Backchannel request grant	The RP does not interact directly with the end user; instead it initiates a backchannel request to the end user’s authentication device to gather consent for the operation. For example, a smart speaker gets consent from its registered end user after receiving a voice request to transfer money to a third party.
The RP is an SPA.	Implicit grant	The OpenID provider (OP) uses the user-agent to transport tokens, exposing them to the end user and other parties. When possible, use the authorization code grant with PKCE instead.
The RP gets an ID token immediately and later gets an access token.	Hybrid grant	The OpenID provider (OP) uses the user-agent to transport the authorization code and initial tokens. Use PKCE with this flow when possible.

Grant

Description

The RP is a web application running on a server.

The OpenID provider (OP) uses the user-agent to transport the authorization code the RP exchanges for tokens.

Use the same grant with Proof Key for Code Exchange (PKCE) when possible.

The RP is a native application or a single-page application (SPA); for example, a desktop or mobile application, or a JavaScript application.

Authorization code grant with PKCE

The RP cannot communicate securely with the OP, so the authorization code can be intercepted by malicious users. The PKCE standard mitigates against interception attacks.

The RP knows the end user’s identifier and gains consent through a separate authentication device, such as a mobile phone with an authenticator application.

Backchannel request grant

The RP does not interact directly with the end user; instead it initiates a backchannel request to the end user’s authentication device to gather consent for the operation.

For example, a smart speaker gets consent from its registered end user after receiving a voice request to transfer money to a third party.

The RP is an SPA.

Implicit grant

The OpenID provider (OP) uses the user-agent to transport tokens, exposing them to the end user and other parties.

When possible, use the authorization code grant with PKCE instead.

The RP gets an ID token immediately and later gets an access token.

Hybrid grant

The OpenID provider (OP) uses the user-agent to transport the authorization code and initial tokens.

Use PKCE with this flow when possible.

Identity Cloud

OIDC grant flows