What is a session, and why do web applications use them?

A session is a server-side record of an authenticated user, opened after a successful login, so the user doesn't have to re-authenticate on every single request.

Without sessions, HTTP's statelessness would mean typing your password on every page load. Sessions trade a one-time authentication cost for a long-lived "ticket" that the client presents on every subsequent request.

Server side, a session typically holds:

• The authenticated user ID.
• Authorisation context (roles, permissions, tenant).
• Creation time, last-activity time, expiry.
• Optional context like the IP address or User-Agent the session was created with (used for hijacking detection).

Client side, the session ID (the "ticket") is usually carried as a cookie, sometimes as a header or URL parameter.

Trade-off: convenience vs. risk. A session is a long-lived bearer credential — if it's stolen, the attacker has the user's access for as long as the session lives. That's why all the session-management hardening exists: short timeouts, ID renewal, Secure/HttpOnly/SameSite cookies, server-side invalidation on logout.

Tip: "Session" is sometimes used for stateless tokens too (JWTs in Authorization: Bearer). The risks are the same; only the storage location differs.