Security
Session management best practices for web applications
Session IDs, cookie flags, idle and absolute timeouts, regeneration on login, and revocation — the controls OWASP and NIST expect, and why each exists.
The short answer
A secure session uses an unpredictable identifier generated server-side, sent only in a cookie marked Secure, HttpOnly and SameSite, regenerated on every privilege change including login, bounded by both an idle timeout and an absolute timeout, and revocable on the server so that logout and administrator action take effect immediately.
Sources last reviewed .
The controls
- Identifier: at least 64 bits of entropy from a cryptographically secure generator (OWASP Session Management Cheat Sheet), meaningless in itself.
- Cookie: Secure, HttpOnly, SameSite=Lax or Strict, narrowest Domain and Path; a __Host- prefix where possible.
- Regenerate on login and on privilege change, to defeat session fixation.
- Idle timeout and absolute timeout, both enforced server-side. NIST SP 800-63B ties the limits to the assurance level.
- Server-side state or a revocation check, so logout actually ends the session.
- A visible list of active sessions, with the ability to end them.
Idle versus absolute
The idle timeout limits how long an unattended session stays usable. The absolute timeout limits the total lifetime regardless of activity, so a stolen session that is kept busy still dies. You need both; either alone leaves a gap.
Sessions and tokens
When an OpenID Connect provider is involved, your application session and the provider session are separate, and refresh tokens are a third lifetime. Align them deliberately: an application session that outlives the identity session it came from is a common audit finding.
In Authreads
How this applies to Authreads
Idle and absolute session expiry, a device and session inventory, and revocation by the user, a tenant administrator or the product via API are Available, with lifetimes set per tenant. The resolved idle timeout is exposed to relying parties so they can enforce it in their own sessions.
Authreads is a multi-tenant identity platform in beta. Capability status is maintained on /roadmap as Available, In progress or Planned.
Keep reading
Security
Session fixation and session hijacking: how they work and how to stop them
Protocols and how-tos
Logout in OpenID Connect: RP-initiated, front-channel and back-channel
Protocols and how-tos
Refresh token rotation and reuse detection, explained
Glossary: Idle timeout and absolute expiry · Absolute session timeout · Session revocation · Session fixation
Building on any of this?
Tell us what you're putting together. We'll tell you plainly whether Authreads fits it.