Intermediate16 min

OpenID Connect

The authentication layer OAuth was missing — a verifiable ID token for 'who is the user'.

By the end of this lesson, explain how OIDC adds authentication to OAuth and what the ID token is for.

How deep?

How the pieces actually move.

OpenID Connect (OIDC) is a thin authentication layer on top of OAuth 2.0. It adds one crucial artifact: the ID token, a JWT that asserts *who authenticated* — issuer, subject, when, and how. Where OAuth gives you an access token to *call APIs*, OIDC gives you an ID token to *know the user*.

First, the whole system

First, see the whole system. Then we’ll open it up.

OIDC = OAuth + ID token

The client runs the OAuth code flow requesting the openid scope.
The provider returns both an access token (for APIs) and an ID token (a JWT identifying the user).
The client verifies the ID token to learn who the user is.

flowchart LR
  client[Client] -->|OAuth code flow + scope=openid| op[OpenID Provider]
  op -->|access token| api[APIs]
  op -->|ID token JWT| client
  client -->|verify ID token| who[Knows the user]

Requesting the openid scope turns an OAuth flow into an OIDC flow. The ID token carries iss, sub, aud (the client), exp, iat, plus a nonce to bind it to the request and prevent replay. The /userinfo endpoint returns additional profile claims. Discovery (/.well-known/openid-configuration) lets clients auto-configure endpoints and keys.

Abstraction leak

This is where the abstraction starts leaking.

The ID token is for the client; the access token is for APIs. Sending an ID token to an API, or using an access token to identify the user, are both common mistakes. Audience (aud) is what keeps them in their lanes — verify it.

Why it exists

You know what happens. Now see why it works.

Before OIDC, every app invented its own 'log in with OAuth', frequently insecurely (treating access tokens as identity). OIDC standardized authentication so 'Sign in with Google/Microsoft' works consistently and single sign-on (SSO) is interoperable.

ID token confusion

Trigger: An API accepts ID tokens, or a client accepts an ID token whose aud/nonce it never checks.
Symptom: Tokens minted for one party are accepted by another.
Blast radius: Authentication bypass or cross-client token reuse.
Mitigation: Validate aud, iss, exp, and nonce; APIs accept only access tokens.

Deep dive: Token Replay

How it connects

Your SPA needs to display the logged-in user's name. Which token has that, and how do you trust it?

The ID token. Verify its signature via the provider's JWKS and check iss, aud (your client), exp, and nonce before trusting its claims.