Short definition
OpenID Connect (OIDC) is an identity layer built on top of the OAuth 2.0 authorization framework. It allows applications to verify the identity of a user through an identity provider and retrieve basic profile information in a standardized way. The result is a signed ID token that the application can inspect and trust without managing passwords itself.
Extended definition
OAuth 2.0 was designed for delegated authorization, meaning it controls what an application is allowed to do on behalf of a user. It was never designed to tell an application who that user actually is. OpenID Connect fills that gap by adding a thin authentication layer on top of OAuth 2.0, introducing the ID token, the UserInfo endpoint, and a set of standardized scopes for retrieving identity data.
When a user authenticates through an OIDC flow, the identity provider issues an ID token in JSON Web Token (JWT) format. That token contains claims: structured fields such as the subject identifier, the issuer, the audience, and the token expiry time. Applications validate the token cryptographically before trusting its contents, so there is no round-trip to a session store for every request.
OIDC is the foundation for single sign-on (SSO) across modern web and mobile applications. Enterprise identity providers such as Okta, Azure Active Directory, Google Workspace, and Keycloak all expose OIDC endpoints. Any application that speaks the protocol can integrate with any of these providers without custom authentication code.
Developers choose OIDC because it separates authentication concerns from application logic. The identity provider handles credential storage, multi-factor authentication, and session management. The application only needs to validate a token. This boundary reduces attack surface and simplifies compliance audits, since credential handling is delegated to a specialized system.
Deep technical explanation
The authorization code flow
The most common OIDC flow is the authorization code flow with PKCE (Proof Key for Code Exchange). The client redirects the user to the identity provider’s authorization endpoint with parameters including client_id, redirect_uri, response_type=code, scope=openid, and a PKCE code challenge. After the user authenticates, the provider redirects back with a short-lived authorization code.
The client exchanges that code for tokens at the token endpoint, presenting the PKCE verifier to prove it initiated the request. The response contains an ID token, an access token, and optionally a refresh token. The ID token is a signed JWT. The client validates the signature against the provider’s public keys, which are published at a well-known JWKS URI.
ID token structure and claims
An ID token has three base64url-encoded sections: a header specifying the signing algorithm, a payload containing the claims, and a signature. Standard claims include iss (issuer), sub (subject, a stable unique user identifier), aud (intended audience), exp (expiry), and iat (issued at). Providers add custom claims for email, name, roles, and tenant identifiers depending on configuration.
The sub claim is the correct field to use as a stable user identifier inside your database. Email addresses can change; the sub value for a given provider and user combination does not. This distinction matters when building user tables that need to survive account updates.
Discovery and provider metadata
OIDC defines a discovery document published at /.well-known/openid-configuration on the provider’s domain. This document lists all endpoints, supported scopes, supported signing algorithms, and the JWKS URI. Client libraries fetch this document at startup to configure themselves automatically, which eliminates hardcoded endpoint URLs and makes provider migrations less painful.
Common failure modes
Clock skew between the client and the provider causes token validation to fail when the exp or iat claims fall outside an acceptable window. Libraries allow a small tolerance, typically 60 seconds, but servers with drifted clocks will produce intermittent authentication failures that are hard to reproduce. Token audience mismatches are another common source of errors: if the aud claim does not match the client’s registered client_id, the token must be rejected.
Refresh token rotation is an edge case that breaks mobile apps when background syncs race against each other. If two simultaneous requests both attempt to use the same refresh token, the second will be rejected after the first has already rotated it. Applications need to serialize refresh operations or handle the resulting 400 error by triggering a full re-authentication.
Practical examples
SaaS application SSO
A B2B SaaS platform needed to let enterprise customers authenticate with their own identity providers. The team integrated OIDC using the authorization code flow with PKCE. Each customer provided their provider’s discovery URL and client credentials. The platform extracted the sub and email claims from the ID token to map users to accounts, eliminating the need to manage passwords for enterprise users.
Internal tooling with Google Workspace
An engineering team needed to restrict access to internal dashboards to company employees only. They configured OIDC login against Google Workspace, validating the hd (hosted domain) claim on every ID token to ensure only users from the company’s domain could authenticate. Non-employees received a 403 before reaching the application.
Microservices token propagation
A platform with multiple backend services needed a consistent way to propagate user identity across service calls. The API gateway validated the OIDC ID token on each incoming request and forwarded the sub and role claims as trusted headers to downstream services. Each downstream service consumed those headers directly without performing its own token validation, reducing latency.
Mobile application authentication
A React Native application integrated OIDC using the authorization code flow with PKCE via a system browser. Redirecting to a system browser instead of an embedded WebView prevented credential phishing by ensuring the identity provider rendered in a trusted context. The refresh token was stored in the device’s secure keychain with rotation enabled.
Why it matters
- OIDC removes password management from application code, reducing the attack surface for credential theft and simplifying security audits.
- The ID token’s cryptographic signature means applications can validate user identity locally without a database lookup on every request.
- Provider-side MFA enforcement means any application using OIDC automatically inherits the organization’s authentication policies without code changes.
- Standardized claims and discovery documents make it straightforward to switch identity providers or support multiple providers in parallel.
- OIDC is the standard expected by enterprise procurement teams, so supporting it is often a prerequisite for closing B2B deals.
- PKCE eliminates the authorization code interception attack for public clients, making OIDC safe for mobile and single-page applications without a client secret.