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 are the foundational tool for authentication and state management in traditional server-rendered web applications. Features like forced logout from an admin panel or detecting concurrent logins and expiring prior sessions are possible precisely because the server manages sessions directly. With a single server, storing sessions in process memory is fast and requires no additional setup. But as the service grows and more servers are added, you encounter the problem of a user who logged in on server A having their next request routed to server B, where the session cannot be found. At that point you must either introduce an external session store such as Redis that all servers share, or adopt a sticky session strategy at the load balancer. The amount of data stored in a session is also worth considering in production. Putting too much data in a session increases the load on the store and raises the cost of serializing and deserializing the session. The general guideline is to keep only authentication details and the minimum necessary state in the session, and fetch everything else from the database when needed.