Overview
A session is how a web application maintains a user's authenticated state across many requests. Sessions build on cookies and are the backbone of "being logged in." This lesson explains sessions and how they work.
Learning objectives
- Define a web session.
- Explain server-side vs stateless (token) session models.
- Connect sessions to authentication state.
Core concept
A session represents an ongoing authenticated interaction between a user and the application. After login, the app creates a session and links subsequent requests to it — usually via a session identifier stored in a cookie. Two broad models:
- Server-side sessions — the server stores session state and the cookie holds only an opaque session ID pointing to it.
- Stateless/token sessions — the session state (claims) is encoded in a signed token (e.g. a JWT) held by the client; the server validates the signature rather than storing state.
How it works
On login, the app establishes the session and returns an identifier (session ID cookie) or token. Each later request carries it, and the server uses it to recognize the user and their authenticated state — so you are not asked to log in on every page. In the server-side model, the ID is a meaningless reference to state kept safely on the server; in the token model, the client holds signed claims the server verifies. Either way, the identifier/token is the "key" to the account for that session and must be protected.
Practical example
After login, a server-side session app sets session=a1b2c3... (an opaque ID); the server maps that ID to "logged in as Alice." Every request with that cookie is treated as Alice's. A token-based app instead returns a signed token containing Alice's identity, which the server verifies on each request. In both, possession of the identifier/token equals being Alice for that session — hence its protection is paramount.
Cybersecurity relevance
Sessions are the target of session hijacking (stealing the ID/token to impersonate a user) and session fixation (forcing a known ID onto a victim). Their security depends on unpredictable identifiers, protective cookie flags, proper expiration, and correct logout/invalidation (covered in this module). Token models add concerns like signature verification and revocation. Because the session is what proves "who you are" after login, weaknesses here can fully compromise an account.
Common mistakes
- Putting sensitive/authoritative data in a client-held token or cookie without integrity protection.
- Confusing authentication with session management — logging in is one step; safely maintaining the session is another.
- Neglecting session expiration and invalidation, leaving stale sessions usable.
Key takeaways
- A session maintains a user's authenticated state across requests, tracked by an identifier (usually a cookie) or a signed token.
- Server-side sessions store state on the server (cookie holds an opaque ID); token/stateless sessions encode signed state on the client.
- The session identifier/token is the key to the account for that session; protecting it (and expiring/invalidating sessions) is essential against hijacking and fixation.
Check your understanding
- What is the difference between a server-side session and a stateless/token session?
- Why is the session identifier or token effectively equivalent to the user's identity for that session?