A session is the conceptual unit that stitches a particular user's state (logged-in status, cart, etc.) across many requests on top of stateless HTTP.
The traditional implementation is server-side sessions: the server stores the state and hands the client a session ID pointing to it, usually via a cookie.
In server-side sessions, a successful login makes the server create a session record in memory or a store (Redis/DB) and send a random session ID via `Set-Cookie`. On later requests, the ID in the cookie lets the server find that session and identify the user. Because the state lives on the server, invalidation — logout, forced expiry, permission changes — is immediate and reliable. The cost is that the server holds state, so horizontal scaling needs a shared session store (stateless servers + external store) or sticky sessions.
The contrasting approach is token-based (e.g. JWT): state (identity claims) is carried in a signed token the client holds, so the server can authenticate by verification alone without a session store — great for scaling, but with the trade-off that immediate revocation is hard. In practice, short-lived access tokens plus server-side refresh tokens blend the strengths of both. The key session threats are session-ID theft (XSS) and session fixation, defended by HttpOnly/Secure cookies and regenerating the ID after login.