Category: Identity and Access Management
OpenID Connect
Also known as: OIDC, OpenID Connect 1.0
Simply put
OpenID Connect is an identity protocol built on top of OAuth 2.0 that allows applications to verify who a user is. It is widely used to enable single sign-on across different websites and services. Applications receive structured identity information about authenticated users through standardized tokens.
Formal definition
OpenID Connect 1.0 is an identity layer on top of the OAuth 2.0 protocol that enables relying party clients to verify the identity of an end-user based on authentication performed by an authorization server. It extends OAuth 2.0's authorization mechanisms to support authentication, introducing the ID token as a signed artifact carrying identity claims about the authenticated subject. OIDC is the leading internet standard for cross-domain single sign-on and is used to authenticate users for access to protected endpoints, providing a standardized way for clients to obtain verifiable identity assertions in addition to OAuth 2.0 access tokens.
Why it matters
OpenID Connect addresses a foundational challenge in modern application security: verifying who a user is in a standardized, interoperable way across different domains and services. Before widely adopted identity protocols like OIDC, applications typically implemented authentication independently, leading to fragmented credential stores, inconsistent security controls, and repeated exposure of user passwords to multiple parties. By building on the established OAuth 2.0 framework and introducing a dedicated identity layer, OIDC provides a structured mechanism for delegating authentication to a trusted authorization server while giving relying party applications verifiable, signed assertions about the authenticated user.
Who it's relevant to
Application Developers
Developers building web, mobile, or API-backed applications use OIDC to integrate single sign-on and delegate authentication to a trusted identity provider rather than managing credentials directly. Understanding the ID token structure, claim validation requirements, and the distinction between authentication flows is important for implementing OIDC correctly and avoiding common misconfigurations.
Security Engineers and Architects
Security engineers evaluating identity infrastructure need to assess how OIDC is configured across relying parties and authorization servers, including token validation logic, redirect URI handling, and scope definitions. Architectural decisions around which OIDC flows to use, how tokens are stored, and how sessions are managed have direct impact on the application's overall authentication security posture.
Identity and Access Management (IAM) Teams
IAM teams are typically responsible for operating or selecting the authorization servers that issue OIDC tokens and for defining the identity claims available to relying parties. They must ensure that authentication policies, user attribute mappings, and token lifetimes are configured consistently across the services that depend on the identity provider.
Penetration Testers and Application Security Reviewers
Security reviewers testing applications that implement OIDC should examine token validation behavior, redirect URI whitelisting, state parameter handling, and how applications distinguish between ID tokens and access tokens. Misimplementations of the protocol, such as accepting unvalidated tokens or conflating authorization with authentication, are categories of issues that may appear in code review or dynamic testing of OIDC-integrated applications.
Enterprise IT and Cloud Administrators
Administrators deploying cloud platforms and enterprise software increasingly encounter OIDC as the standard mechanism for federating user identities across services, including integrations with major identity providers. Correct configuration of trusted issuers, audience restrictions, and claim mappings is relevant to both access control enforcement and audit logging.
Inside OIDC
ID Token
A signed JWT issued by the OpenID Provider that contains claims about the authenticated end-user, including a subject identifier, issuer, audience, expiration time, and issuance time. It represents proof of authentication and is intended for consumption by the relying party, not for use as an API access credential.
UserInfo Endpoint
A protected OAuth 2.0 resource endpoint exposed by the OpenID Provider that returns additional claims about the authenticated user when queried with a valid access token. It supplements the ID token with extended profile information without bloating the token itself.
OpenID Provider (OP)
The authorization server that implements the OpenID Connect protocol, authenticates end-users, and issues ID tokens and access tokens to relying parties. It is responsible for maintaining the authentication event and publishing discovery metadata.
Relying Party (RP)
The client application that delegates user authentication to an OpenID Provider and consumes the resulting ID token to establish a local session. The relying party must validate the ID token signature, issuer, audience, and expiration before trusting its contents.
Claims
Key-value pairs embedded in the ID token or returned from the UserInfo endpoint that convey information about the end-user and the authentication event. Standard claims include subject identifier (sub), email, name, and authentication time (auth_time), among others defined in the specification.
Discovery Document
A JSON document published by the OpenID Provider at a well-known URL that exposes provider metadata, including the authorization endpoint, token endpoint, UserInfo endpoint, supported scopes, and public key locations. Relying parties use it to configure themselves dynamically rather than through manual coordination.
Nonce
A random value included by the relying party in the authentication request and embedded by the OpenID Provider in the issued ID token. It is used to bind the token to a specific authentication request, mitigating replay attacks and certain token substitution attacks.
Scopes
OAuth 2.0 scope values that control which sets of claims are requested from the OpenID Provider. The 'openid' scope is required to trigger OpenID Connect behavior, while additional scopes such as 'profile', 'email', and 'address' request corresponding claim sets.
Authorization Code Flow
The primary flow defined in OpenID Connect in which the relying party receives an authorization code at its redirect URI, then exchanges it for tokens at the token endpoint using a confidential back-channel request. This flow is recommended for server-side applications because it avoids exposing tokens in the browser.
JWKS (JSON Web Key Set) Endpoint
A URL published by the OpenID Provider that exposes its current public signing keys in JWK format. Relying parties retrieve these keys to verify the cryptographic signatures on ID tokens.
Common questions
Answers to the questions practitioners most commonly ask about OIDC.
Does OpenID Connect handle authorization, or is it only for authentication?
OpenID Connect is an authentication protocol, not an authorization protocol. It verifies who a user is and provides identity assertions via an ID token. Authorization decisions, meaning what a user is permitted to do, are out of scope for OpenID Connect itself. For delegated authorization, OAuth 2.0 (on which OpenID Connect is layered) handles access delegation, but granular permission enforcement typically requires a separate authorization mechanism.
Does receiving an ID token mean a user is authorized to access a resource?
No. An ID token confirms the identity of the authenticated user but does not grant authorization to any resource. Applications must implement their own access control logic to determine whether an authenticated identity is permitted to perform a given action. Treating a valid ID token as proof of authorization is a common and dangerous misconception.
How should an application validate an ID token in practice?
Applications must validate the ID token's signature using the provider's published public keys, typically retrieved from the provider's JWKS endpoint. They must also verify the 'iss' (issuer) claim matches the expected provider, the 'aud' (audience) claim matches the application's client ID, the 'exp' (expiration) claim has not passed, and, where applicable, the 'nonce' claim matches the value sent in the authentication request to prevent replay attacks.
What is the difference between the ID token and the UserInfo endpoint, and which should be used for user data?
The ID token is a signed JWT returned directly in the authentication response and contains a baseline set of claims about the authenticated user. The UserInfo endpoint is a protected resource that can return additional or more current user attributes when queried with an access token. For security-sensitive decisions, the signed ID token is generally preferred because its integrity is cryptographically verifiable. The UserInfo endpoint may return more complete profile data but requires a separate authenticated request and its response is not itself signed in most implementations.
Which OpenID Connect flow is appropriate for server-side web applications versus single-page applications?
Server-side web applications typically use the Authorization Code flow, which exchanges a short-lived authorization code for tokens server-side, keeping tokens out of the browser. Single-page applications should use the Authorization Code flow with PKCE (Proof Key for Code Exchange), which protects the code exchange without requiring a client secret, since secrets cannot be safely stored in browser environments. The Implicit flow, which returned tokens directly in the URL fragment, is deprecated for most use cases due to security concerns including token exposure in browser history and referrer headers.
How should applications handle OpenID Connect session termination and logout?
OpenID Connect defines optional specifications for logout, including RP-Initiated Logout, Front-Channel Logout, and Back-Channel Logout. RP-Initiated Logout redirects the user to the provider to end the provider session. Front-Channel Logout uses embedded iframes to notify other relying parties but is fragile in modern browsers due to cookie restrictions. Back-Channel Logout sends server-to-server notifications and is generally more reliable. Applications must also invalidate their own local sessions independently, since ending the provider session does not automatically terminate active sessions at relying parties unless those parties implement and respond to logout notifications.
Common misconceptions
OpenID Connect and OAuth 2.0 are interchangeable and serve the same purpose.
OAuth 2.0 is an authorization framework designed to grant delegated access to resources and does not define how to authenticate users or convey user identity. OpenID Connect is a distinct identity layer built on top of OAuth 2.0 that adds the ID token, standardized claims, and user authentication semantics. Using an OAuth 2.0 access token to determine who a user is, without the OpenID Connect layer, is a common and risky misuse pattern.
The ID token can be used as a credential to call APIs on behalf of the user.
The ID token is intended solely for the relying party to verify the authentication event and learn about the user. It should not be sent to resource servers as an API credential. The access token issued alongside the ID token is the appropriate credential for calling protected APIs, and the two tokens have distinct intended audiences and lifetimes.
Receiving a valid ID token is sufficient proof of a successful authentication without further validation.
A relying party must perform several explicit validation steps on the ID token before trusting it, including verifying the cryptographic signature against the provider's published keys, confirming the issuer matches the expected OpenID Provider, confirming the audience contains the relying party's client identifier, checking the expiration time, and validating the nonce if one was sent in the request. Skipping any of these steps can expose the application to token substitution, replay, or spoofing attacks.
Best practices
Always validate the ID token fully on the server side before establishing a session, including signature verification against the OpenID Provider's current JWKS, issuer confirmation, audience confirmation, expiration check, and nonce binding verification.
Use the Authorization Code Flow with PKCE for all relying party implementations, including single-page applications, to prevent authorization code interception and avoid exposing tokens in the browser's URL or history.
Never use the ID token as an access credential for API calls. Pass the access token to resource servers and reserve the ID token for the relying party's internal session establishment only.
Consume the OpenID Provider's discovery document dynamically to configure endpoints and key locations rather than hardcoding them, so that key rotations and endpoint changes are handled automatically without manual intervention.
Implement short session lifetimes and leverage the OpenID Connect session management or back-channel logout specifications so that user sessions in the relying party are terminated promptly when the user logs out at the OpenID Provider.
Restrict the scopes and claims requested to only those necessary for the application's function, reducing the sensitivity of data handled by the relying party and limiting exposure if tokens are logged or leaked.