OpenID Connect grant flows

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

You should decide which flow is best for your environment based on the role of the relying party (RP). The following table provides an overview of the flows AM supports and when they should be used:

Scenario Recommended flow

Scenario	Recommended flow
The RP is a server-side web application that authenticates users and needs the identity claims in an ID token.	Authorization code grant. The RP is a confidential client that can store a client secret and exchanges the code for tokens on the server. The OpenID provider (OP) uses the user-agent to transport the authorization code the RP exchanges for tokens. Use Proof Key for Code Exchange (PKCE) with this grant when possible.
The RP is a native application or a single-page application (SPA) that authenticates users without a server backend. For example, a desktop, mobile, or JavaScript application.	Authorization code grant with PKCE. The RP is a public client that can’t store a client secret or communicate securely with the OP, so the authorization code can be intercepted by malicious users. The PKCE standard mitigates against interception attacks.
The RP is a backend service that knows the end user’s identifier and needs their consent without browser redirection. The RP supplies the identifier as a `login_hint` in the backchannel request. For example, a smart speaker gets consent from its registered end user after receiving a voice request to transfer money to a third party.	Backchannel request grant (client-initiated backchannel authentication, CIBA). The RP registers as a confidential client and doesn’t interact directly with the end user. It initiates a backchannel request to the end user’s authentication device, such as a mobile phone with an authenticator application. The RP then polls for tokens while the user approves the operation.
The RP is an SPA that can only consume tokens delivered directly through the browser.	Implicit grant. The OP uses the user-agent to transport tokens, exposing them to the end user and other parties, and the RP receives tokens in the front channel. AM doesn’t issue refresh tokens. When possible, use the authorization code grant with PKCE instead.
The RP requires an ID token immediately and exchanges the authorization code for additional tokens later.	Hybrid grant. The OP uses the user-agent to transport the authorization code and initial tokens. The RP validates the user’s identity before the code exchange completes, for example to start a session early. Use PKCE with this flow when possible.

The RP is a server-side web application that authenticates users and needs the identity claims in an ID token.

Authorization code grant.

The RP is a confidential client that can store a client secret and exchanges the code for tokens on the server. The OpenID provider (OP) uses the user-agent to transport the authorization code the RP exchanges for tokens.

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

The RP is a native application or a single-page application (SPA) that authenticates users without a server backend. For example, a desktop, mobile, or JavaScript application.

Authorization code grant with PKCE.

The RP is a public client that can’t store a client secret or communicate securely with the OP, so the authorization code can be intercepted by malicious users. The PKCE standard mitigates against interception attacks.

The RP is a backend service that knows the end user’s identifier and needs their consent without browser redirection. The RP supplies the identifier as a login_hint in the backchannel request. For example, a smart speaker gets consent from its registered end user after receiving a voice request to transfer money to a third party.

Backchannel request grant (client-initiated backchannel authentication, CIBA).

The RP registers as a confidential client and doesn’t interact directly with the end user. It initiates a backchannel request to the end user’s authentication device, such as a mobile phone with an authenticator application. The RP then polls for tokens while the user approves the operation.

The RP is an SPA that can only consume tokens delivered directly through the browser.

Implicit grant.

The OP uses the user-agent to transport tokens, exposing them to the end user and other parties, and the RP receives tokens in the front channel. AM doesn’t issue refresh tokens.

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

The RP requires an ID token immediately and exchanges the authorization code for additional tokens later.

Hybrid grant.

The OP uses the user-agent to transport the authorization code and initial tokens. The RP validates the user’s identity before the code exchange completes, for example to start a session early.

Use PKCE with this flow when possible.

PingAM

OpenID Connect grant flows