OpenID Connect (OIDC) is an identity layer built on top of OAuth 2.0, enabling applications to authenticate users and obtain their profile information. OAuth 2.0 handles authorization (what a user can access), OIDC adds authentication (who the user is) using standardized ID tokens.

Example: When you click “Continue with Google” to sign in to Spotify, OIDC verifies your identity with Google. Spotify receives your profile information, like your name and email. Your Google password is never shared. Google issues an ID token containing identity claims, like your user ID and profile information. Some claims (like email verification) are explicitly marked as verified.

OIDC has become widely adopted for modern web and mobile authentication. Published in 2014 by the OpenID Foundation, it combines OAuth 2.0 authorization with identity verification. Major identity providers support OIDC, making it commonly used for Single Sign-On (SSO), social login, and consumer applications.

Before OIDC, developers faced three main challenges:

1. Lack of a Standard Identity Layer

   OAuth 2.0 provides authorization but does not define a standardized or interoperable authentication method. As a result, developers created custom solutions, leading to interoperability issues.

2. Complex Alternatives

   SAML 2.0 supports enterprise authentication but uses verbose XML, requires certificates, and works poorly on mobile devices.

3. Credential Exposure Risks

   In the past, applications often stored user credentials or required password sharing, which created security risks and a subpar user experience.

OIDC addresses these issues. Applications receive cryptographically signed ID tokens with asserted identity claims. Credential storage is no longer necessary, and authentication is consistent across platforms. OIDC authenticates users but does not manage application-specific user data, roles, or permissions.

OIDC builds on OAuth 2.0 roles, identity-specific terminology:

• End User: The person whose identity is being verified
• Relying Party (RP): The application requesting user authentication
• OpenID Provider (OP): The identity provider that authenticates users and issues ID tokens. In OIDC, the OP functions as the OAuth 2.0 Authorization Server

ID Token Claims

ID tokens are JSON Web Tokens (JWTs) that contain identity claims and must be validated before use:

• sub: Stable, unique identifier for the user within the issuer
• iss: Token issuer (OpenID Provider URL)
  aud: Intended application (client ID)
• exp: Expiration time (Unix timestamp)
• iat: Issued at time (Unix timestamp)
• auth_time: Authentication timestamp
• nonce: Prevents replay attacks (required if sent in request)

Common OIDC Scopes

Scopes define the requested user information:

• openid: Required; triggers OIDC
• profile: Name, picture, and basic profile info
• email: Email address and verification
• address: Physical address
• phone: Phone number and verification

Since OIDC extends OAuth 2.0, the flow is similar to OAuth’s authorization code flow with OIDC-specific additions.

The OIDC Authentication Flow

1. Authentication Request: RP redirects the user to OP with client ID, redirect URI, response_type=code, and scope including openid.
2. User Authentication and Consent: OP authenticates the user with a password, MFA, or biometric. Consent screen shows requested data.
3. Authorization Response: OP redirects back with an authorization code and state parameter.
   Token Request: RP exchanges a code for three tokens: an ID token, an access token, and an optional refresh token. Confidential clients do this server-to-server. Public clients use PKCE.
4. Token Validation: RP validates ID token signature, expiration, issuer, audience, and nonce using the provider’s public keys (JWKS). The ID token is for the client application only and must never be sent to APIs. APIs should validate access tokens instead.
5. User Profile Access: Optionally, RP calls the UserInfo endpoint with an access token to retrieve additional profile claims.

Proof Key for Code Exchange (PKCE)

PKCE prevents authorization code interception attacks. Public clients (mobile apps and SPAs) use PKCE since they cannot securely store client secrets. Confidential clients typically authenticate with a client secret. Many modern deployments also add PKCE for defense-in-depth.

Determining which flow to use:

Flow	Use Case	Security	Status
Authorization Code with PKCE	All modern apps (Web, mobile, SPAs)	Highest	Recommended for all clients
Implicit Flow	None	Low	Deprecated (RFC 8252)
Hybrid Flow	Complex enterprise	Medium	Legacy only

• Authorization Code with PKCE is the recommended best practice and is expected to be mandatory in OAuth 2.1.
• Implicit Flow is deprecated due to security vulnerabilities.
• Hybrid Flow is mainly used in legacy or specialized enterprise scenarios and is generally unnecessary for most modern applications.

ID Token Validation

ID tokens must be validated for signature, expiration, issuer, audience, and nonce.

Validation steps:

• Verify signature using JWKS keys
• Check that the issuer matches the provider
• Verify audience matches the client ID
• Confirm the token has not expired
• Validate nonce matches the request

Best practice: Use established OIDC libraries that handle validation.

Nonce Handling

Nonce prevents replay attacks. An attacker could replay a valid ID token without a nonce. Predictable, reused, or unverified nonces are insecure.

Best practice: Generate cryptographically random nonces, store them server-side with TTL (5–10 minutes), and validate exact matches.

