OpenID Connect (OIDC)

OpenID Connect is a thin identity layer built on top of OAuth 2.0. OAuth answers what can this app do; OIDC answers who is the user.

• It standardizes how clients authenticate users and receive verified identity claims.
• It introduces the ID token as a cryptographically signed assertion of authentication.

Before OIDC, developers misused OAuth access tokens for login, leading to confused-deputy and impersonation bugs.

The defining OIDC artifact is the ID token, a signed JWT describing the authentication event.

• It carries claims about who logged in and when.
• It is meant for the client to consume, not the resource server.

Never send an ID token to an API as an access credential, and never accept one without validating its signature and claims.

Validating an ID token means checking specific claims, not just the signature.

• iss issuer must match the expected IdP.
• aud audience must contain your client_id.
• exp / iat token must be unexpired and recently issued.
• sub stable, unique user identifier.
• nonce must match the value your client sent.

OIDC reuses the Authorization Code flow but adds the openid scope and a nonce.

• Client requests scope openid (plus optional profile, email).
• The token endpoint returns an ID token alongside the access token.
• The nonce links the ID token to the original request, preventing replay.

OIDC providers publish their signing keys at a JWKS endpoint, discoverable via the well-known configuration document.

• Fetch keys from jwks_uri and match the token kid header.
• Verify with the listed asymmetric algorithm (RS256, ES256).

Reject the none algorithm and never trust an algorithm value supplied solely by the token.

The nonce is to ID tokens what state is to the redirect: a one-time value binding the response to the request.

• The client generates a random nonce and stores it in the session.
• The IdP echoes it inside the ID token.
• On receipt, the client verifies the nonce matches and has not been used before.

This blocks token replay and injection of a token minted for a different session.

For additional profile data beyond the ID token, OIDC defines the UserInfo endpoint.

• The client calls it with the access token (not the ID token).
• It returns claims such as name, email, and picture for the authenticated subject.

Always match the returned sub against the ID token sub to prevent claim substitution.

OIDC standardizes discovery so clients can auto-configure endpoints and supported features.

• The /.well-known/openid-configuration document lists endpoints, supported scopes, and algorithms.
• Pin or validate the issuer; do not blindly follow discovery from an attacker-controlled host.

Discovery simplifies integration but the issuer remains a trust anchor you must verify.

Session termination across federated apps is handled by OIDC logout specs.

• Front-channel logout uses browser redirects/iframes to clear each relying party.
• Back-channel logout sends server-to-server logout tokens, more reliable but requires endpoints.

Without coordinated logout, a user can sign out of one app while remaining logged into others, a real session-management risk.

Identity bugs often come from skipping validation steps.

• Accepting tokens without checking aud (token meant for another client).
• Ignoring iss, enabling IdP spoofing.
• Not validating signature or accepting alg: none.
• Confusing ID tokens and access tokens.
• Missing nonce checks, enabling replay.

If your goal is login, use OIDC, not raw OAuth.

• OAuth access tokens are opaque to the client and prove nothing about identity.
• An access token can be valid for a different user or app, leading to impersonation if used for login.
• OIDC ID tokens are explicitly audience-bound identity assertions.

This distinction prevents the classic confused-deputy authentication flaw.

Pick the most critical validation step for a relying party consuming an ID token.

Key takeaways:

• OIDC adds an identity layer on OAuth 2.0; the ID token is a signed JWT proving authentication.
• Always validate iss, aud, exp, signature (via JWKS), and nonce.
• ID tokens are for the client; access tokens are for APIs; never swap their roles.
• Use nonce against replay and state against CSRF.
• Use OIDC, not raw OAuth, when you need to authenticate users.