Session store walk-through: opaque ids, two expiries, revocation and outage behaviour

Goal

Keep server-side sessions in a dedicated store with predictable expiry, listing and revocation per user, and a defined behaviour when the store is unavailable.

Prerequisites

The application already issues an opaque, random session id in a cookie with the right attributes; this walk-through covers the store behind that id.

Steps

1. Constraints: a lookup on every request must be fast; a session ends at an idle limit and at an absolute limit; "log out everywhere" must work; the session id must not be recoverable from a copy of the store.
2. Components: the store (a key-value store with per-key TTL, or a database table with an expiry index); a session library shared by all instances; a cleanup job for the table variant; an admin path for revocation.
3. Data model: session(id_hash primary, user_id, created_at, last_seen_at, idle_expires_at, absolute_expires_at, revoked_at, client_summary) with an index on user_id. Store a hash of the id so that a leaked dump yields no usable cookies. The OWASP Session Management Cheat Sheet describes idle and absolute timeouts and states that both values are highly dependent on how critical the application and its data are; keep both as configuration.
4. Reads and writes: per request, look up by hash, check both expiries and revoked_at, and update last_seen_at only when it moved by more than a threshold, to avoid a write per request; on a privilege change issue a new id and delete the old row.
5. Revocation: "log out everywhere" lists rows by user_id and sets revoked_at; a password change or an admin action does the same. In a TTL-only key-value store the user index is a set of id hashes maintained alongside the rows.
6. Failure modes: store outage (fail closed: treat the request as unauthenticated with a clear error, never fall back to trusting the cookie); clock skew between instances (compute expiry from the store's clock or use its TTL); one user with thousands of sessions (cap per user, evict the oldest); replication lag right after login in a multi-node store (read your own write on the login path); expired rows never deleted in the table variant (batch cleanup by the expiry index).
7. Measure: lookup latency, sessions per user, revocation-to-effect time, expired rows outstanding, store error rate and the forced logouts it caused.
8. Not first: multi-region active-active replication, stateless tokens, a device-management UI, session data beyond identity.

Expected result

Each request costs one read and an occasional write, revocation takes effect on the next request, and a store outage produces logouts rather than silent trust.

Limits and test basis

Proposed design, no measurements. Cookie attributes and id rotation are covered by the session management and cookie attributes articles.

A bounded local cache for store outages

Failing closed protects against trusting the cookie, but a store outage of seconds then logs out every user at once. Each instance may keep a short in-memory cache of sessions it has itself validated against the store, keyed by the id hash, with a TTL of tens of seconds. While the store is unreachable, a request whose session is in that cache is served; a request with no cached entry still fails closed. Privileged actions (password change, payment, administration) always require a fresh store read and are never served from the cache. The cache TTL is the upper bound on revocation latency and is recorded next to the revocation-to-effect measurement.