OAuth 2.0 / OpenID Connect (OIDC)

Overview

OAuth 2.0 is an authorization protocol that lets apps access user data securely without sharing credentials directly. Unlike SAML 2.0—a heavier, XML-based standard primarily designed for enterprise SSO — OAuth 2.0 is built around token-based delegated authorization, makes it a better fit for today’s needs:

  • Mobile & Web Applications: OAuth 2.0 fits well with apps that run on smartphones or in browsers.
  • APIs & Microservices: It enables granular, secure scope-based access control between small, interconnected services - broad adoption across a wide range of public and private APIs.
  • IoT & Cloud Services: Its lightweight token system works well for devices and cloud-based applications, where SAML’s heavy XML approach is impractical.
  • Development: Client libraries for OAuth 2.0/OIDC are widely available and simpler to use.

OAuth 2.0 is designed for authorization, meaning it controls what resources a user or application can access. It does not, by itself, verify the identity of a user. OpenID Connect (OIDC) is built on top of OAuth 2.0 and adds an identity layer. It introduces an ID token that carries information about the user, confirming who they are. This makes the login process safer and clearer, turning OAuth 2.0 into a tool that can handle both authorization and authentication when needed.

OAuth 2.0 & OIDC common use cases

The most common interactions in modern web ecosystems include browsers communicating with web applications, and web applications communicating with web APIs—sometimes on their own and sometimes on behalf of a user. In addition, browser-based, native, and server-based applications all interact with web APIs, while web APIs themselves often communicate with one another, again either autonomously or on behalf of a user.

OAuth 2.0 and OIDC are widely used to secure a variety of interactions between browsers, applications, and APIs by managing delegated authorization and user authentication. For instance:

  • When browsers communicate with web applications, OIDC is often used to authenticate users through third-party providers, enabling single sign-on (SSO) and a seamless login experience.

  • In scenarios where web or native applications interact with web APIs, OAuth 2.0’s authorization code flow—often enhanced with PKCE for public clients like mobile apps—is employed to grant access tokens securely on behalf of the user.

  • Similarly, browser-based single-page applications (SPAs) use these flows to safely access backend APIs.

  • In server-to-server communications, such as when a server-based application or one web API communicates with another, the client credentials flow is a common pattern since no user is directly involved.

Overall, these protocols ensure that whether an interaction involves a human user or is entirely machine-driven, both authentication (via OIDC) and fine-grained authorization (via OAuth 2.0) are robustly managed.

Supported profiles

Identify OAuth 2.0 supports multiple profiles, each designed for specific use cases and security needs. Below, we outline the supported profiles, when to use them, and provide links to relevant specifications and documentation.

Authorization Code Flow with PKCE

The Authorization Code Flow with PKCE is designed for secure authentication in web and mobile applications. It is commonly used when a user logs into a web or mobile app via an external identity provider. PKCE enhances security by preventing authorization code interception, making it essential for public clients where client secrets cannot be securely stored. Learn more from RFC 7636 - PKCE. For implementation details, see Implementing PKCE in Secure OAuth Workflows.

Client Credentials Flow

The Client Credentials Flow is used for machine-to-machine (M2M) authentication where no end-user is involved. It is ideal for APIs communicating with each other, such as microservices authentication. This flow provides a secure way for services to authenticate without user interaction. RFC 6749 - Client Credentials Grant provides further details. For implementation guidance, refer to Our Client Credentials Implementation Guide.

Device Authorization Flow

The Device Authorization Flow is used for devices with limited input capabilities, such as smart TVs and IoT devices. It allows users to log into services by confirming the login on a separate device, such as a mobile phone. This flow ensures a seamless and secure authentication experience for devices that cannot handle standard OAuth flows. More details are available in RFC 8628 - Device Authorization Grant. See Our Guide on Device Authorization Flow for implementation details.

Mutual TLS Client Authentication

Mutual TLS Client Authentication is designed for high-security environments where client authentication via certificates is required. It is widely used in financial services, government applications, and zero-trust networks where strict security measures are necessary. By using mutual TLS, both the client and server authenticate each other, reducing the risk of unauthorized access. Refer to RFC 8705 - OAuth 2.0 Mutual-TLS Client Authentication for specifications. More details can be found in Mutual TLS Setup and Best Practices.

