OAuth 2.0 and JWT Authentication: A Foolproof Guide for System Design Interviews

Security is often the most neglected component of a system design interview. Candidates will spend 30 minutes meticulously scaling a Redis cluster, only to hand-wave the authentication layer with a vague "and we'll just check if the user is logged in."

Failing to articulate a secure, scalable authentication flow is a massive red flag for senior engineering roles. In this definitive guide, we will break down the two critical pillars of modern API security: JSON Web Tokens (JWT) for authentication, and OAuth 2.0 for authorization.

1. Stateful Sessions vs. Stateless JWTs

Before modern Single Page Applications (SPAs) and microservices, authentication was strictly stateful.

The Old Way: Stateful Session IDs

A user logs in. The server generates a unique, opaque Session ID, stores it in a central database or Redis cache, and sends the ID back to the client via a cookie. For every subsequent request, the server must look up that ID in the database to verify the user.

• The Problem: It breaks horizontal scaling. If you have 50 microservices behind an API Gateway, every single service must constantly hit the Redis cache just to verify if an incoming request is valid, creating a massive I/O bottleneck and tight coupling.

The Modern Way: Stateless JSON Web Tokens (JWT)

JWTs are completely stateless. When a user logs in, the server cryptographically signs a JSON payload containing the user's ID, roles, and expiration time, and sends this token to the client.

• The Anatomy of a JWT: A JWT contains three Base64Url encoded strings separated by dots: Header, Payload, and Signature.
• The Magic: Because the token's signature is mathematically generated using a secret key (symmetric HS256) or a private/public keypair (asymmetric RS256), any microservice can mathematically verify the token's authenticity independently, without ever talking to a database.

The JWT Revocation Problem

The major trade-off of a stateless JWT is that you cannot easily revoke it. If a hacker steals a token, or a user is banned, the token remains mathematically valid until its built-in expiration time (exp) hits.

Interview Solution: You must explain the strategy of using extremely short-lived Access Tokens (e.g., 15 minutes) paired with long-lived, database-backed Refresh Tokens. If a user is banned, the server invalidates their Refresh Token. After 15 minutes, the stolen Access Token expires, and the attacker is locked out. Alternatively, you can maintain a high-performance Redis blacklist of explicitly revoked token signatures.

2. Storage Security: XSS vs. CSRF

When returning a JWT to a web client, where do you store it? This is a classic interview trap.

• LocalStorage: Easy to implement, but vulnerable to Cross-Site Scripting (XSS). If an attacker injects malicious JavaScript into your site, they can easily read localStorage.getItem('token') and steal the user's identity.
• HttpOnly Secure Cookies: The recommended approach. The browser automatically attaches the cookie to requests, and JavaScript cannot access it, eliminating XSS theft. However, it opens you up to Cross-Site Request Forgery (CSRF). You must mitigate this by implementing Anti-CSRF tokens or utilizing the SameSite=Strict cookie attribute.

3. OAuth 2.0: The Authorization Framework

If JWT is the format of the token, OAuth 2.0 is the protocol used to securely acquire it, especially when dealing with third parties. Whenever you see a button that says "Log in with Google," you are looking at OAuth 2.0.

(Note: OAuth 2.0 is technically for Authorization—granting access. OpenID Connect (OIDC) sits on top of OAuth 2.0 to provide Authentication—verifying identity).

The OAuth 2.0 Authorization Code Flow (with PKCE)

If asked to design an authentication flow integrating third parties or a centralized Auth Server, this is the architecture you draw:

1. The Request: The user clicks "Log in." The application redirects the user to the Authorization Server.
2. User Consent: The user authenticates and grants the application permission.
3. The Code: The server redirects the user back to the application, passing a short-lived, one-time-use Authorization Code in the URL.
4. The Exchange (Server-to-Server): The application's backend server securely takes this code (along with a Client Secret) and exchanges it directly with the Auth Server for an Access Token (JWT). This step happens entirely backend-to-backend, shielding the token from the user's browser history.
5. PKCE Enhancement: Modern systems use PKCE (Proof Key for Code Exchange) to cryptographically ensure that the client who initiated the request is the exact same client exchanging the code, preventing authorization code interception attacks.

Bulletproof Your Architecture with PracHub

Diagramming an OAuth flow with PKCE and defending HttpOnly cookie constraints under the pressure of a ticking clock is a skill that must be honed.

PracHub offers the perfect sandbox to practice your security architecture. By scheduling mock system design interviews with experienced peers on PracHub, you can practice answering tough follow-up questions like how to securely rotate RS256 keypairs or architect a global Redis token blacklist, ensuring your security design is absolutely foolproof before the real interview.