Authentication
Sessions, cookies, JWT tokens, and OAuth 2.0 flows
Authentication on the Web
Proving identity and maintaining state across stateless HTTP
Authentication is the process of verifying who a user is. HTTP is inherently stateless — each request is independent, with no memory of previous interactions. Authentication systems solve this by issuing a credential after login that the client presents on every subsequent request.
The three dominant approaches are session cookies (server stores state), JWTs (token carries state cryptographically), and OAuth 2.0 (delegate authentication to a trusted third party).
- • Server stores session
- • Cookie holds ID
- • Instant revocation
- • Same-origin apps
- • Stateless token
- • Self-contained
- • No DB lookup
- • APIs & microservices
- • Delegated access
- • Third-party login
- • Authorization flows
- • SSO & enterprise
Session-Based Authentication
The classic, stateful approach using cookies
Session Auth Flow
Watch how a login creates a session and subsequent requests are authenticated
User submits credentials (username + password) over HTTPS to the server.
POST /login HTTP/1.1
Content-Type: application/json
{
"username": "alice",
"password": "hunter2"
}Cookie cannot be accessed by JavaScript. Prevents XSS attacks from stealing the session ID.
Cookie is only sent over HTTPS connections. Prevents interception on unsecured networks.
Cookie is not sent with cross-site requests. The primary defense against CSRF attacks.
Sets when the cookie expires. Session cookies (no Max-Age) expire when the browser closes.
JWT Authentication
Stateless tokens that carry signed user claims
JWT Structure & Flow
Click each part of the token to decode it, then step through the auth flow
Click each part to decode it:
JWT Authentication Flow
Stateless by Design
The server doesn't store JWTs. Any server that knows the secret key can verify a token — making JWTs ideal for microservices and horizontal scaling. The downside: tokens cannot be invalidated before expiry without additional infrastructure (a token denylist).
OAuth 2.0 & OpenID Connect
Delegated authorization — 'Login with Google' explained
OAuth 2.0 Authorization Code Flow
Step through the full OAuth flow with four actors: User, Client, Auth Server, and Resource Server
User clicks "Sign in with Google". Client redirects the browser to the Authorization Server with the required parameters.
GET https://accounts.google.com/o/oauth2/auth
?response_type=code
&client_id=my-app-123
&redirect_uri=https://myapp.com/callback
&scope=openid email profile
&state=random_csrf_tokenOAuth 2.0 Grant Types
Used above. Safe for server-side apps. Code is exchanged server-to-server, keeping client_secret out of the browser.
Authorization Code without a client secret. Uses a code_verifier/code_challenge pair instead. Required for public clients.
No user involved. Service authenticates directly with client_id + client_secret. Used for backend services and APIs.
Token returned directly in URL fragment. No longer recommended — replaced by Auth Code + PKCE for SPAs.
Sessions vs JWT vs OAuth
Understanding when to use each approach
Best for traditional web apps where all requests go to the same server or server cluster. Simple, battle-tested, instant logout. Requires a shared session store for multi-server setups.
Stateful — server stores session
Stateless — server stores nothing
Stateless tokens, stateful consent
Needs shared session store (Redis)
Scales easily — no DB lookup per request
Scales well with token introspection
Instant — delete session from store
Hard — must wait for expiry or use denylist
Yes — revoke refresh token at auth server
HttpOnly cookie protects session ID
Risky if stored in localStorage
Access token exposure risk on client
Vulnerable without SameSite/CSRF token
Safe if stored in Authorization header
State parameter prevents CSRF
Difficult — cookies are same-origin
Works across domains via Authorization header
Designed for this — powers SSO
Not designed for it
Can be used but not standard
Primary use case — "Login with Google"
Simple to implement
Moderate — key management matters
Complex — multiple parties and flows
Choosing the Right Approach
- • Sessions — Traditional server-rendered apps, simple setups, need instant revocation
- • JWT — APIs, microservices, mobile backends, cross-domain auth
- • OAuth 2.0 + OIDC — Third-party login, enterprise SSO, delegated access
- • Many apps combine — e.g., OAuth login that issues a session cookie
Security Best Practices
Common vulnerabilities and how to prevent them
Key Terms to Remember
Master these terms for technical interviews