OAuth & OIDC
Studies in this cluster, in series order. Each one keeps its own URL.
Security
AuthN, AuthZ, OAuth/OIDC, OWASP web attacks (injection, XSS, CSRF, SSRF, CORS), secrets/KMS, tokens, and service identity you can defend in interviews.
OAuth & OIDC
7 studies- 1.OAuth 2.1 & OIDC — Authorization Code + PKCEOAuth 2.1 makes Authorization Code + PKCE the default for public clients and retires implicit and password grants. Authentication (who) and authorization (what) are different questions: OIDC identity is the next lesson, JWT is only a token format, and the decision matrix picks session, BFF, PKCE, client credentials, device code, or mTLS. Interviews expect the redirect sequence, S256, exact redirect URIs, and state versus nonce.
- 2.OpenID Connect — ID Tokens, UserInfo, Discovery & NonceOpenID Connect is the identity layer on OAuth 2. The client asks for scope openid, validates an ID token aimed at itself (iss, aud, exp, nonce), and may call UserInfo. Discovery publishes the endpoints. Never send the ID token to your API as a bearer.
- 3.JWT vs Opaque Tokens — Validation, JWKS & RevocationJWTs validate locally via JWKS (iss/aud/exp/kid) and scale reads; opaque tokens make revocation trivial via introspection or a store. Choosing wrong means day-long stolen JWTs or introspection bottlenecks at the edge. Pair short AT TTL with refresh rotation and never skip audience checks.
- 4.Refresh Token Rotation & Reuse DetectionRefresh token rotation issues a new RT on every refresh and invalidates the old one; reuse detection treats a replayed ancestor as theft and revokes the whole token family. This is OAuth 2.1 / BCP guidance for public clients and pairs with short-lived access tokens and BFF storage.
- 5.BFF Cookie Sessions vs SPA Bearer TokensA BFF keeps access and refresh tokens on the server and gives the browser only an HttpOnly Secure SameSite session cookie. SPA bearer puts tokens in the browser, so XSS means token theft. BFF needs CSRF defenses; bearer needs extreme XSS hygiene. Prefer BFF for first-party SPAs.
- 6.Service-to-Service Auth — mTLS, Client Credentials & Workload IdentityService-to-service auth uses Client Credentials, mTLS/SPIFFE, or cloud Workload Identity federation instead of user OAuth dances. Narrow audiences, short-lived creds, and no long-lived JSON keys. Interviews probe blast radius, metadata SSRF, and token exchange.
- 7.OAuth Threat Model — CSRF, Token Leakage, Confused Deputy & Common PitfallsOAuth security is a threat model: login CSRF (state), code interception (PKCE), token leakage, confused deputy (aud), refresh theft (rotation), and mix-up attacks. Map each attack to controls across this cluster rather than treating OAuth as a grant-type checklist.