Token Storage

ID tokens contain sensitive information — never use localStorage or sessionStorage due to cross-site scripting (XSS) vulnerabilities.

Best practice: Use in-memory storage for SPAs or secure, HTTP-only cookies when using a backend-for-frontend (BFF) pattern. Server-side encrypted sessions are safer.

Scope Requests

Request only the scopes your app needs. Avoid unnecessary profile data.

UserInfo Endpoint Usage

Only call UserInfo if the ID token is missing the required claims. The endpoint requires an access token and is often rate-limited. Always validate access tokens and cache responses as needed.

OIDC works best for consumer-facing applications, mobile apps, and modern web authentication. Choose OIDC for social login, SSO, and scenarios where users authenticate with existing accounts.

SAML 2.0 remains common in legacy enterprise and government systems, while many organizations increasingly adopt OIDC for new workforce applications. Many organizations use both: OIDC for modern apps and SAML for enterprise federation.

• Validate ID Tokens completely using JWKS keys. Verify the signature, exp, iss, aud, and nonce. (ID tokens must never be sent to APIs.)
• Use HTTPS for all production communications. RFC 6749 allows localhost exceptions for development only.
• Implement PKCE for all clients. (Expected to be mandatory in OAuth 2.1)
• Secure Token Storage with HTTP-only cookies or server-side sessions.
• Validate Redirect URIs explicitly. Never use wildcards.
• Implement the State Parameter to prevent CSRF attacks.
• Use Short-Lived Tokens (15–60 minutes) and refresh tokens with rotation.
• Respect User Consent and minimize requested profile data.

Aspect	OIDC	OAuth 2.0	SAML 2.0
Purpose	Authentication	Authorization	Authentication and SSO
Built On	OAuth 2.0	IETF OAuth specifications	XML-based SAML standards
Token Format	JWT	Bearer token (format unspecified)	XML
Identity Claims	Standardized	Not defined	Attribute statements
Mobile Support	Excellent	Excellent	Poor
Use Cases	User authentication, social login	API access	Enterprise SSO
Complexity	Low	Low	High
Target Audience	Modern apps	APIs	Enterprise federation

OIDC and OAuth 2.0 complement each other. OIDC answers “Who is this user?” OAuth 2.0 answers “What can this user access?” SAML is widely used for enterprise SSO. OIDC is preferred for modern apps and mobile support.

What is the difference between OAuth 2.0 and OpenID Connect?

OAuth 2.0 is for authorization. OIDC adds authentication on top. OAuth answers “What can this app access?” OIDC answers “Who is this user?”

What is an ID token and why is it important?

An ID token is a signed JWT containing identity claims asserted by the provider. It proves that authentication occurred. Unlike access tokens, it is intended for the client to verify a user's identity. The signature enables validation without requiring contact with the provider. Common claims include user ID (sub), email, and authentication time. Always validate ID tokens.

Can I use OIDC without OAuth 2.0?

No. OIDC is built on OAuth 2.0. Every OIDC flow is an OAuth 2.0 flow with the openid scope and ID token added. OIDC extends OAuth 2.0; it doesn't replace it.

Is OIDC more secure than SAML?

Both are secure if implemented correctly. OIDC uses simpler JWT validation. SAML requires XML signatures, which are more complex in nature. Most vulnerabilities arise from implementation errors, not the protocol itself. OIDC’s simpler token format helps reduce implementation risk.

What is the UserInfo endpoint?

The UserInfo endpoint returns extra user profile claims. It requires a valid access token, not the ID token. Use it only if the ID token does not contain the needed claims. The endpoint is often rate-limited, so implement caching to improve performance.

Do I need to validate ID tokens from a trusted provider?

Yes. Always validate signature, issuer, audience, expiration, and nonce. Validation ensures the token is genuine, current, and intended for your application. Even tokens from trusted providers must be validated to prevent tampering and replay attacks.

Can OIDC work without HTTPS?

No. HTTPS is required for production. Attackers can intercept tokens sent over HTTP. Localhost exceptions are only allowed for development purposes.

Using OIDC Libraries

Mature libraries handle token validation, JWKS key management, and protocol details. Libraries can help reduce errors, but they require an understanding of OIDC concepts.

Popular open source libraries include:

• Node.js: openid-client
• Python: authlib
• Python: pyoidc
• Java: Spring Security OAuth

Using Identity Platforms

Identity platforms offer OIDC and OAuth 2.0 implementations with built-in security, social login, and protocol translation capabilities. They can also manage updates, compliance, and scaling, allowing developers to focus on application logic.

Auth0 streamlines OIDC and OAuth 2.0 implementations, enabling developers to focus on building applications while securely handling authentication and identity.

Explore our Intro to IAM series on identity and access management.

Learn more

These materials are intended for general informational purposes only. You are responsible for obtaining security, privacy, compliance, or business advice from your own professional advisors and should not rely solely on the information provided herein.