OpenID Connect (OIDC): Definition, Flow, and Where You’ll See It

OpenID Connect (OIDC) is the most common modern standard for login and single sign-on (SSO). It’s an identity layer on OAuth 2.0 that lets an application verify who a user is—typically by receiving an ID token (often a JWT) from an Identity Provider (IdP). Used correctly, OIDC simplifies integrations and improves security (standard endpoints, discovery, and key rotation), but it’s still security-critical: you must validate tokens, lock down redirect URIs, and choose the right flow.

How OIDC works (actors, endpoints, and tokens)

OIDC reuses OAuth 2.0’s authorization framework and adds identity-specific primitives—most importantly the ID token—plus standardized discovery and a UserInfo endpoint.

The four common actors

End user: the person logging in
Relying Party (RP) / client: your application (web app, SPA, mobile app, API gateway)
OpenID Provider (OP) / Identity Provider (IdP): authenticates the user and issues tokens
Resource server: an API the client calls with an access token (OAuth), not an ID token

For most modern applications—especially SPAs and mobile—Authorization Code Flow with PKCE is the recommended pattern.

App initiates login - Redirect the user to the IdP’s authorization endpoint with parameters like:
- client_id
- redirect_uri
- response_type=code
- scope=openid profile email (the openid scope signals OIDC)
- state (CSRF protection)
- nonce (binds the ID token to this auth request)
- PKCE: code_challenge and code_challenge_method=S256
User authenticates at the IdP - The IdP handles credentials, MFA, and policy checks. - Your app never directly sees the user’s password.
IdP returns an authorization code - The IdP redirects back to your redirect_uri with:
- code=...
- state=... (must match the value you sent)
App exchanges the code for tokens - Your app calls the IdP’s token endpoint with:
- grant_type=authorization_code
- code=...
- redirect_uri=...
- client_id=...
- PKCE: code_verifier=...
- The IdP returns commonly:
- id_token (OIDC)
- access_token (OAuth)
- optionally refresh_token (if allowed and appropriate)
App validates tokens and establishes a session - Validate the ID token (signature, issuer, audience, expiry, nonce). - Establish a local session (often an HTTP-only cookie) or use tokens directly depending on architecture.

ID token vs access token (don’t swap them)

A frequent implementation mistake is using the wrong token for the wrong job.

ID token (authentication)

Proves that the user authenticated at the IdP.
Typically a JWT signed by the IdP.
Common claims:
iss (issuer URL)
sub (stable user identifier)
aud (intended client)
exp, iat
optionally email, name, preferred_username (depending on scopes/claims)

Access token (API authorization)

Authorizes calling APIs (resource servers).
Can be JWT or opaque depending on the IdP.
Intended for the resource server, not as a “login token” for your app.

If you’re reviewing token-related incidents or attacks in this space, it can help to understand JWT pitfalls (including authorization mis-binding). See: what is jwt confused deputy.

Discovery and key rotation (why OIDC is easier to integrate)

OIDC standardizes metadata and public key distribution so clients don’t hard-code endpoints and keys.

Discovery document

/.well-known/openid-configuration
Includes:
authorization_endpoint
token_endpoint
jwks_uri
issuer
(often) userinfo_endpoint, end_session_endpoint, etc.

Example:

curl -s https://idp.example.com/.well-known/openid-configuration | jq

JWKS (JSON Web Key Set)

Fetched from jwks_uri
Contains public keys used to verify JWT signatures (supports rotation via kid)

Example:

curl -s https://idp.example.com/.well-known/jwks.json | jq

ID token validation (minimum checks)

When validating an ID token (JWT), treat this as non-negotiable:

Signature is valid using a key from JWKS (match kid)
iss equals the expected issuer exactly
aud contains your client_id (handle azp when relevant)
exp is in the future (allow small clock skew)
nonce matches what your app stored for this login attempt
Token algorithm is what you expect (never accept none; restrict allowed algs)

Pseudo-checklist:

if jwt.header.alg not in allowed_algs: reject
key = jwks.find_by_kid(jwt.header.kid)
if !verify_signature(jwt, key): reject
if jwt.claims.iss != expected_issuer: reject
if expected_client_id not in jwt.claims.aud: reject
if now >= jwt.claims.exp: reject
if jwt.claims.nonce != stored_nonce: reject
accept

What to monitor in logs (security and troubleshooting)

In IdP or application logs, investigate spikes in:

Redirect URI mismatch / invalid redirect
Reused authorization codes
State mismatch / missing state
Nonce validation failures
Token validation failures (iss/aud mismatch, signature failures)

Examples:

OIDC callback error: state mismatch
Token validation failed: issuer mismatch (iss=...)
Auth code exchange failed: invalid_grant
Redirect URI not registered: redirect_uri=...

Where you’ll encounter OIDC in the real world

SSO for SaaS and internal apps - Admins configure app integrations in an IdP (redirect URIs, client IDs/secrets, claim mappings). - Often used alongside (or instead of) SAML for newer apps.
“Sign in with …” buttons - Google/Microsoft/Apple sign-in commonly uses OIDC (sometimes with provider-specific extensions).
Zero Trust access and identity-aware proxies - Proxies authenticate users via OIDC and pass identity upstream using headers or tokens.
Kubernetes and cloud-native platforms - Kubernetes API authentication can use OIDC (external IdP + discovery/JWKS). - API gateways/ingress controllers often validate JWTs issued via OIDC.
Mobile apps and SPAs - OIDC + PKCE is the standard approach for public clients (no embedded secrets).
CI/CD and developer tooling - Some systems use OIDC-based federation to reduce static secrets and exchange identity assertions for short-lived credentials.

Practitioner guidance (what to do next)

Prefer Authorization Code Flow + PKCE; avoid Implicit Flow for new builds.
Lock down redirect URIs (exact match; avoid wildcards unless unavoidable and risk-accepted).
Validate tokens correctly (issuer/audience/signature/expiry/nonce).
Minimize scopes/claims (least privilege).
Use short token lifetimes; use refresh tokens cautiously (especially for SPAs).
Monitor callback and validation failures—often early warning of misconfiguration or probing.

If OIDC is part of your broader identity security program, also consider strengthening credentials and secrets storage around SSO accounts. A business password manager can reduce account takeover risk for admins and break-glass accounts; see password manager for small business 2026 (and if you choose 1Password, you can check plans here: Try 1Password →).