This article describes the available OAuth 2.0 grants and OpenID Connect (OIDC) flows. It provides guidance on selecting the correct flow or grant based on the application type, security requirements, and specific use cases.

• OAuth 2.0
• OpenID Connect (OIDC)

Choosing the right OAuth 2.0 grant or OIDC flow depends on your application type and security requirements. The following list is divided into "Primary Flows and Grants", which are used to start a new user session, and "Dependent Flows and Grants", which rely on a token or assertion already obtained from a primary flow. Legacy flows are included at the bottom for reference, but are generally discouraged for new integrations.

Primary Authentication Flows and Grants

These flows (and grants) are used to initiate a user or machine session from scratch.

Authorization Code Flow with Proof Key for Code Exchange (PKCE)

• Use Case: PKCE was initially designed to protect the authorization code flow in single-page applications and mobile apps, but its ability to prevent authorization code injection makes it useful for every type of OAuth client, including web apps that use client authentication. 
• Description: This flow adds a security layer to the standard Authorization Code flow by using a dynamic code verifier and code challenge. It prevents authorization code interception attacks and is the recommended standard for OAuth clients.
• Documentation: Implement the Authorization Code flow with PKCE.

Client Credentials Grant

• Use Case: Machine-to-Machine (M2M) communications, such as daemons, backend scripts, or services with no end-user interaction.
• Description: The application authenticates as itself using its client credentials to obtain an Access Token. This grant does not involve a user context and, therefore, no ID token or user identifier is returned, and it cannot be used with OpenID scopes.
• Documentation: Implement the Client Credentials Grant.

Direct Auth

• Use Case: Direct authentication allows client apps to directly verify user credentials and authentication factors without relying on browser interactions. This approach gives apps more control over authentication. It's also useful for non-browser apps, such as mobile apps, where user experience can be negatively impacted by browser interactions.
• Description: Direct authentication provides a set of authentication APIs. These APIs allow a client to directly verify a user's authentication factors in exchange for OAuth 2.0 tokens. The client does this without interacting with the Sign-In Widget in a browser.
• Documentation: Configure Direct Auth Grants.

Interaction Code Flow (IDX)

• Use Case: Native, Single-Page Application (SPA), and web apps using the Okta Identity Engine (OIE) that require an embedded authentication experience.
• Description: This flow allows applications to manage user interactions directly with the Identity Engine without browser redirects. It returns an interaction code that the client exchanges for tokens. 
• Documentation: Implement the Interaction Code flow.

Device Authorization Grant Flow

• Use Case: Input-constrained devices such as smart TVs, IoT devices, or command-line interfaces (CLI) that lack a browser or keyboard.
• Description: This flow is designed for devices that cannot perform a standard browser-based login. It initiates a request that requires the user to complete authentication on a separate device (such as a smartphone or laptop). Once the user enters the provided code and authenticates on the second device, the original device receives the Access Token, completing the grant.
• Documentation: Implement the Device Authorization grant flow.

Dependent & Specialized Flows and Grants

These flows (and grants) require a token or assertion obtained from one of the Primary Flows above.

Refresh Token Grant

• Use Case: Applications that require access to resources for an extended period without forcing the user to re-authenticate.
• Description: A refresh token is a credential artifact originally obtained during an initial user-authenticated flow (such as the Authorization Code Flow with PKCE or Interaction Code Flow). Once the initial flow is complete and the access token expires, the application uses this refresh token to obtain a new access token without further user interaction.
• Documentation: Refresh access tokens.

Identity Assertion Grant

• Use Case: Cross App Access (XAA) scenarios where an application needs to access resources in another application within the same trust domain without direct user interaction.
• Description: This flow is not a standalone authentication method; it requires a specialized identity assertion (the id-jag token) originally obtained via a Cross App Access flow. The application exchanges the assertion for a new Access Token to interact with a third-party API, using a common identity provider to bridge the trust between the independent applications. 
• Documentation: Cross App Access.

On-Behalf-Of (OBO) Token Exchange Grant

