Authentication: JWT, OAuth 2.0, Sessions and Login Design

Authentication answers one question: who are you? In monoliths, a server-side session cookie was enough. In distributed systems with multiple services behind a load balancer, stateless tokens (JWT, OAuth 2.0) replaced sessions because any server can validate a token without hitting a shared session store. Getting authentication wrong means either security breaches (weak validation) or poor user experience (constant re-logins). Every system design interview involving users starts here.

Why This Matters

Every production system needs authentication. A misconfigured auth layer is the number one cause of data breaches (OWASP Top 10, A07:2021). In microservice architectures, authentication happens at the API gateway and is propagated to downstream services via signed tokens. Understanding JWT structure, OAuth 2.0 flows, and token refresh patterns is essential for any system design that involves users or API consumers.

The Building Blocks

• Passwords + Hashing: Users provide a password, the server hashes it with bcrypt or Argon2 (never MD5/SHA-1), and compares against the stored hash. Salt prevents rainbow table attacks.
• JWT (JSON Web Token): A self-contained token with three parts: header (algorithm), payload (claims like user_id, exp), and signature (HMAC or RSA). Any service can validate it without a database call.
• OAuth 2.0: Delegated authorization framework. The user authenticates with an identity provider (Google, GitHub), which issues an access token. Your service trusts the token, never sees the password.
• Refresh Tokens: Short-lived access tokens (15 min) paired with long-lived refresh tokens (30 days). When the access token expires, the client uses the refresh token to get a new one without re-login.
• Multi-Factor Authentication: Something you know (password) + something you have (TOTP code, hardware key). TOTP uses a shared secret and the current time to generate 6-digit codes that change every 30 seconds.
• Session Management: Server-side sessions store state in Redis/Memcached. The client holds only a session ID cookie. More secure than JWT (revocable instantly) but requires a shared session store for horizontal scaling.

Under the Hood

When a user logs in, the server validates credentials against the user database (password hash comparison using bcrypt with a work factor of 12). On success, it generates a JWT: base64-encode the header and payload, sign with HMAC-SHA256 or RSA-256 using a server secret, and return the token to the client.

On subsequent requests, the client sends the JWT in the Authorization header. The API gateway validates the signature (no database call needed for HMAC), checks the expiration claim, extracts the user_id, and forwards the request to downstream services with the validated claims. This is why JWTs enable horizontal scaling — any server can validate the token independently.

The security critical detail: JWTs cannot be revoked before expiration. If a token is stolen, it remains valid until it expires. This is why access tokens should be short-lived (15 minutes) and paired with refresh tokens stored securely (HttpOnly cookies with Secure and SameSite flags).

How Companies Actually Do This

Auth0/Okta provides authentication-as-a-service for 16,000+ companies. They handle the complexity of password storage, MFA, social logins, and compliance (SOC2, HIPAA) so engineering teams do not build it from scratch.

Google uses OAuth 2.0 to let third-party apps access user data (Gmail, Drive) without exposing passwords. Their OpenID Connect layer adds identity verification on top of OAuth's authorization flow.

Netflix authenticates 200M+ subscribers across devices using short-lived tokens with device-specific refresh tokens. Each device session is independently revocable without affecting other logged-in devices.

Common Pitfalls

1. Storing passwords with MD5 or SHA-1 instead of bcrypt/Argon2 — these are fast hashes designed for speed, not security, and are trivially crackable with GPU hardware
2. Using long-lived JWTs (24h+) without a refresh token rotation — a stolen token gives an attacker access for the entire validity period with no way to revoke it
3. Not validating the JWT algorithm header — the 'none' algorithm attack tricks servers into accepting unsigned tokens if the validation library is misconfigured

Interview Questions Worth Practicing

1. How would you design an authentication system for a microservice architecture with 50 services?
2. What are the tradeoffs between JWT-based auth and server-side sessions?
3. How do you handle token revocation if a user's account is compromised?

The Tradeoffs

• Stateless (JWT) vs Stateful (Sessions): JWTs scale horizontally without shared state, but cannot be revoked instantly. Sessions can be revoked immediately but require a shared store (Redis) that becomes a dependency.
• Security vs UX Friction: MFA, short token lifetimes, and device verification are more secure but add login friction. The right balance depends on what you are protecting.
• Centralized vs Distributed Auth: A single auth service is simpler to secure and audit, but becomes a single point of failure. Distributed validation (JWT) removes the SPOF but makes revocation harder.

How to Explain This in an Interview

Here is how I would explain Authentication in a system design interview:

Authentication is verifying identity — who are you? I would design it with a dedicated auth service behind the API gateway. Users log in with credentials (hashed with bcrypt), and the service issues a short-lived JWT (15 min) plus a refresh token (HttpOnly cookie, 30 days). The API gateway validates the JWT signature on every request — no database call needed, so it scales horizontally. For token revocation (compromised accounts), I would maintain a small blocklist in Redis that the gateway checks. This gives us stateless validation 99.9% of the time with the ability to force-revoke when needed. I would add MFA for sensitive operations (payments, password changes) using TOTP or WebAuthn.

Related Topics

• Authorization
• API Gateway
• Rate Limiting
• SSO

Original DosiBridge notes for Authentication: JWT, OAuth 2.0, Sessions and Login Design

This section is written specifically for this page, not copied from a general system-design checklist. The useful way to study Authentication: JWT, OAuth 2.0, Sessions and Login Design is to connect the concept to a trust boundary where convenience must not weaken identity, confidentiality, or auditability. That framing changes the design discussion from definitions to operating choices.

What makes this topic distinct

• Contract Evolution: For Authentication: JWT, OAuth 2.0, Sessions and Login Design, decide the contract evolution before choosing tools; otherwise the design looks clean but fails when authentication changes.
• Idempotency: For Authentication: JWT, OAuth 2.0, Sessions and Login Design, decide the idempotency before choosing tools; otherwise the design looks clean but fails when authentication changes.
• Pagination: For Authentication: JWT, OAuth 2.0, Sessions and Login Design, decide the pagination before choosing tools; otherwise the design looks clean but fails when authentication changes.
• Error Shape: For Authentication: JWT, OAuth 2.0, Sessions and Login Design, decide the error shape before choosing tools; otherwise the design looks clean but fails when authentication changes.
• Consumer Compatibility: For Authentication: JWT, OAuth 2.0, Sessions and Login Design, decide the consumer compatibility before choosing tools; otherwise the design looks clean but fails when authentication changes.

Production review question

If a team adopts Authentication: JWT, OAuth 2.0, Sessions and Login Design, what observable signal proves it helped instead of only making the architecture diagram more fashionable?

Practical metric to track

Track authentication health as a named dashboard or review item: combine one user-facing metric, one saturation metric, and one correctness metric. For Authentication: JWT, OAuth 2.0, Sessions and Login Design, this keeps the discussion grounded in behavior that can be measured after deployment instead of generic advice that sounds good in an interview but never gets verified.