Session

In short: A continuous period of communication between two parties during which state (e.g. login status) is preserved across several individual requests.

In more detail: Since many protocols such as HTTP are stateless by themselves (each request stands on its own), a mechanism is needed to recognise, for example, a logged-in user across several page views — usually a session cookie containing a unique session ID, while the actual data is stored on the server.

In Depth

“Stateless” in HTTP means: the server handles every request completely independently of all previous ones — it doesn’t “remember” anything by itself. For many use cases (a logged-in shopping session, a form spanning several steps) this is impractical, which is why the session concept was built on top: on first contact, the client is assigned a unique, random session ID, which it automatically sends with every further request (usually via a cookie). The server keeps the actual session data (e.g. “user 123 is logged in”) in server-side storage (database, Redis cache or similar) and assigns it based on the session ID.

An important security aspect: session IDs have to be sufficiently random and long so that they can’t be guessed (otherwise “session hijacking” would be possible), and should be transmitted over a secure, encrypted connection (HTTPS) so that they can’t be read in transit. Session cookies therefore usually get the flags HttpOnly (not readable via JavaScript) and Secure (only sent over HTTPS).

See also: Cookies, Authentication