OAuth 2.0 grant flows
This section 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 server-side tokens; however, the examples also apply to client-side 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:
| Scenario | Recommended flow |
|---|---|
The client is a server-side web application that authenticates users and calls APIs on their behalf.
For example, a Java or Python application, or a |
The client is confidential and can store a client secret, and the code exchange happens on the server, away from the browser. 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. Use Proof Key for Code Exchange (PKCE) with this grant when possible. |
The client is a native application or a single-page application (SPA) that authenticates users without a server backend. For example, a desktop, a mobile application, or a JavaScript application. |
The client is a public client that can’t store a client secret. 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 it doesn’t communicate securely with the authorization server, the code can be intercepted by malicious users. The implementation of the PKCE standard mitigates against those attacks. |
The client is a web application, a native application, or an SPA that needs to make complex and highly secure authorization requests. |
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 that is used to secure a subsequent authorization request. |
The client is an SPA that can only consume tokens delivered directly through the browser. For example, a JavaScript application. |
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. |
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 aren’t available. |
The client is the resource owner, or the client doesn’t act on behalf of the resource owner. For example, a scheduled job or a microservice calling an API without an end user present. |
Similar to the resource owner password credentials grant type, but the resource owner isn’t part of the flow and the client accesses information relevant to itself. |
The client is an input-constrained device that needs user authorization but has no practical keyboard and browser. For example, a smart TV, a streaming device, a command-line tool, or a headless server. |
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. If the device can generate a PKCE challenge, use device authorization with PKCE. |
The client is an input-constrained device that can generate a PKCE challenge. |
Device authorization grant with PKCE (AM-only, 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 doesn’t communicate securely with the authorization server, the code can 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 ecosystem coexists with an OAuth 2.0 one. |
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 JSON Web Token (JWT). For example, an application in an environment where a non-SAML 2.0 identity ecosystem coexists with an OAuth 2.0 one. |
The client or another issuer authenticates the resource owner, obtains authorization, and prepares a signed JWT. AM validates the JWT using a trusted JWT issuer profile and issues an access token without interacting with the resource owner. |
Use the Postman collection to try out the flows.
|
AM supports associating a confirmation key or a certificate with an access token to support proof-of-possession interactions. Learn more in Certificate-bound proof-of-possession and JWK-based proof-of-possession. |