Token Exchange

Token Exchange is used for secure delegation of access where a token from one security domain needs to be exchanged for another. This is useful in scenarios where a user authenticates with an identity provider, and their token needs to be exchanged for an API access token. Token exchange enables fine-grained control over token permissions and scopes across different services. More details are outlined in RFC 8693 - OAuth 2.0 Token Exchange. Learn more in Token Exchange in OAuth Workflows.

JWT Bearer Flow

The JWT Bearer Flow allows clients to obtain an OAuth 2.0 access token by presenting a signed JWT. This is useful in scenarios where a client already possesses a valid JWT (e.g., issued by an identity provider) and needs to exchange it for an OAuth access token to access APIs. It is commonly used in server-to-server authentication and delegated access scenarios. For more details, refer to RFC 7523 - OAuth 2.0 JWT Bearer Token Grant. See Our Guide on JWT Bearer Flow for implementation details.

SAML Bearer Flow

The SAML Bearer Flow allows clients to use a SAML assertion to obtain an OAuth 2.0 access token. This is beneficial in environments where SAML-based authentication is already in use, and applications need to integrate OAuth for API access. It is commonly used for federated identity scenarios where SAML assertions are issued by an identity provider and exchanged for OAuth tokens. More details are available in RFC 7522 - OAuth 2.0 SAML Bearer Assertion Flow. Learn more in SAML Bearer Flow Implementation Guide.

These profiles provide a flexible framework to support a wide range of application types and security requirements, ensuring that OAuth 2.0 and OIDC can be adapted to various contexts and needs.

Security

OAuth 2.0 and OpenID Connect (OIDC) provide powerful frameworks for authentication and authorization, but their complexity also introduces unique security challenges.

OAuth 2.0 faces security risks such as authorization code interception, where attackers steal codes if PKCE isn’t enforced. Open redirectors can lead users to malicious sites if redirect URIs aren’t properly validated. Cross-Site Scripting (XSS) remains a threat, allowing attackers to inject scripts and steal session tokens.

The Proof Key for Code Exchange (PKCE) enhances the security of the Authorization Code Flow by preventing attackers from intercepting authorization codes. PKCE is particularly important for public clients such as mobile apps and single-page applications (SPAs) that cannot securely store a client secret. Without PKCE, an attacker who intercepts an authorization code could potentially exchange it for an access token. For enhanced security, it is recommended to always enforce PKCE in authorization code grants and to use S256 hashing instead of plain text for PKCE challenge values.

For browser-based applications (SPAs), adopting the Backend for Frontend (BFF) pattern is recommended instead of handling tokens directly in the frontend. Managing OAuth tokens in client-side JavaScript increases the risk of token theft through cross-site scripting (XSS) attacks.

These examples illustrate that while OAuth/OIDC are invaluable for modern identity management, developers must implement diligent security measures to mitigate these well-documented attacks with the OAuth best current practices.

Learn more

Key Components of an OAuth 2.0 / OIDC Application

Endpoints

The most used endpoints are for the authorization process and token management:

  • Authorization endpoint: Used to interact with the resource owner and obtain an authorization grant. The client gets the authorization code through this endpoint.
  • Token endpoint: After obtaining the authorization code, the client exchanges it at this endpoint for an access token, and optionally, a refresh token and ID token.
  • User information endpoint: Retrieves information about the user's profile using the access token obtained from the token endpoint.
  • Registration endpoint: Allows clients to dynamically register with the authorization server, following the implementation of RFC 7591.
  • OIO OIDC (OpenID Connect for the Danish public sector) is an identity and authentication standard based on OpenID Connect (OIDC), customized for use in Denmark’s government and public sector digital services.
  • Token revocation & introspection endpoints: These endpoints allow clients to revoke tokens when they are no longer needed and inspect tokens to determine their validity and metadata. The token revocation endpoint invalidates tokens, while the token introspection endpoint checks the active state and metadata of a token.
  • Logout endpoint: Allow a Relying Party — typically an application — to initiate a logout request and redirect the user to the Identify OIDC server to terminate the session.

These endpoints ensure secure and efficient management of authentication and authorization for applications using OAuth 2.0 and OIDC protocols.

Advanced topics

Advanced topics cover client credentials, device, and hybrid flows, as well as security and session management.