The protocol that powers the web, HTTP, has a peculiar trait: it's stateless. This means every time your browser asks a server for something, like a webpage or an image, the server treats it as a brand-new request from a complete stranger. It has no memory of who you are or what you did just a moment ago. Once it sends you the file, it forgets you entirely.

This is like talking to someone with no short-term memory. You'd have to reintroduce yourself with every single sentence. For just browsing public pages, this is fine. But what happens when you need to log in to an account? The server needs a way to remember who you are from one click to the next.

To solve this memory problem, developers came up with the idea of sessions. A session is like a temporary memory file the server creates just for you. This approach is called stateful architecture, because the server must maintain the user's state (their session). The process works like a valet service.

This session ID is the crucial piece that connects your browser to the server's memory of your login. But how does your browser hold onto that ticket and show it every time?

The magic link between your browser and the server's session is a small piece of data called a cookie. When the server creates your session, it sends the session ID to your browser with an instruction: "Please store this, and include it in every future request you send to me."

Your browser dutifully stores the cookie. From then on, until the cookie expires or you log out, it automatically attaches that cookie to every request sent to that specific website. The server sees the incoming cookie, reads the session ID, finds your session in its database, and knows exactly who you are.

This server-side session model works beautifully for many websites. But it has a significant drawback when a site becomes very popular and needs to run on multiple servers to handle the traffic.

A load balancer distributes incoming requests across these servers to prevent any single one from being overwhelmed. Now, imagine you log in and your request goes to Server 1. It creates your session and stores it. A few seconds later, you click a link. The load balancer sends this new request to Server 2.

Server 2 has no idea who you are. Your session ID is stored on Server 1's hard drive. To Server 2, you're a stranger. It will probably redirect you to the login page, creating a frustrating experience.

There are ways to solve this, like using a central database that all servers share for sessions, but this adds complexity and another potential point of failure. This scaling challenge is a key reason why other authentication methods were developed.

Session-based authentication was a foundational solution to HTTP's stateless nature. By storing user data on the server, it allows for a continuous, logged-in experience. While effective, its stateful design introduces challenges for large-scale applications.