Cookie-Based Sessions: Server-Side State, Client-Side ID

Why it exists

HTTP is a stateless protocol, meaning each request is independent and has no memory of past requests. For features like user logins or shopping carts, an application needs a way to remember a user across multiple page loads. Cookie-based sessions solve this by creating a persistent identity for a user's browser.

The mental model

A session managed by Express.js is like a coat check. The server is the coat check room, holding all the user's data (the "coat"). The user's browser just holds a small, unique ticket (the session ID cookie). When the user makes a new request, they present the ticket, and the server retrieves their specific data. The actual session data never leaves the server; only the identifier does.

How it works

When a user first interacts with a site using express-session, the middleware generates a unique session ID. It creates a session object on the server (in a session store) and sends the session ID to the browser via a Set-Cookie header. On every subsequent request from that browser, the cookie is automatically sent back. The middleware reads the ID, retrieves the corresponding session data from its store, and attaches it to the request object, typically as req.session.

When to use it

Use this for managing any state that is specific to a user and needs to persist across multiple requests. It's the standard for implementing user authentication, shopping carts, and multi-step forms in Express. It's secure because sensitive session data remains on the server.

When not to use it

Avoid this pattern for fully stateless APIs that rely on tokens (like JWTs) in headers for authorization. The biggest footgun is using the default server-side session storage, MemoryStore, in a production environment. It is not designed for production, will leak memory, and does not scale beyond a single process. You must configure a robust, external session store like Redis or a database for any real application.

One canonical example

A user logs into an e-commerce site. The server validates their password, creates a session, and stores { userId: 42, role: 'customer' } in its Redis session store. The server sends a cookie containing only the session ID back to the browser. When the user tries to access their account page, the browser sends the cookie, express-session uses the ID to fetch the session data from Redis, confirms the user is logged in, and renders the page.