Standard · reviewed 2026-05-22

OpenID Connect (OIDC) explained — the identity layer on top of OAuth

OpenID Connect adds an identity layer on top of OAuth 2.0 — a signed ID Token, standard claims, and a discovery endpoint.

Read the spec

Authentication flow visualization with credentials passing through layered identity verification gates

TL;DR

OIDC (OpenID Foundation, 2014) is what made OAuth-based "Sign in with X" practical. OAuth alone gives you an access token for an API; OIDC adds an ID Token (a signed JWT containing claims about the user) so the relying party can know *who* the user is, not just that they have access. Almost every modern SSO uses OIDC for authentication, with OAuth flows underneath for any subsequent API authorization.

Published by

OpenID Foundation

Spec

OpenID Connect Core 1.0 (2014, with errata)

Who uses it

Google Sign-In, Microsoft accounts, Apple ID, every consumer IdP, every workforce IdP (Okta, Entra, Auth0, Ping, JumpCloud, etc.). Default SSO protocol for new B2C + B2B integrations.

Reviewed

2026-05-22

When to use

Any web or mobile application that needs to "log a user in." OIDC + OAuth Authorization Code + PKCE is the default for new identity integrations.

When not to use

Pure API-to-API authentication with no human user (use OAuth 2.1 Client Credentials directly). Government / enterprise integrations that already require SAML 2.0 — translating is more cost than benefit.

What OIDC adds on top of OAuth

Five things, in order of importance:

ID Token — a signed JWT with claims about who the user is (`sub`, `email`, `name`, `aud`, `iss`, `exp`). This is what makes "Sign in with X" work — the relying party can verify the signature and trust the claims without calling back to the IdP.
`openid` scope — adds OIDC behavior to a standard OAuth /authorize call. If you ask for `openid profile email`, the response includes an ID Token; if you don't include `openid`, it doesn't.
Standard claims — `sub`, `name`, `email`, `email_verified`, `picture`, `locale`, etc. RPs can rely on the same claim names across IdPs.
UserInfo endpoint — returns the same claims as the ID Token, but as a regular HTTP endpoint requiring the access token. Useful when the ID Token has been narrowed for privacy.
Discovery (well-known) — `/.well-known/openid-configuration` returns a JSON document with all the IdP's endpoints, supported scopes, supported algorithms, and JWKS URI. The RP can configure itself.

The ID Token, dissected

An ID Token is a JWT. Sample decoded payload:

{
  "iss": "https://idp.example.com",       // who issued the token
  "sub": "auth0|abc123",                   // stable user identifier
  "aud": "your-client-id",                 // who this token is for
  "iat": 1720000000,                        // issued at
  "exp": 1720003600,                        // expires (1 hour later)
  "nonce": "<random from authn request>",  // anti-replay
  "email": "[email protected]",
  "email_verified": true,
  "name": "Jane Doe",
  "picture": "https://lh3...",
  "locale": "en-US"
}

What an RP must verify on the ID Token

Spec-required validation, in order:

Signature is valid against the issuer's JWKS.
`iss` matches the configured issuer URL exactly.
`aud` matches the client's client_id.
`exp` is in the future (with reasonable clock skew tolerance).
`nonce` matches the value the client included in the /authorize request.
For implicit / hybrid flows: `at_hash` is the SHA256 hash of the access token (anti-substitution).

Discovery + JWKS — what makes OIDC easy to integrate

An OIDC-conformant RP needs only two URLs from the IdP: the issuer URL and the client_id. Everything else is discoverable:

GET https://idp.example.com/.well-known/openid-configuration

{
  "issuer": "https://idp.example.com",
  "authorization_endpoint": "https://idp.example.com/authorize",
  "token_endpoint": "https://idp.example.com/token",
  "userinfo_endpoint": "https://idp.example.com/userinfo",
  "jwks_uri": "https://idp.example.com/.well-known/jwks.json",
  "scopes_supported": ["openid", "profile", "email", "offline_access"],
  "response_types_supported": ["code", "id_token", "code id_token"],
  "id_token_signing_alg_values_supported": ["RS256", "ES256"],
  "subject_types_supported": ["public", "pairwise"]
}

Common implementation mistakes

Real failures we see in audits:

Skipping `nonce` validation. ID tokens without nonce validation are vulnerable to token-replay across sessions.
Trusting an unsigned ID token. Setting `alg: none` was a real spec issue once; libraries should reject it by default. Verify your library does.
Pinning a single signing key. JWKS rotation breaks signature validation. Cache JWKS but refresh on cache miss for unknown `kid`.
Using ID Token for API authorization. The ID Token is for the RP to know who the user is. To call an API, use the access token. Audience-confusing the two is a common pattern.

FAQ

