Session-Cookie, JWT, and SSO: How Web Authentication Actually Works
Choosing between sessions and tokens isn't a matter of fashion; it determines how you handle logout, scale across servers, and defend against XSS versus CSRF. Getting the combination wrong — JWT without a refresh-and-blacklist strategy, or sessions without shared Redis in a distributed deployment — creates outages and security gaps that only surface in production.
HTTP has no memory, so every authentication scheme is a workaround for that fact. Session-Cookie keeps user state on the server and hands the browser a short-lived ID; JWT packs user claims into a signed token the client carries around; SSO layers a central authority on top so one login unlocks multiple systems. Each approach shifts the trade-offs between server load, revocation control, cross-domain support, and attack surface.
The guide walks through the mechanics with sequence diagrams and TypeScript snippets: Express sessions backed by Redis, JWT issuance and refresh-token rotation, and CAS/OAuth redirect flows. A comparison table lines up token size, scalability, logout difficulty, and the specific attack each scheme is most vulnerable to — CSRF for sessions, XSS for JWTs stored in localStorage.
A decision flowchart and scenario table close the loop. Monoliths still favor Session-Cookie for simplicity and instant kick capability. Microservices and mobile apps lean toward JWT for stateless verification. Multi-system enterprise setups need SSO, implemented via shared cookies on the same domain or CAS/OAuth across domains. The underlying authentication mechanism — session or JWT — is independent of the SSO architecture sitting above it.
JWT's 'stateless' label is misleading in practice — the moment you need logout or token revocation, you reintroduce server-side state through a blacklist or token version field, eroding the very advantage that justified choosing JWT.
The security model flips depending on where the token lives: Authorization headers protect against CSRF but expose the token to JavaScript; HttpOnly cookies protect against XSS but require CSRF mitigation. There is no single safe storage location, only a choice of which attack class to prioritize defending against.
SSO implementations often conflate authentication and authorization layers. CAS is a pure authentication protocol; OAuth 2.0 was designed for delegated authorization and only becomes an authentication solution when paired with OIDC. Misunderstanding this distinction leads to over-permissioned third-party integrations.
The guide's decision flowchart correctly identifies 'need instant kick' as the pivot point for JWT versus Session-Cookie, but many teams underestimate how often that requirement emerges — compliance, security incidents, and user de-provisioning all demand it.