Authentication — JWT, OAuth 2.0, and Session-Based Auth Compared
The Interview Question
Compare JWT authentication, session-based authentication, and OAuth 2.0. When would you use each?
Expert Answer
Session-based auth is the traditional approach: user logs in, server creates a session stored in memory or a database, and sends back a session ID in a cookie. The server looks up the session on every request. It's simple and easy to revoke (just delete the session), but requires server-side storage that must be shared across instances in a load-balanced environment (sticky sessions or a shared session store like Redis). JWT (JSON Web Token) is stateless: the server signs a token containing the user's identity and claims, and the client sends it with every request (usually in the Authorization header). The server validates the signature without any database lookup. JWTs are great for microservices and APIs because any service with the signing key can validate them. The downside: you can't revoke a JWT before it expires without maintaining a blacklist, which defeats the stateless advantage. OAuth 2.0 is not an authentication protocol — it's an authorization framework. It lets users grant third-party apps limited access to their accounts without sharing passwords. The flows (authorization code, client credentials, etc.) result in access tokens that grant specific permissions. Use session-based for traditional web apps, JWTs for APIs and microservices, and OAuth 2.0 when you need third-party authorization.
Key Points to Hit in Your Answer
- Session-based: server-side state, easy revocation, requires shared storage for scaling
- JWT: stateless, self-contained, can't be revoked without blacklist, good for microservices
- OAuth 2.0: authorization (not authentication), for third-party access delegation
- JWT should be short-lived (15 min) with refresh tokens for new access tokens
- Store JWTs in httpOnly cookies (not localStorage) to prevent XSS theft
- OpenID Connect (OIDC) is the authentication layer built on top of OAuth 2.0
- Never store passwords in plain text — use bcrypt, scrypt, or Argon2
Code Example
// JWT structure: header.payload.signature
// Header: {"alg": "HS256", "typ": "JWT"}
// Payload: {"sub": "user_123", "role": "admin", "exp": 1735689600}
// Signature: HMAC-SHA256(header + "." + payload, secret)
// Server: create JWT on login
const token = jwt.sign(
{ sub: user.id, role: user.role },
process.env.JWT_SECRET,
{ expiresIn: '15m' }
);
// Server: validate JWT on request
const decoded = jwt.verify(token, process.env.JWT_SECRET);
// decoded.sub = "user_123"
// Refresh token flow
// 1. Login → access token (15min) + refresh token (7 days, stored in DB)
// 2. Access token expires → client sends refresh token
// 3. Server validates refresh token → issues new access token
// 4. Refresh token used or expired → user must re-loginWhat Interviewers Are Really Looking For
The key distinction: sessions are stateful (server stores state), JWTs are stateless (client carries state). Know the JWT revocation problem — it's the most common follow-up. Mentioning refresh tokens shows you understand the practical pattern. Distinguishing OAuth 2.0 as authorization (not authentication) is a strong signal. Security awareness: httpOnly cookies, HTTPS only, short token lifetimes.
Practice This Question with AI Grading
Reading about interview questions is a start — but practicing with real-time AI feedback is how you actually get better. Goliath Prep grades your answers instantly and tells you exactly what you're missing.
Start Practicing Free →