Session Management Deep Dive¶

Server-side session:  Cookie = "sess_a1b2c3" (meaningless number)
                       Server looks up "a1b2c3" in Redis →
                       {user_id: 42, role: "admin", logged_in_at: ...}
                       The coat (your identity) never leaves the back room.
                       Lose the ticket? Attendant can void that number
                       instantly — the coat is still safe in the back.

1. User logs in with credentials.
2. Server creates a session record:
   session_id = cryptographically random 128+ bit value
   Redis: SET sess:a1b2c3... {user_id: 42, role: "admin"} EX 1800
3. Server sends the session_id back as a cookie.
4. Every subsequent request: browser auto-sends the cookie.
5. Server: Redis GET sess:a1b2c3... → looks up identity, proceeds.
6. Logout: Redis DEL sess:a1b2c3... → session is immediately gone,
   from every app server, instantly.

1. User logs in. Server issues a signed JWT containing claims directly:
   {user_id: 42, role: "admin", exp: 1735689600}
2. Client stores the JWT (cookie, or memory + Authorization header).
3. Every request: server verifies the JWT's signature and claims —
   no database or Redis lookup required.
4. Logout: ...there's no server-side record to delete. The token
   is still cryptographically valid until `exp`. This is "the JWT
   revocation problem," covered below.

Set-Cookie: sess_id=a1b2c3; Secure; HttpOnly; SameSite=Strict; Path=/; Domain=app.example.com

Secure       Cookie is only sent over HTTPS. Without it, the cookie
             leaks in plaintext the moment a user is on an HTTP
             connection (open wifi, downgrade attack).