• Use Case: Service-to-service chaining in which a middle-tier API (Service A) calls a downstream API (Service B) while preserving the original user's identity and permissions.
• Description: This flow is not a standalone authentication method; it requires an existing Access Token (the "subject token") originally obtained via a user-facing flow (such as Authorization Code Flow with PKCE). The middle-tier service exchanges the incoming token for a new Access Token specifically scoped for the downstream service.
• Documentation: Set up On-Behalf-Of Token Exchange.

Native to Web SSO

• Use Case: Creates a seamless, unified authentication experience when a user transitions from an OIDC origin app (like a native mobile app) to a web app, either OIDC or Security Assertion Markup Language (SAML).
• Description: This flow allows an origin app to exchange an existing session token for a single-use interclient token. The native app launches the system browser and passes this token to the target web app's authorization URL to bootstrap the user's session without a second login.
• Documentation: Configure Native to Web SSO.

Native to Native SSO

• Use Case: Provides a seamless Single Sign-On (SSO)/Single Logout (SLO) experience across multiple independent native applications installed on the same device.
• Description: This flow uses the Token Exchange Grant to share authentication state. A primary app obtains a device_secret and id_token which a secondary app can exchange for its own tokens via the /token endpoint, mimicking web-based cookie sharing for native OS environments.
• Documentation: Configure SSO for Native apps.

SAML 2.0 Assertion Flow

• Use Case: Ideal for applications that already have a trust relationship with a SAML Identity Provider (IdP) and need to access OAuth-protected APIs without requiring the user to sign in again or provide direct consent. This is commonly used in hybrid environments where a user logs into a legacy system via SAML but needs to interact with modern OIDC/OAuth 2.0 resources.
• Description: This flow allows a client application to exchange a valid, signed SAML 2.0 Assertion for an OAuth 2.0 access token. The client first obtains the assertion from the SAML IdP and then presents it to the Okta /token endpoint using the urn:ietf:params:oauth:grant-type:saml2-bearer grant type. Okta validates the assertion's signature and trust before issuing tokens, effectively bridging the gap between SAML-based authentication and OAuth-based authorization.
• Documentation: Implement the SAML 2.0 Assertion grant.

Hybrid Flow

• Use Case: Server-side applications that can securely store secrets but need immediate access to an ID token before exchanging the code for an access token.
• Description: This flow is not a distinct standalone method but rather a combination of the Implicit Flow with Form Post and the Implement the Authorization Code flow. It allows the client to receive an ID token immediately from the authorization endpoint while simultaneously obtaining an authorization code that can later be exchanged for an Access Token.

Legacy/Discouraged Flows and Grants

Authorization Code Flow

• Use Case: Server-side web applications (for example, ASP.NET, Java, PHP, Node.js) where the code executes on a secure server. The Authorization Code Flow with PKCE is now preferred over this flow.
• Description: This flow was the standard method for controlling access to web applications capable of securely storing a client secret. The application exchanges an authorization code for an Access Token and ID Token directly with the authorization server, ensuring that the tokens are never exposed to the user agent.
• Documentation: Implement the Authorization Code flow.

Resource Owner Password Grant (ROPG)

• Use Case: Highly trusted legacy applications where no other flow is viable.
• Description: The user enters their username and password directly into the client application, which exchanges them for a token.
• Documentation: Implement the Resource Owner Password grant.

NOTE: This flow is strongly discouraged because it bypasses Multi-Factor Authentication (MFA) and Single Sign-On (SSO) flows and exposes user credentials to the client.

Implicit Flow

• Use Case: Historically used by Single-Page Applications (SPAs) that did not have a backend and could not securely store a client secret.
• Description: This flow returns tokens directly to the browser's address bar via a redirect. Because this exposes Access Tokens in the browser history and logs, it is strongly discouraged for modern applications. It has been superseded by the Authorization Code Flow with PKCE, which provides a more secure way to handle tokens in the browser.

NOTE: Highly susceptible to token theft and interception. Use only if maintaining legacy applications where no other flow is supported.