Session

Thanks to cookies, it became possible to exchange identifiers between the browser and the server. But what to associate with that identifier, and where to keep it, are separate problems. Storing user information inside the cookie itself allows the client to read and manipulate the values, and the 4 KB size limit also applies. Leaving in-progress payment data or administrator privileges on the client side is a security risk. Conversely, if the server holds no state at all, it must re-establish from scratch on every request who the user is and what they were doing. That means either repeating authentication or including all context in every request, which is a significant burden. What is needed is a structure where the client receives only a lightweight key, and the actual data associated with that key is kept securely on the server.

As web applications moved beyond delivering static documents to requiring stateful features like login, shopping carts, and payment, a way to layer state on top of stateless HTTP became necessary. Early approaches included embedding session information in URLs (URL rewriting) or passing data through hidden form fields, but these were insecure and cumbersome to manage. Server-side sessions solved the problem with a simple principle: give the client only a meaningless random string (the Session ID) and keep the actual data in server memory. This pattern became a built-in feature of server-side web frameworks from CGI scripts through PHP, Java Servlets, and ASP, and on a single server it worked with almost no additional configuration.

The core mechanism of a session breaks down into three stages. First, session creation. When a user successfully logs in, the server generates a sufficiently long random string as the Session ID, and stores user information in a server-side store keyed by that ID. This ID is delivered to the client browser via the Set-Cookie header. Second, session lookup. Every time the browser sends a subsequent request, the Session ID is automatically included in the cookie, and the server queries the store using that ID to restore the state for that user. From the user's perspective, their login state persists, their cart is remembered, and they see pages appropriate to their permissions. Third, session expiry and cleanup. Sessions are configured with a timeout so that they are automatically deleted after a period of inactivity. When the user logs out, the server immediately destroys the session and the Session ID becomes invalid. For a single server, process memory is sufficient as the session store. But when the system scales out to multiple servers, every server must be able to find the same session regardless of which one receives the request. This is addressed either by moving sessions to an external store such as Redis, or by using sticky sessions, where the load balancer routes the same user to the same server.

Sessions and JWT both solve the same problem of identifying authenticated users across subsequent HTTP requests, but they differ in where the state lives. A session stores data on the server and gives the client only a key (the Session ID). JWT embeds the data itself in the token, which the client carries; the server only verifies the signature. This difference creates distinct strengths and weaknesses. Because the server manages state directly, it can invalidate a specific user's session immediately -- features like forced logout by an administrator or limiting concurrent logins are straightforward. The tradeoff is that the server must maintain a session store, and sharing that store across multiple servers introduces complexity. JWT requires no server-side state, making horizontal scaling simple. However, once a token is issued it is difficult for the server to revoke it unilaterally before it expires. To force logout from the server side, a separate blacklist must be maintained, at which point the server acquires state and the advantage of JWT begins to erode. In practice, it is more useful to ask 'does this system require immediate revocation, or is server statelessness the priority?' than to ask simply 'session or JWT?'.

Sessions fit naturally in systems where operators need to cut off or reshape a user's logged-in state immediately, such as forcing logout from an admin console or limiting concurrent logins. Because the server owns the source of truth for that state, those operational decisions take effect as soon as the session record changes. On a single server, keeping sessions in process memory is often enough to get started quickly. But once the service grows to multiple servers, the problem surfaces immediately: a user logs in on server A, and the next request lands on server B, which cannot find that session. That is the point where teams either introduce a shared external store such as Redis or keep the same user pinned to the same server at the load balancer. The size of the data placed in a session is also an operational choice. If too much data is stored there, load on the store rises and serialization and deserialization costs grow with it. The usual rule is to keep only authentication details and the minimum state needed for the next request in the session, and fetch everything else from the database when needed.