Questions we get on this standard.

Is OIDC the same as OAuth?
No. OAuth is an authorization protocol (it produces access tokens for APIs). OIDC is an authentication protocol built on top of OAuth (it produces ID tokens that identify the user). They're often used together.
Should I use the `name` claim or `email` claim as the user identifier?
Neither. Use `sub` — it's the stable, immutable identifier. Names change; email addresses get reused. The `sub` is yours forever within that IdP.
How does OIDC compare to SAML for SSO?
OIDC is the modern default — simpler JSON over HTTPS, better for mobile / native, smaller payloads. SAML is the older XML-based incumbent, still ubiquitous in B2B + government. They cover the same use cases.

Use the tool

Understanding the spec is the easy part.

We implement OpenID Connect integrations across regulated enterprises — workforce SSO, B2B SaaS federation, customer identity. Same-day reply.

Talk to a practice leadMore explainers

What OIDC adds on top of OAuth

Five things, in order of importance:

ID Token — a signed JWT with claims about who the user is (`sub`, `email`, `name`, `aud`, `iss`, `exp`). This is what makes "Sign in with X" work — the relying party can verify the signature and trust the claims without calling back to the IdP.

`openid` scope — adds OIDC behavior to a standard OAuth /authorize call. If you ask for `openid profile email`, the response includes an ID Token; if you don't include `openid`, it doesn't.

Standard claims — `sub`, `name`, `email`, `email_verified`, `picture`, `locale`, etc. RPs can rely on the same claim names across IdPs.

UserInfo endpoint — returns the same claims as the ID Token, but as a regular HTTP endpoint requiring the access token. Useful when the ID Token has been narrowed for privacy.

Discovery (well-known) — `/.well-known/openid-configuration` returns a JSON document with all the IdP's endpoints, supported scopes, supported algorithms, and JWKS URI. The RP can configure itself.

The ID Token, dissected

An ID Token is a JWT. Sample decoded payload:

{ "iss": "https://idp.example.com", // who issued the token "sub": "auth0|abc123", // stable user identifier "aud": "your-client-id", // who this token is for "iat": 1720000000, // issued at "exp": 1720003600, // expires (1 hour later) "nonce": "<random from authn request>", // anti-replay "email": "[email protected]", "email_verified": true, "name": "Jane Doe", "picture": "https://lh3...", "locale": "en-US" }

What an RP must verify on the ID Token

Spec-required validation, in order:

Signature is valid against the issuer's JWKS.

`iss` matches the configured issuer URL exactly.

`aud` matches the client's client_id.

`exp` is in the future (with reasonable clock skew tolerance).

`nonce` matches the value the client included in the /authorize request.

For implicit / hybrid flows: `at_hash` is the SHA256 hash of the access token (anti-substitution).

Discovery + JWKS — what makes OIDC easy to integrate

An OIDC-conformant RP needs only two URLs from the IdP: the issuer URL and the client_id. Everything else is discoverable:

GET https://idp.example.com/.well-known/openid-configuration { "issuer": "https://idp.example.com", "authorization_endpoint": "https://idp.example.com/authorize", "token_endpoint": "https://idp.example.com/token", "userinfo_endpoint": "https://idp.example.com/userinfo", "jwks_uri": "https://idp.example.com/.well-known/jwks.json", "scopes_supported": ["openid", "profile", "email", "offline_access"], "response_types_supported": ["code", "id_token", "code id_token"], "id_token_signing_alg_values_supported": ["RS256", "ES256"], "subject_types_supported": ["public", "pairwise"] }

Common implementation mistakes

Real failures we see in audits:

Skipping `nonce` validation. ID tokens without nonce validation are vulnerable to token-replay across sessions.

Trusting an unsigned ID token. Setting `alg: none` was a real spec issue once; libraries should reject it by default. Verify your library does.

Pinning a single signing key. JWKS rotation breaks signature validation. Cache JWKS but refresh on cache miss for unknown `kid`.

Using ID Token for API authorization. The ID Token is for the RP to know who the user is. To call an API, use the access token. Audience-confusing the two is a common pattern.

Questions we get on this standard.

Is OIDC the same as OAuth?

No. OAuth is an authorization protocol (it produces access tokens for APIs). OIDC is an authentication protocol built on top of OAuth (it produces ID tokens that identify the user). They're often used together.

Should I use the `name` claim or `email` claim as the user identifier?

Neither. Use `sub` — it's the stable, immutable identifier. Names change; email addresses get reused. The `sub` is yours forever within that IdP.

How does OIDC compare to SAML for SSO?

OIDC is the modern default — simpler JSON over HTTPS, better for mobile / native, smaller payloads. SAML is the older XML-based incumbent, still ubiquitous in B2B + government. They cover the same use cases.