What is a session (in auth)?

In authentication, a session is the server-side record that a particular user is currently signed in. It’s how your app remembers “this browser is authenticated as Jane” across multiple requests.

How sessions work

1. User signs in successfully
2. Server generates a random session ID
3. Server stores the session in a database (or Redis): {session_id, user_id, expires_at, ...}
4. Server sets a cookie with the session ID
5. On every subsequent request, the browser sends the cookie, the server looks up the session, and attaches the user to the request

Session properties

• Session ID — a random, unguessable identifier (32+ bytes of entropy)
• Expiration — sessions should time out (sliding or absolute)
• Rotation — the ID should change on every privilege change (login, MFA, impersonation)
• Revocation — admins can invalidate a session by deleting the row

Sessions vs tokens

• Sessions: server-side state. Easy to revoke. Simple lookup.
• Tokens (JWT): self-contained. Harder to revoke without adding state back.

For most SaaS, sessions are the right default. Tokens earn their complexity at service boundaries.

Cookie hygiene

The session cookie should always be HttpOnly; Secure; SameSite=Lax. HttpOnly blocks JS access (defeats XSS token theft). Secure requires HTTPS. SameSite=Lax blocks classic CSRF.

See the full auth glossary for related terms.