Chapter 4 — Session-Based Auth

The why

Sessions are the "boring" option. They're also the default choice of banks, government systems, and most server-rendered web apps. Sessions don't get the hype JWT gets, but they're simpler, more secure for browser-based apps, and support instant revocation. This chapter teaches you when boring is better.

Core concepts

How sessions work

1. User logs in → server creates a session record (in DB/Redis) with a random session ID.
2. Server sends session ID to browser as a cookie: Set-Cookie: sessionId=abc123
3. Browser sends the cookie with every request: Cookie: sessionId=abc123
4. Server looks up session ID → finds user data → attaches to request.
5. User logs out → server deletes session record. Cookie is useless.
6. (Optional) Session expires after N minutes of inactivity.

Implementation with express-session + Redis

const express = require('express');
const session = require('express-session');
const RedisStore = require('connect-redis').default;
const { createClient } = require('

Cookie security: HttpOnly, Secure, SameSite

cookie: {
  httpOnly: true,     // ✅ Always
  secure: true,       // ✅ Always in production
  sameSite: 'lax',    // ✅ Default. Use 'strict' for banking apps.
  maxAge: 86400000,   // 24 hours
  domain: 'example.com',

Session fixation and how to prevent it

Session fixation: an attacker sets a known session ID in a victim's browser, waits for them to log in, then uses the same session ID to access their account.

Attacker: visits /login → gets session ID "abc123"
Attacker: sends victim a link: https://app.com/login?sessionId=abc123
Victim: clicks link, logs in. Session "abc123" now contains victim's user data.
Attacker: uses session "abc123" → logged in as victim.

Prevention: req.session.regenerate() after login. This creates a new, random session ID after authentication. The old session ID the attacker set is now useless.

Session store: Redis vs Database vs Memory

Sessions vs JWTs — the real comparison

Real-world example: How banks use sessions

Banks overwhelmingly use session-based auth — not JWTs. Why?

1. Instant revocation. If fraud is detected, the bank can invalidate the session immediately — the next request fails. With JWTs, the access token is valid until it expires (unless you add a blocklist, which loses the "stateless" benefit).
2. No client-side token storage. HttpOnly cookies are invisible to JavaScript, dramatically reducing the XSS attack surface. Banks have strict third-party script policies, but defense in depth means assuming XSS is possible.
3. Idle timeout. Banks set short session timeouts (5–15 minutes of inactivity). The session store handles this with TTL — no custom logic needed.
4. Auditability. Every session is a row in a database. Banks can query "how many active sessions does user X have?" instantly. With JWTs, you'd need a separate tracking mechanism.

Common mistakes

Production notes

• Use a managed Redis service (Upstash, Redis Cloud, AWS ElastiCache) for session storage. Self-hosted Redis is another thing to monitor and backup.
• Set Redis maxmemory-policy to allkeys-lru with a maxmemory limit. Sessions should expire and evict old sessions when memory is full.
• Monitor session count. A spike in active sessions might indicate credential stuffing or a botnet.
• Session TTL vs idle TTL. maxAge sets absolute expiry. Implement idle expiry by touching the session on each request (req.session.touch()).

Performance notes

• Redis session lookup adds ~0.5ms per request. Acceptable for most apps. If 0.5ms is too much, cache the session in the application process memory with a short TTL (5 seconds).
• Don't store large objects in the session. The entire session object is serialized/deserialized on every request. Keep it under 1 KB: user ID, role, a few flags.

Security notes

• Regenerate session ID on privilege changes. User upgrades to admin? New session ID. Password changed? New session ID. This prevents session fixation and ensures old session IDs can't be reused.
• Bind sessions to IP or User-Agent (carefully). Adds security but breaks legitimate users on mobile networks (IP changes frequently). Use User-Agent binding as a weaker signal — flag, don't block.

Exercises

Beginner

1. Set up express-session with the default memory store. Add login, profile, and logout routes. Verify that the session persists across requests.
2. Add Redis as the session store. Verify that sessions survive a server restart.

Intermediate

1. Implement session fixation attack: set a known session ID before login, log in, then use that ID from a different browser. Then fix it with req.session.regenerate() and verify the attack no longer works.
2. Implement session idle timeout: track last activity time in the session. On each request, check if idle time exceeds 15 minutes. If so, destroy the session.

Advanced

1. Build a session dashboard: show all active sessions for a user (device, IP, last activity). Allow the user to revoke individual sessions remotely.
2. Implement rolling session expiry: extend the session TTL on each request, but enforce an absolute maximum of 24 hours, after which re-authentication is required.

Interview questions

Beginner

1. How do sessions work? The server creates a session record (in DB/Redis/memory) with a random ID. The ID is sent to the browser as a cookie. Subsequent requests include the cookie, and the server looks up the session to identify the user.

2. What are HttpOnly cookies and why are they important? Cookies with the HttpOnly flag cannot be read by JavaScript (document.cookie). This prevents XSS attacks from stealing session tokens.

3. What happens when a user logs out? The server deletes the session record. The cookie becomes useless (it references a session that no longer exists). The browser may also be instructed to remove the cookie via res.clearCookie().

Senior

4. Compare sessions and JWTs for a browser-based web application. Sessions: server-side state (DB/Redis lookup per request), instant revocation, HttpOnly cookies protect against XSS, but vulnerable to CSRF (mitigated by SameSite cookies). JWTs: stateless (no lookup), better for microservices, but revocation is complex, and client-side storage is risky (localStorage) or loses stateless benefits (HttpOnly cookie — why not just sessions?). For purely browser-based apps, sessions are generally simpler and more secure.

5. What is session fixation and how do you prevent it? An attacker tricks a victim into authenticating with a known session ID, then uses that ID to hijack the authenticated session. Prevent by: regenerating the session ID after login (req.session.regenerate()), never accepting session IDs from URL parameters, and binding sessions to additional attributes (IP, User-Agent) as secondary checks.

6. How would you handle sessions in a horizontally scaled application? Use a shared session store (Redis) accessible to all application instances. Configure express-session with connect-redis. All instances read/write to the same Redis cluster. Alternatives: sticky sessions (load balancer routes same user to same server — fragile), or JWTs (stateless — but with the revocation tradeoff).

Summary

Sessions are the "boring but correct" choice for browser-based authentication. Store session data server-side (Redis), send only an opaque session ID to the browser (HttpOnly + Secure + SameSite cookie). Regenerate session IDs after login to prevent fixation. Sessions support instant revocation, idle timeouts, and multi-device management. They require a shared store (Redis) for horizontal scaling but are otherwise simpler and more secure than JWTs for browser-based apps.

Quick recall

• Session ID → cookie (HttpOnly, Secure, SameSite=Lax). User data → server (Redis).
• req.session.regenerate() after login to prevent fixation.
• Redis for production session store. Memory store for dev only.
• Session advantage: instant revocation, no client-side token storage.
• Session disadvantage: requires DB/Redis lookup per request (~0.5ms).
• Use sessions for browser apps. Use JWTs for mobile apps and microservices.

Quiz

1. Where is the user's actual data stored in session-based auth? On the server (Redis, database, or memory). The cookie only contains a random session ID.
2. What does the HttpOnly flag do? Prevents JavaScript from reading the cookie — XSS protection.
3. What is session fixation? An attack where the victim authenticates with a session ID known to the attacker, allowing the attacker to hijack the session.
4. Why can't you use the default memory store in production? Sessions lost on restart. Memory leak. Doesn't scale across multiple servers.
5. What is the primary disadvantage of sessions compared to JWTs? Sessions require a server-side lookup on every request (Redis/DB), adding ~0.5–5ms latency. JWTs are stateless — no lookup needed.
6. What does sameSite: 'lax' protect against? CSRF attacks — the cookie is not sent on cross-site POST requests.
7. Why do banks prefer sessions over JWTs? Instant revocation (critical for fraud response), HttpOnly cookies (XSS protection), idle timeouts, and auditability of active sessions.