OAuth 2.0 + OIDC + PKCE for Frontend Auth Flows
OAuth 2.0
Delegated authorization
- - Access tokens for APIs
- - Not identity by itself
OIDC
Identity layer on OAuth
- - id_token + user claims
- - Discovery + JWKS validation
PKCE
Public-client proof
- - Mitigates code interception
- - Required for SPA/mobile
Session strategy
Runtime safety
- - Short access token lifetime
- - Refresh/revocation policy
Core Lens
Separate authorization from identity and enforce public-client constraints in browser apps.
Flow
OAuth and OIDC are protocol frameworks that define how applications delegate authorization and establish identity.
For frontend architecture, the important design questions are not just how to log a user in, but how to safely handle tokens, how to recover when tokens expire, and how to prevent browser runtime compromise from exposing credentials.
Strong frontend systems clearly separate responsibilities between the browser, the identity provider, and backend APIs.
Quick Navigation: OAuth Roles and System Boundaries • Authorization Code + PKCE Flow • OIDC: Identity Layer on Top of OAuth • Token Types and Responsibilities • SPA Security Model • Token Storage Tradeoffs • Architecture Pattern: Backend-for-Frontend (BFF) • Token Lifecycle and Reliability
Quick Decision Guide
Senior-Level Decision Guide:
- OAuth handles delegated authorization while OIDC provides identity. - Browser-based apps must use Authorization Code + PKCE instead of the deprecated implicit flow. - SPAs are public clients and cannot safely store client secrets. - Token exposure in browser storage increases XSS blast radius. - Token refresh and session rotation must be designed as reliability systems, not just security features.
OAuth Roles and System Boundaries
OAuth defines four core actors:
In frontend interviews, a key point is recognizing that browser apps are public clients. Unlike backend services, they cannot safely hold confidential client secrets.
Authorization Code + PKCE Flow
Modern browser apps use the Authorization Code flow with PKCE.
High-level steps:
1. Client generates a code_verifier.
2. Derives a code_challenge from the verifier.
3. Redirects user to the authorization endpoint.
4. Identity provider redirects back with an authorization code.
5. Client exchanges the code and verifier for tokens.
PKCE ensures that the party initiating the authorization request is the same one completing the token exchange, protecting against intercepted authorization codes.
OIDC: Identity Layer on Top of OAuth
OAuth itself only describes authorization. OIDC extends OAuth to provide identity verification.
Key additions:
id_token containing identity claimsuserinfo endpointOIDC ensures the application can verify the authenticated user rather than simply receiving an authorization grant.
Token Types and Responsibilities
Typical OAuth/OIDC flows produce multiple tokens:
Frontend architecture must treat these tokens differently based on sensitivity, lifetime, and intended usage.
SPA Security Model
Browsers are hostile runtime environments from a security perspective.
Risks include:
Because of this threat model, frontend applications should minimize token lifetime, limit token exposure in JavaScript-accessible storage, and rely on secure session mediation when possible.
Token Storage Tradeoffs
Common storage strategies include:
Each has tradeoffs:
Staff-level answers describe the threat model rather than claiming a single universal best practice.
Architecture Pattern: Backend-for-Frontend (BFF)
Many large systems avoid storing OAuth tokens directly in the browser.
Instead, a backend-for-frontend service performs OAuth exchanges and stores tokens server-side. The browser receives a session cookie instead of raw provider tokens.
Benefits include:
This pattern is common in enterprise systems with strict security requirements.
Token Lifecycle and Reliability
Authentication systems must handle token expiration and refresh safely.
Common problems include:
Robust systems implement refresh coordination, retry limits, and clear fallback paths when authentication state becomes invalid.
Failure Modes and Production Pitfalls
Typical production incidents include:
state or nonce validationFrontend engineers must design degraded behavior such as forced re-authentication when identity providers become unavailable.
Interview Rubric (Staff Level)
A strong interview answer should explain:
Weak answers describe login redirects. Strong answers explain security boundaries and operational recovery behavior.