OAuth2 / OIDC Flows
OAuth2 is an authorization framework allowing third-party applications to access resources on a user's behalf without sharing credentials. OIDC (OpenID Connect) extends OAuth2 with authentication — it provides a standard way to verify user identity.
OAuth2 = a valet parking ticket. You hand the valet (app) a limited ticket to park your car (access data) without giving them your actual car keys (password). OIDC adds a photo ID check so you prove who you are too.
Key flows: Authorization Code Flow (for server-side apps — most secure; uses PKCE extension for SPAs and mobile apps); Client Credentials Flow (for service-to-service — no user involved; client ID + secret exchanged for access token); Device Authorization Flow (for TVs/CLIs where browser redirect is impractical). Tokens: Access Token (short-lived JWT for API authorization, typically 15 minutes), Refresh Token (longer-lived, used to obtain new access tokens without re-authentication, typically 30 days), ID Token (OIDC JWT containing user identity claims — never sent to APIs).
PKCE (Proof Key for Code Exchange) prevents authorization code interception attacks for public clients (SPAs, mobile apps) that cannot safely store a client secret. The client generates a random code_verifier, derives code_challenge = SHA256(code_verifier), sends code_challenge with the auth request, then sends code_verifier with the token exchange. An interceptor who captures the authorization code cannot exchange it without the code_verifier. Token introspection vs JWT verification: JWTs are self-contained (verify with public key, no network call), but revocation requires a blacklist check (token introspection endpoint or short TTL + refresh token revocation). The correct security model: access tokens are JWTs with 15-minute expiry; refresh tokens are opaque tokens with server-side storage enabling instant revocation.
For a B2C web app, I use Authorization Code Flow + PKCE. The SPA never sees the client secret — the backend handles the token exchange. Access tokens are JWTs signed by the identity provider (Auth0, Cognito), verified by services using the provider's JWKS endpoint (with local key caching). Services do not accept access tokens older than 15 minutes. For service-to-service, I use Client Credentials Flow with short-lived tokens cached by the calling service to avoid per-request token fetches.
Storing JWTs in localStorage. XSS attacks can exfiltrate localStorage contents. Store tokens in httpOnly, Secure cookies — they are inaccessible to JavaScript. The 'token in memory' approach (React state) is XSS-safe but lost on page reload, requiring silent refresh on startup.