On this page
OAuth 2.0 and OpenID Connect overview
OAuth 2.0 and OpenID Connect (OIDC) are industry standard protocols for user authentication and authorization. Okta identity solutions are based on these standards.
- Learn how to implement flows based on OAuth 2.0 and OIDC using Okta.
- Learn which flows and grant types are commonly used by different types of applications.
Note: To learn about the Okta authentication deployment models built on top of OAuth 2.0 and OIDC, see Okta deployment models.
OAuth 2.0 and OpenID Connect (OIDC) are complementary protocols, defining how users are authenticated by a server and then authorized to access resources:
- OAuth 2.0 controls and delegates authorization to access a protected resource, like your web app, native app, or API service. It provides API security through scoped access tokens.
- OIDC extends OAuth 2.0 with user authentication and Single Sign-On (SSO) functionality. It enables you to retrieve and store authentication information about your end users. It also defines several OAuth 2.0 scopes to enable applications to access user profile information.
Okta recommends using one of its authentication deployment models for your application's authentication needs. Each model abstracts over the OAuth 2.0 and OIDC protocols, so you don't have to use them directly. To get started and to find sample apps, see Sign users in.
Tip: Use the Authentication API if you require a custom app setup and workflow with direct access to your Okta org and app integrations. This API underpins both the Okta redirect model, Embedded Sign-In Widget, and Auth JS SDKs.
OAuth 2.0 is a standard that apps use to provide client applications with access. If you would like to grant access to your application data in a secure way, then you want to use the OAuth 2.0 protocol.
The OAuth 2.0 spec has four important roles:
- client: The application that wants to access some data.
- resource server: The API or application that stores the data the client wants to access.
- resource owner: The owner of the data on the resource server. For example, you're the owner of your Facebook profile.
- authorization server: The server that manages access and issues access tokens. In this case, Okta is the authorization server.
Other important terms:
- OAuth 2.0 grant: The authorization given (or granted) to the client by the user. Examples of grants are Authorization Code and Client Credentials. Each OAuth grant has a corresponding flow. See Choose an OAuth 2.0 flow.
- access token: The token issued by the authorization server (Okta) in exchange for the grant.
- refresh token: An optional token that is exchanged for a new access token if the access token has expired.
Note: For more information on hard-coded and configurable token lifetimes, see Token lifetime.
The usual OAuth 2.0 authorization code flow looks like this:
- The client requests authorization from the resource owner (usually the user).
- If the owner gives authorization, the client passes the authorization grant to the authorization server (in this case Okta).
- If the grant is valid, the authorization server returns an access token, possibly alongside a refresh and/or ID token.
- The client now uses that access token to access the resource server.
At the core of both OAuth 2.0 and OIDC is the authorization server. An authorization server is simply an OAuth 2.0 token minting engine. Each authorization server has a unique issuer URI and its own signing key for tokens to keep a proper boundary between security domains. In the context of this guide, Okta is your authorization server.
Note: For information on authorization servers, how they work, and how you can use them, see Authorization servers.
OpenID Connect (OIDC) is an authentication standard built on top of OAuth 2.0. It defines an ID token type to pair with OAuth 2.0 access and refresh tokens. OIDC also standardizes areas that OAuth 2.0 leaves up to choice, such as scopes, endpoint discovery, and the dynamic registration of clients. Okta is OpenID Certified (opens new window).
Although OIDC extends OAuth 2.0, the OIDC specification (opens new window) uses slightly different terms for the roles in the flows:
- OpenID provider: The authorization server that issues the ID token. In this case Okta is the OpenID provider.
- end user: The end user's information that is contained in the ID token.
- relying party: The client application that requests the ID token from Okta.
- ID token: The token issued by the OpenID provider that contains information about the end user in the form of claims.
- claim: The claim is a piece of information about the end user.
The high-level flow looks the same for both OpenID Connect and regular OAuth 2.0 flows. The primary difference is that an OpenID Connect flow results in an ID token, in addition to any access or refresh tokens.
The OAuth flow that you use depends on your use case. The following sections recommend OAuth 2.0 flows based on:
- The type of application that you're building and the token types that the application requires
- The type of client that you're building
The following table shows you which OAuth 2.0 flow to use for the type of application that you're building.
|Type of application
|OAuth 2.0 flow / grant type
|Server-side (aka web),
|Authorization Code with PKCE or
Interaction Code (Identity Engine only).
Note: There's also an OAuth 2.0 SAML 2.0 Assertion flow. This flow is intended for client applications that want to use an existing trust relationship without a direct user approval step at the authorization server. It supports access and ID tokens.
The type of OAuth 2.0 flow depends on what kind of client that you're building. This flowchart can quickly help you decide which flow to use.
Single-Page Applications (SPAs), mobile, and native applications are public applications where end users can view and possibly modify the source code of the application. Any secrets in the code are exposed to malicious users. By comparison, server-side (web) and desktop applications are confidential or private applications. Confidential clients can use client-side authentication methods such as client secrets and private keys.
If your client application is a SPA or a native application that redirects its authentication requests to an Okta-hosted sign-in page (the redirect model), use the Authorization Code flow with PKCE. If your application hosts the authentication flow itself (the embedded model), use the Interaction Code flow.
If your client application runs on a server with no direct end user, then it can be trusted with its own credentials and to use them responsibly. If your client application is only doing machine-to-machine interaction, then you should use the Client Credentials flow.
An application is high-trust if you own both it and the resource that it accesses. Because you own both, you can trust the application to handle your end users' usernames and passwords. In this case, and only if other flows aren't viable, you can use the Resource Owner Password flow. However, it isn't possible to use this flow with multifactor authentication, so consider alternatives such as the Authorization Code or Interaction Code flow.
If your app isn't high-trust, or if you want to take advantage of multifactor authentication, you should use the Authorization Code flow.
Proof Key for Code Exchange (PKCE) was originally designed as an extension to protect the Authorization Code flow in mobile apps. However, its ability to prevent authorization code injection and keep the flow secure makes it optimal for every type of OAuth client. Okta recommends that you use the Authorization Code flow with PKCE for your OAuth client, if possible.
The flow requires your application to generate a cryptographically random string called a code verifier. The code verifier is then hashed to create the code challenge, and this challenge is passed along with the request for the authorization code. The authorization server responds with an authorization code and associates the code challenge with the authorization code.
After the application receives the authorization code, it sends the authorization code and the code verifier in a request for an access token. The authorization server recomputes the challenge from the verifier using the previously agreed-upon hash algorithm and then compares the challenge with the one it associated with the authorization code in the previous step. If the two code challenges and verifier match, the authorization server knows that the same client sent both requests.
Note: For implementing refresh tokens with SPAs and other browser-based apps, see Refresh access tokens.
For information on how to set up your application to use this flow, see Implement the Authorization Code flow with PKCE.
The Interaction Code flow extends the OAuth 2.0 and OIDC standards. It requires clients to pass a client ID and PKCE parameters to Okta to keep the flow secure. The user can start the request with minimal information, relying on the client to facilitate the interactions with Okta to authenticate the user. See Interaction Code grant type.
Note: Interaction Code flow is only available in Identity Engine orgs.
The Resource Owner Password flow is intended for use cases where:
- You control both the client application and the resource that it's interacting with.
- The client can store a client secret and can be trusted with the resource owner's credentials.
- You don't need your users to use multifactor authentication.
It's most commonly found in first-party clients made for online services, like the Facebook client applications that interact with the Facebook service. It doesn't require redirects like the Authorization Code or Implicit flows, and involves a single authenticated call to the
For information on how to set up your application to use this flow, see Implement the Resource Owner Password flow.
The Client Credentials flow is intended for server-side (confidential) client applications with no end user. Normally, this means machine-to-machine communication. The application must be server-side because it must be trusted with the client secret, and since the credentials are hard-coded, an actual end user can't use it. It involves a single, authenticated request to the
/token endpoint, which returns an access token.
Note: The Client Credentials flow doesn't support refresh tokens.
For information on how to set up your application to use this flow, see Implement the Client Credentials flow.
The SAML 2.0 Assertion flow is intended for a client app that wants to use an existing trust relationship without a direct user approval step at the authorization server. It enables a client application to obtain an authorization from a valid, signed SAML assertion from the SAML Identity Provider. The client app can then exchange it for an OAuth access token from the OAuth authorization server. For example, this flow is useful when you want to fetch data from APIs that only support delegated permissions without prompting the user for credentials.
To use a SAML 2.0 Assertion as an authorization grant, the client makes a SAML request to the Identity Provider and the Identity Provider sends the SAML 2.0 Assertion back in the response. The client then makes a request for an access token with the
urn:ietf:params:oauth:grant-type:saml2-bearer grant type and includes the
assertion parameter. The value of the
assertion parameter is the SAML 2.0 Assertion that is Base64-encoded. You can send only one SAML assertion in that request.
For information on how to set up your application to use this flow, see Implement the SAML 2.0 Assertion flow.
Note: The Implicit flow is a legacy flow used only for SPAs that can't support PKCE.
The Implicit flow was intended for browser-based applications that didn't support Cross-Origin Resource Sharing (CORS), lacked modern cryptography APIs, and that couldn't protect a client secret. In this flow, the client doesn't make a request to the
/token endpoint, but instead receives the access token in the redirect from the
/authorize endpoint. The client must be able to interact with the resource owner's user agent and to receive incoming requests (through redirection) from the authorization server.
Note: Because it was always intended for less-trusted clients, the Implicit flow doesn't support refresh tokens.
Important: For Single-Page Applications (SPA) running in modern browsers that support Web Crypto for PKCE, Okta recommends using the Authorization Code flow with PKCE instead of the Implicit flow for maximum security. If support for older browsers is required, the Implicit flow provides a functional solution.
For information on how to set up your application to use this flow, see Implement the Implicit flow.