Session
The record that keeps someone logged in between requests: a random ID in a cookie pointing at their login state on the server.
See it
What it is
HTTP forgets you between every request, so a session is the memory bolted on top. When the password check passes, the server creates a record (user ID, created time, device, IP) keyed by a long random ID, and returns that ID in a cookie. Every later request carries the cookie, the server looks the ID up, and the request runs as that user. The cookie value is opaque: it is a pointer with no readable claims inside it, so nobody learns your email or your role by staring at it. That is not the same as harmless. Possession of the raw value authenticates whoever presents it, which is exactly why it has to be treated like a password.
Two shapes. Server-side sessions keep the record in Postgres or Redis, which costs a lookup per request but lets you list a user's devices, revoke one instantly, and ban an account in real time. Stateless sessions pack the claims into a signed or encrypted cookie (often a JWT), so there is nothing to look up and nothing to easily revoke. Most product apps want the server-side kind, because 'log out everywhere' and 'kill this account now' turn out to be features, not infrastructure trivia.
Gotchas: rotate the session ID on login and on any privilege change, otherwise an attacker who plants a known ID beforehand inherits the logged-in session. The cookie is the entire credential, so HttpOnly, Secure, and SameSite are not optional extras. And 'logged in' is not one boolean per user: a person has many concurrent sessions, so model it as a table you can query, expire, and delete rows from.
Ask AI for it
Implement server-side sessions for this app. Create a sessions table with id, user_id, a hashed session token, user_agent, ip, created_at, last_seen_at, expires_at, and revoked_at. On successful login generate at least 128 bits from a cryptographically secure random source, store only its hash, and send the raw value in a cookie set HttpOnly, Secure, SameSite=Lax, Path=/. Rotate the session ID on login and on password or email change, and delete the old row. On each request look the session up, reject revoked or expired rows, and refresh last_seen_at at most once a minute to avoid a write per request. Add logout (delete this row), log out everywhere (delete all rows for the user), and an account settings screen listing active sessions with device, location, and last seen, each individually revocable.