Summary
OAuth 2.0 / OIDC lets users grant your app access without sharing passwords. JWTs carry claims in a self-contained, signed token; sessions store state on the server. Each approach carries different trade-offs for revocation, storage, and XSS exposure. The BFF pattern resolves the SPA token-storage dilemma.
Jump to the interview angleOAuth 2.0 / OIDC
OAuth 2.0 is an authorization framework that lets users grant a third-party app scoped access to their resources on another service — without exposing their credentials. OpenID Connect (OIDC) is a thin identity layer on top of OAuth 2.0 that adds a signed ID token with user claims (sub, email, name).
The authorization-code flow with PKCE (Proof Key for Code Exchange) is the correct flow for SPAs and mobile apps. PKCE prevents auth-code interception attacks by binding the authorization request to a one-time code verifier that the client generates and the token endpoint validates.
JWT vs server sessions
| Dimension | JWT (stateless) | Server session (stateful) | |
|---|---|---|---|
| State location | Encoded in token, held by client | Session record on server (DB/Redis) | |
| Revocation | Not possible until expiry (need blocklist) | Immediate — delete the session record | |
| Scalability | No server lookup; scales horizontally | Session store becomes shared dependency | |
| Token size | Larger — carries all claims inline | Small ID; claims fetched server-side | |
| Best for | Stateless APIs, short-lived machine tokens | User sessions needing instant logout |
Cookies vs localStorage for token storage
Store tokens in HttpOnly Secure SameSite=Strict cookies, not localStorage. localStorage is readable by any JavaScript on the page — a single XSS vulnerability drains every user token. HttpOnly cookies are invisible to JS; SameSite=Strict blocks CSRF. Short-lived access tokens (5–15 min) plus a refresh token in an HttpOnly cookie is the standard pattern.
BFF token-handler pattern
- A Backend for Frontend (BFF) handles the OAuth code exchange server-side, keeping tokens off the browser entirely.
- The BFF sets HttpOnly cookies for the session; the SPA never sees raw access or refresh tokens.
- Downstream API calls are made server-side by the BFF, which attaches the access token as a Bearer header.
- Logout hits the BFF, which revokes the refresh token and clears the cookie atomically.
- Auth0 and Okta publish reference BFF implementations; Next.js Auth.js uses this pattern by default.
Interview angle
Interviewers probe the JWT revocation gap — you can't invalidate a token before it expires without a blocklist. Contrast with sessions: stateful, instantly revocable. Cover the PKCE flow for SPAs, and why localStorage is off-limits for tokens.
Soundbite: "JWTs are stateless and unrevocable; sessions are stateful and instantly revocable."
Key terms
- PKCE
- Proof Key for Code Exchange — one-time code verifier that binds an auth request to its token exchange, blocking interception.
- OIDC
- OpenID Connect — identity layer on OAuth 2.0 that issues a signed ID token containing user claims.
- JWT
- JSON Web Token — base64url-encoded header + payload + signature; stateless, self-contained, cannot be revoked before expiry.
- HttpOnly cookie
- Browser cookie inaccessible to JavaScript; protects tokens from XSS exfiltration.
- BFF (Backend for Frontend)
- Server layer that holds OAuth tokens and exposes a session cookie to the SPA, keeping tokens off the client.