OIDC Primer

The three parties

Every OIDC flow involves a Relying Party (your app), an OpenID Provider (Google, GitHub, your own IdP), and the End User. The provider authenticates the user and returns an ID Token — a signed JWT that your app verifies locally.

ID Token vs Access Token

The ID Token proves who the user is. It contains claims like sub,iss, and aud. The Access Token is an opaque bearer token used to call resource APIs. Never use an Access Token for authentication — that is what the ID Token is for.

Authorization Code Flow + PKCE

The modern standard for public clients. Your app redirects the browser to the provider's /authorizeendpoint with a code challenge. After the user consents, the provider redirects back with an authorization code. Your backend exchanges that code for tokens at the/tokenendpoint. PKCE binds the entire chain, preventing authorization code interception attacks.

Discovery & JWKS

Every compliant provider exposes a/.well-known/openid-configurationdocument. It lists the authorization, token, and JWKS endpoints. The JWKS endpoint publishes the public keys used to verify ID Token signatures. Rotate keys regularly and never hardcode endpoints — always fetch the discovery document first.

Verification checklist

• Validate the JWT signature against the JWKS public key.
• Confirm issmatches the expected provider URL.
• Confirm audmatches your client ID.
• Check expand iatwith a reasonable clock skew (≤ 5 minutes).
• Reject tokens signed with the none algorithm.