Authentication
Session policy as data, credentials that survive a database leak, and the defaults that must not be configurable.
Overview
This document covers opaque session tokens over stateless ones, storing credentials so a database leak is not a compromise, expressing session policy as data rather than scattered constants, and the specific defaults that must be forced rather than configured. It closes with the gaps most session implementations share.
Why This Exists
In a cookie-session system the cookie *is* the credential. There is no second factor and no signature to check: whoever presents it is the user, for as long as it is valid. That single property decides most of what follows. It is why the secure flag cannot be a configurable boolean, why tokens are stored hashed, why rotation exists at all, and why the absence of revocation is the most conspicuous gap a session system can have. Every relaxation is a full account takeover rather than a degradation.
Opaque server-side sessions, not self-contained tokens
Credentials and tokens, stored so a leak is not a compromise
Session policy is data
Defaults that must not be configurable
Authenticate, then evaluate account state separately
What most session systems are missing
Related Principles· 3
Related Documents· 3
Referenced By· 4
Version History
- v0.1.0
Initial structure and metadata established.
- v0.2.0
Written from real experience. Covers opaque sessions over self-contained tokens, the different hashing requirements for passwords and tokens, session policy as data including the rotation defect, the defaults that must be forced rather than configured, splitting authentication from account state, and the gaps most session systems share.