Session-Based Authentication: Secure Cookies, Rotation, Expiry, and Server-Side State
Session-based authentication gives the browser a random session identifier while the trusted authentication state remains on the server.
Keep Session IDs Meaningless and Random
The cookie should contain an unpredictable identifier—not roles, passwords, or sensitive user data that the server blindly trusts.
Generate IDs with a cryptographically secure random source and store the authoritative session record server-side.
Harden the Cookie
For normal first-party browser sessions, a strong baseline is similar to:
Set-Cookie: __Host-session=...; Secure; HttpOnly; SameSite=Lax; Path=/
Use SameSite=Strict where the UX allows it. __Host- cookies must be Secure, use Path=/, and omit Domain, reducing subdomain cookie scope problems.
Cookie-authenticated state-changing requests may still need explicit CSRF protection according to the application's cross-site model.
Rotate Session IDs
Regenerate the session identifier after authentication and privilege changes to prevent session-fixation problems.
Do not continue using a pre-login anonymous session ID as the authenticated session identifier without rotation.
Enforce Expiry Server-Side
Use both:
- idle timeout — expires inactive sessions.
- absolute timeout — caps total session lifetime regardless of activity.
The browser cannot be trusted to enforce either timeout correctly; the backend/session store must do it.
Support Real Revocation
Server-side sessions make immediate revocation straightforward. Logout, password/security changes, administrator revocation, or suspicious activity can invalidate the session record directly.
For horizontally scaled backends, session state usually lives in a shared durable/fast store rather than one process's memory.
Final Takeaway
Session auth is a strong browser-friendly model when you need simple revocation and authoritative server-side state. Use unpredictable IDs, hardened cookies, rotation after login/privilege changes, server-enforced expiry, and proper CSRF defenses.
References
Discussion (0)