OpenID Connect (OIDC) is an identity layer built on OAuth 2.0 that answers "who is this user?" — the question OAuth deliberately left unanswered. OAuth 2.0 handles authorization ("what can this app access?"); OIDC adds authentication by issuing a signed **ID token** alongside the OAuth access token. ## Mechanics Triggered by the `openid` scope in the authorization request. The provider returns: - **ID token** — a JWT with identity claims: `sub` (stable user identifier), `iss` (issuer), `aud` (intended audience), `exp`, `email`, `name` - **Access token** — authorizes API calls to resource servers (format is provider-defined, not spec-mandated) - **Discovery document** at `/.well-known/openid-configuration` — enables clients to auto-configure endpoints and keys **Key rule**: The ID token is for the client — it proves who authenticated. Never forward it to APIs. The access token is for resource servers. ## OIDC vs SAML | | OIDC | SAML | |---|---|---| | Format | JSON / JWT | XML assertions | | Transport | REST / mobile-friendly | Browser redirect–only | | Era | 2014, API-first | 2002, enterprise legacy | OIDC is the modern standard. Production systems still require SAML support for legacy SP integrations. ## Cross-Domain Applications **[[Workload Identity Federation]]**: CI platforms (GitHub Actions, GitLab) issue OIDC tokens to jobs; AWS and GCP validate them via `sts:AssumeRoleWithWebIdentity` to grant temporary credentials — no stored secrets. **Kubernetes**: OIDC is the native authentication mechanism for `kubectl` and IRSA (IAM Roles for Service Accounts). **SSO products**: Auth0, Okta, and Clerk implement OIDC as the primary SSO protocol; SAML support is layered on top for enterprise customers.