Read as
Last updated: May 1, 2026
Why this module exists. Every web app makes session decisions in the first month of development that they regret 18 months later. The wrong choice between cookies and tokens, the wrong refresh strategy, the wrong idle timeout — each is technical debt that becomes a breach footnote.
Why this module exists. Every web app makes session decisions in the first month of development that they regret 18 months later. The wrong choice between cookies and tokens, the wrong refresh strategy, the wrong idle timeout — each is technical debt that becomes a breach footnote. This module is the playbook for getting it right the first time.
The four session storage options
| Mechanism | Where it lives | Strengths | Weaknesses |
|---|---|---|---|
| Server-side session + cookie ID | Cookie holds opaque session ID; server has the data | Easy revocation; easy to extend; battle-tested | Server-side state; sticky sessions or shared session store needed |
| Stateless JWT in cookie | Cookie holds the JWT | Stateless; works across services | Hard to revoke before expiry; JWT validation bugs |
| JWT in localStorage | JS-readable | Easy for SPAs | XSS reads it; no httpOnly protection |
| Refresh + access token pair | Refresh in httpOnly cookie; access in memory | Best of both; short access lifetime; refresh revocable server-side | More complexity |
Want this for your team?
Custom team training + practitioner advisory
Beyond the free academy — we run private workshops, vCISO advisory, and red-team exercises tailored to your stack. For Indian SMBs scaling past their first hire.
Book team training call
Replies in 4 working hrs · India-only · Senior consultants