HttpOnly     JavaScript CANNOT read this cookie (document.cookie
             won't show it). This is the single most important
             defense against session-token theft via XSS — even if
             an attacker injects a script, `document.cookie` returns
             nothing for this cookie.

SameSite     Controls whether the cookie is sent on cross-site
             requests:
               Strict → never sent cross-site, even a legitimate
                        link from another site to yours won't carry it.
                        Best CSRF defense; can break some login flows.
               Lax    → sent on top-level navigation (clicking a link)
                        but not on cross-site POSTs, images, iframes.
                        Good default for most session cookies.
               None   → sent everywhere, must be paired with Secure.
                        Needed for legitimate cross-site use (embedded
                        widgets, some OAuth redirect flows).

Domain/Path  Scopes exactly which hosts/paths receive the cookie.
             Domain=example.com (no leading dot needed in modern
             browsers) sends the cookie to all subdomains — only
             set this broadly if you actually need subdomain sharing;
             otherwise scope it tightly.

Attack:
  1. Attacker visits the site, gets session_id=xyz (unauthenticated).
  2. Attacker tricks victim into using that same session_id — e.g. a
     URL like https://site.com/login?sessionid=xyz on a site that
     accepts session IDs from the URL, or by setting the cookie via
     a subdomain XSS if Domain scoping is too broad.
  3. Victim logs in. If the server keeps using session_id=xyz and just
     attaches the victim's identity to it, the attacker's copy of
     xyz is now a valid, authenticated session for the victim.

Defense: regenerate the session_id on every privilege change, most
critically on login. Never keep the same session_id from
pre-authentication into the authenticated state.

  Redis: DEL sess:xyz (the old, pre-auth session)
         SET sess:NEW_RANDOM_ID {user_id: 42, ...}
         Set-Cookie: sess_id=NEW_RANDOM_ID

Hijacking: attacker obtains a valid session_id through network
sniffing (no TLS), a logged session_id in a proxy/access log, or
XSS reading document.cookie. With the raw session_id, the attacker
IS the user until the session expires or is invalidated.

Why HttpOnly specifically matters here: an XSS bug is common —
one unescaped user input, one vulnerable dependency. Without
HttpOnly, that single XSS bug reads document.cookie and exfiltrates
the session_id to an attacker-controlled endpoint in one line of
injected JavaScript. With HttpOnly, the same XSS bug can still do
damage (DOM manipulation, CSRF-adjacent tricks) but cannot read or
exfiltrate the session cookie directly — it has to trick the browser
into making authenticated requests instead of stealing the credential.

Sticky sessions (session affinity)
  Load balancer routes a given client always to the same app server,
  which holds the session in local memory.
  ✓ No shared store needed, low latency
  ✗ Server restart = every session on it is gone
  ✗ Uneven load if some users are much more active than others
  ✗ Autoscaling is awkward — new servers get no traffic until old
    servers' sessions expire

Centralized store (Redis)
  Every app server is stateless; session lives in Redis, accessible
  from any server.
  ✓ Any server handles any request; clean horizontal scaling
  ✓ Instant revocation (DEL the key)
  ✗ Redis is now a dependency on the critical path of every request
  ✗ Redis outage = every session becomes unreachable, mass logout
    (mitigate with replicas + sane failover, but it's still a
    centralized dependency that didn't exist before)

Stateless JWT
  No shared store at all; identity travels in the token.
  ✓ Zero session-store infrastructure, zero lookup latency
  ✓ Trivially scales across any number of servers, any region
  ✗ Can't revoke before expiry without reintroducing a store
    (a blocklist), which quietly turns this back into "centralized
    store," just for revocations instead of full sessions

Option 1: Just wait it out
  Set exp short (5-15 min). A stolen or compromised token is only
  dangerous for that window. This is the real-world default — you
  don't get true revocation, you get bounded exposure instead.

Option 2: Blocklist
  Maintain a store of revoked token IDs (jti claim) that haven't
  yet naturally expired. Every request checks: "is this jti
  blocklisted?" You've reintroduced a centralized lookup on every
  request — you no longer have a stateless system, you have a JWT
  with extra steps.

Option 3: Short-lived access token + server-tracked refresh token
  The pattern everyone actually converges on (see OAuth2 & OIDC:
  Refresh Token Rotation). Access token (JWT, 5-15 min, stateless,
  unrevocable) does the high-frequency work. Refresh token (server-
  tracked, revocable, in Redis/DB) is checked only when minting a
  new access token, which happens far less often. "Revoke" a user
  really means: delete their refresh token record. Their current
  access token is still valid for whatever's left of its short TTL,
  then it can't be renewed.

Absolute expiration:  session dies exactly 30 min after login,
                       no matter how active the user is. Simple,
                       predictable, occasionally annoying (kicks out
                       an actively-working user mid-task).

Sliding expiration:   session's TTL resets on every request/activity.
                       An active user never gets logged out; an idle
                       one expires 30 min after their LAST action.
                       Better UX, but needs a max absolute cap too —
                       otherwise a session that's active forever
                       (a bot, a compromised token being replayed
                       periodically) never expires at all.

Best practice: sliding expiration bounded by an absolute maximum
  (e.g. slides on activity, but hard-caps at 12 hours regardless —
  forces periodic re-authentication even for continuously active
  sessions, which limits the value of a long-lived stolen token).

Normal load: ~500K active sessions, each Redis key ~200 bytes
             (user_id, role, cart_id, last_activity) → ~100MB total,
             comfortably fits in memory with room to spare.

Login surge (flash sale, 10K logins/min for 20 min):
             10K new SET operations/min to Redis — trivial for a
             single Redis primary (handles 100K+ ops/sec easily).

Redis primary fails (no failover configured, hypothetically):
             Every app server's session lookup starts failing.
             500K users appear logged out simultaneously — not
             because their sessions were deleted, but because the
             lookup itself has nowhere to go. This is why "session
             store outage" and "mass logout" are the same incident
             in a centralized-store design.

Mitigation actually in place: Redis Sentinel promotes a replica to
primary within ~10-30 seconds of primary failure. App servers
reconnect via the same logical endpoint. Brief lookup failures
during the failover window get retried; most requests succeed on
retry within the outage window rather than hard-failing to a login
screen.

Session store outage → cascading mass logout
  Centralizing sessions in Redis means Redis is now a single point
  of failure for "is anyone logged in, anywhere." Mitigate with
  replicas + automated failover (Sentinel/Cluster), and design app
  servers to retry-with-backoff on lookup failure rather than
  immediately treating a lookup error as "not authenticated."

JWT secret/key leak = total compromise
  If the HMAC secret (or private signing key) leaks, an attacker can
  forge a valid JWT for ANY user, with ANY role, with no server-side
  record of it ever happening — because validation never touches a
  database. This is categorically worse than a leaked session_id
  (which only compromises the one session it names). Mitigate with
  asymmetric signing (RS256, not HS256) so the resource servers only
  ever hold the PUBLIC key, and rotate signing keys on a schedule.

Clock skew
  A JWT's exp/iat/nbf claims are only meaningful if the validating
  server's clock roughly agrees with the issuing server's. A server
  whose clock has drifted forward will reject valid, unexpired
  tokens early; drifted backward, it'll accept tokens past their
  intended expiry. NTP-synced infrastructure makes this rare, but
  it's a real, previously-seen cause of "random valid users getting
  401s" incidents.

Session fixation left unfixed
  Not regenerating the session_id on login means any pre-auth
  session_id an attacker can plant becomes valid the moment the
  victim authenticates on it.

Overly broad Domain scoping
  Setting Domain=.example.com when only app.example.com needs the
  cookie means every subdomain — including lower-security ones like
  a marketing microsite or a staging environment — can read and send
  that cookie, widening the XSS attack surface to any subdomain.

Decision tree: "spike in logged-out users"
  Correlates with a deploy? → check for an unintentional cookie
    Domain/Path change, or a JWT signing-key rotation without a
    grace period for tokens signed by the old key
  Correlates with a Redis event? → check INFO replication / failover
    logs; likely a primary failover, sessions briefly unreachable
  One geographic region only? → check for a regional cache/CDN
    stripping Set-Cookie headers, or a clock-sync issue isolated
    to that region's hosts
  Single user, repeatedly? → likely legitimate (their device's clock
    is wrong, or they're bouncing between two session stores behind
    a misconfigured LB without sticky routing on a sticky-session setup)