OpenID Connect

OpenID Connect (OIDC) adds authentication on top of OAuth 2.0: an ID token containing identity claims, alongside the access token for authorisation. It is the standard I reach for when systems must trust each other's users.

My work covers the full flow set — authorization code with PKCE, discovery documents, token validation (issuer, audience, signature), and the id-token claims that drive sessions and user identity.

Where I add real value is the trust boundary: JWKS key management, standardised single sign-on across services, and logout/session semantics that keep identity consistent without rolling bespoke auth.

The ID token is the centrepiece — a signed, short-lived set of claims about who the user is. I rely on it instead of inventing a session format, which is exactly what makes cross-service identity standards-based rather than bespoke.

Discovery documents (well-known) make configuration dynamic. A client finds the token, user-info, and JWKS endpoints from a single URL, which is how a new client or provider integrates without hard-coded endpoint churn.

Validation is the trust step and I never skip it: verify the signature against the provider's JWKS, then the issuer, audience, and nonce. An ID token that is signed by the right issuer and aimed at my client is the only one I accept.

Single sign-on follows naturally from the standard. One login at the identity provider yields portable, verifiable identity across first- and third-party services, which removes the per-app account sprawl that plagues fragmented stacks.

Session and logout semantics get the same discipline. A logout that invalidates the session at the provider, not just the local cookie, is what keeps SSO actually single — otherwise the "sign out everywhere" promise quietly breaks.

I keep identity reads-only where possible: services consume the ID token for who the user is and the access token for what they may do, without re-implementing an identity store. That separation is the clean OIDC pattern in practice.

I start from the discovery document. A single well-known URL reveals the endpoints and JWKS, so a client integrates without hard-coded endpoint churn.

Validation is strict and complete. I verify the signature against the provider's JWKS, then the issuer, audience, and nonce — an ID token aimed somewhere else is rejected.

The ID token is the identity source. I rely on its signed claims instead of inventing a session format, which keeps cross-service identity standards-based rather than bespoke.

Single sign-on follows from the standard. One login at the identity provider yields portable identity across first- and third-party services, removing per-app account sprawl.

Session and logout semantics get the same discipline. A logout that invalidates the session at the provider, not just the local cookie, is what keeps SSO actually single.

Services consume tokens for what they need. Identity claims drive sessions; the access token governs authorisation — and neither requires re-implementing an identity store.

Key handling is centralised and current. JWKS retrieval and rotation are managed in one place so every consumer verifies with the same, trusted keys.

I layer OIDC cleanly over OAuth 2.0. Authorisation and identity stay separate concerns, so the trust boundary is precise and each flow is easy to reason about.

I keep provider choice portable. The same discovery-and-validation contract works against self-hosted or cloud issuers, so identity infrastructure can change without touching every client.