OIDC Overview

OpenID Connect (OIDC) is an identity authentication layer built on top of OAuth 2.0. A one-sentence summary of their division of labor:

OAuth 2.0 handles authorization; OIDC adds authentication.

OAuth 2.0 solves the problem: "how can application A access a user's resources on service B with the user's permission?" Its product is the access token—a "resource access credential." However, OAuth 2.0 itself does not answer the question "who is the current user?" OIDC layers a standardized identity assertion mechanism onto OAuth 2.0's authorization flow. Its core product is the ID Token—a JWT (JSON Web Token, a self-contained, cryptographically signed token format) signed by the identity provider, carrying information like "who authenticated, when, at which IdP, for which client."

OIDC's Position in the Protocol Stack

┌─────────────────────────────────────┐
│  OIDC  (Authentication: who)        │
├─────────────────────────────────────┤
│  OAuth 2.0  (Authorization: access) │
├─────────────────────────────────────┤
│  HTTP / TLS                         │
└─────────────────────────────────────┘

OIDC reuses OAuth 2.0's endpoints (authorization endpoint, token endpoint), flows (authorization code flow, etc.), and security mechanisms (state, redirect_uri validation), with only minor extensions:

• Add openid to the scope when requesting authorization, indicating "this is an authentication request";
• In the token response, return id_token in addition to access_token;
• Add supporting infrastructure such as UserInfo Endpoint and Discovery.

If you're already familiar with OAuth 2.0 (see OAuth 2.0 documentation), the incremental learning cost for OIDC is very low.

Specification Family

OIDC is not a single specification, but a family of specifications:

In engineering practice, the most common combination is Core + Discovery + RP-Initiated Logout; add Front/Back-Channel Logout as needed for single sign-out scenarios (Back-Channel is more reliable, not affected by browser third-party cookie restrictions).

Why Not Use Bare OAuth 2.0 for Login

Before OIDC standardization, many "third-party logins" were implemented this way: run through OAuth 2.0 to get an access token, then call a private "get user info" endpoint, and treat the returned user ID as the login identity. This approach has fundamental flaws:

OIDC's ID Token eliminates such problems by design:

• The aud claim binds the target client; RP must verify aud is its own client_id, and tokens from other parties are rejected;
• The iss claim identifies the issuer; combined with signature verification, it confirms the token truly comes from a trusted OP and is unaltered;
• nonce binds the token to a specific authentication session, preventing replay attacks;
• exp/iat/auth_time provide time validity and authentication time information.

Furthermore, bare OAuth2 implementations have wildly varied "user info endpoint" fields. OIDC standardizes this layer with standard Claims (sub, name, email, etc.), allowing a single RP implementation to interoperate with any compliant OP.

Applicable Scenarios

• User login for web apps / SPAs / mobile apps: Integrating with enterprise IdPs (such as Keycloak, Azure AD / Entra ID, Okta) or social login (Google, Apple, etc.).
• Single sign-on (SSO): Multiple applications share the same OP's login session; one login, access everywhere.
• Login + API authorization in one go: A single authorization code flow obtains both ID Token (login) and access token (calling backend API), a significant advantage of OIDC over SAML.
• Microservices / cloud-native unified identity: Service gateways validate JWTs; identity information propagates with requests.
• CIAM (Customer Identity and Access Management): Large-scale B2C user registration and login systems.

OIDC vs. SAML

SAML 2.0 (Security Assertion Markup Language, an XML-based identity federation protocol) is the de facto standard for the previous generation of enterprise SSO. The two are positioned similarly but have very different characteristics:

Simple decision: choose OIDC for new projects; only use SAML when the counterparty (usually legacy enterprise software) supports only SAML. See SAML documentation for details.

Chapter Navigation

• Core Concepts — OP/RP roles, ID Token structure and validation, standard scopes and claims, Discovery, JWKS, logout mechanisms
• Typical Flows — Complete step-by-step authorization code flow example, comparison of three response_type values, Discovery/JWKS retrieval, RP-Initiated Logout
• Typical Parameters and Claims Reference — Authentication request parameters, ID Token claims, standard claims, prompt values, error codes and troubleshooting quick reference