OAuth 2.0 grant flows

This section describes the supported OAuth 2.0 flows and provides the information required to implement them. The examples assume the realm is configured for client-side tokens, but they also apply to server-side tokens,

Consult the following table to decide which grant flow is best for your environment based on the type of OAuth 2.0 client application.

Client type Suitable grant Description

Client type	Suitable grant	Description
A web application running on a server. For example, a `.war` application.	Authorization code grant	(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.
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	(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. Because 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.
A web application, a native application, or a SPA that needs to make complex and highly secure authorization requests.	Authorization code grant with PAR	(RFC 9126) Clients can push the payload of an authorization request directly to the authorization server without exposing sensitive request data to the browser. The server provides them with a request URI used to secure a subsequent authorization request.
A single-page application (SPA). For example, a JavaScript application.	Implicit grant	(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 grant	(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, rather than acting on behalf of the resource owner.	Client credentials grant	(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.
An input-constrained device. For example, a TV set.	Device authorization grant	(RFC 8628) 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.
An input-constrained device that can generate a Proof Key for Code Exchange (PKCE) challenge.	Device authorization grant with PKCE	(Custom PingOne Advanced Identity Cloud flow, based on RFC 8628 and RFC 7636) 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. Because the client does not communicate securely with the authorization server, the code may be intercepted by malicious users. The implementation of the PKCE standard mitigates against those attacks.
The client has a SAML 2.0 trust relationship with the resource owner. For example, an application in an environment where a SAML 2.0 and an OAuth 2.0 ecosystem coexist.	SAML 2.0 profile for authorization	(RFC 7522) The client uses the resource owner’s SAML 2.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 2.0 and an OAuth 2.0 ecosystem coexist.	JWT profile for authorization	(RFC 7523) The client uses a signed JWT to obtain an access token from the authorization server without interacting with the resource owner.

A web application running on a server. For example, a .war application.

Authorization code grant

(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.

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

(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.

Because 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.

A web application, a native application, or a SPA that needs to make complex and highly secure authorization requests.

Authorization code grant with PAR

(RFC 9126) Clients can push the payload of an authorization request directly to the authorization server without exposing sensitive request data to the browser. The server provides them with a request URI used to secure a subsequent authorization request.

A single-page application (SPA). For example, a JavaScript application.

Implicit grant

(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 grant

(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, rather than acting on behalf of the resource owner.

Client credentials grant

(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.

An input-constrained device. For example, a TV set.

Device authorization grant

(RFC 8628) 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.

An input-constrained device that can generate a Proof Key for Code Exchange (PKCE) challenge.

Device authorization grant with PKCE

(Custom PingOne Advanced Identity Cloud flow, based on RFC 8628 and RFC 7636) 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.

Because the client does not communicate securely with the authorization server, the code may be intercepted by malicious users. The implementation of the PKCE standard mitigates against those attacks.

The client has a SAML 2.0 trust relationship with the resource owner. For example, an application in an environment where a SAML 2.0 and an OAuth 2.0 ecosystem coexist.

SAML 2.0 profile for authorization

(RFC 7522) The client uses the resource owner’s SAML 2.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 2.0 and an OAuth 2.0 ecosystem coexist.

JWT profile for authorization

(RFC 7523) The client uses a signed JWT to obtain an access token from the authorization server without interacting with the resource owner.

PingOne Advanced Identity Cloud supports associating a confirmation key with an access token to support proof-of-possession interactions. For more information, refer to JWK-based proof-of-possession.