OAuth 2.0 & JWT

Why Authentication Is Hard at Scale

Authentication — confirming who a user is — seems simple in a monolith with a single session store. Once you have microservices, mobile clients, third-party integrations, and millions of users, the problem explodes in complexity. You need a protocol that is stateless (so any server can validate a token without calling a central store), delegatable (so a user can grant limited access to a third-party app), and revocable (so stolen credentials can be invalidated quickly). OAuth 2.0 and JWTs together address these requirements, which is why they appear in nearly every system design interview involving user data.

OAuth 2.0: The Protocol

OAuth 2.0 is an authorization framework, not an authentication protocol. It allows a Resource Owner (user) to grant a Client (your app) limited access to resources stored on a Resource Server (e.g., Google Drive) without sharing credentials. An Authorization Server (e.g., Auth0, Google Identity) issues tokens. OpenID Connect (OIDC) sits on top of OAuth 2.0 to add authentication — it introduces the `id_token` (a JWT describing the user) on top of the access token.

Authorization Code Flow with PKCE

JWT: Structure and Validation

A JSON Web Token (JWT) is a compact, URL-safe token format that encodes claims as a signed JSON object. It has three Base64URL-encoded segments separated by dots: `header.payload.signature`. The header specifies the signing algorithm (`alg`). The payload contains claims. The signature proves the token was issued by a trusted party and was not tampered with.

// Header (decoded)
{
  "alg": "RS256",   // RSA signature with SHA-256
  "typ": "JWT",
  "kid": "key-id-1" // Key ID for rotation
}

// Payload (decoded)
{
  "iss": "https://auth.example.com",  // Issuer
  "sub": "user_12345",                // Subject (user ID)
  "aud": "api.example.com",           // Audience
  "exp": 1740000000,                  // Expiry (Unix timestamp)
  "iat": 1739996400,                  // Issued at
  "jti": "unique-token-id",           // JWT ID (for blacklisting)
  "roles": ["viewer", "commenter"],   // Custom claims
  "plan": "pro"
}

// Signature = RS256(base64url(header) + "." + base64url(payload), privateKey)

Validation Checklist

1. Verify signature using the public key (for RS256) or shared secret (for HS256). Reject if invalid.
2. Check `alg` header — reject `alg: none` or unexpected algorithms (algorithm confusion attacks).
3. Validate `exp` claim — reject if token is expired.
4. Validate `iss` (issuer) matches your expected authorization server.
5. Validate `aud` (audience) contains your service's identifier.
6. Optionally check `jti` against a token blacklist if revocation is needed.

Access Tokens vs Refresh Tokens

The standard pattern is: issue a short-lived access token (15–60 minutes) for API access and a long-lived refresh token (7–30 days) stored in an HttpOnly cookie. When the access token expires, the client silently exchanges the refresh token for a new pair. This limits exposure if an access token is stolen while keeping users logged in without re-authentication.

Token Storage Security

Common Pitfalls and Attacks

• JWT Algorithm Confusion: Attacker changes `alg` from `RS256` to `HS256` and signs with the public key (which they have). Always pin the expected algorithm server-side.
• Open Redirect in Redirect URI: OAuth redirects to attacker-controlled URL if `redirect_uri` is not strictly validated. Always whitelist exact redirect URIs.
• CSRF on Authorization Endpoint: Without a `state` parameter, attacker can initiate OAuth flow on victim's behalf. Always validate the `state` parameter to prevent CSRF.
• Token Leakage via Referer Header: Access tokens in URL query params (like Implicit flow) leak through `Referer` headers. Never put tokens in URLs.
• Refresh Token Theft: A compromised refresh token grants indefinite access. Use refresh token rotation (issue new refresh token on each use, invalidate old one) and detect reuse as a breach signal.