Sessions, cookies and tokens

You open a website, type your email and password, click login. Half a second later you are in — and the site knows who you are on every page you visit, every API call your browser makes, every action you take. You never typed your password again.

What actually happened in that half second? And how does the server keep knowing it is you, request after request, without asking you to log in again every time? The answer involves sessions, cookies, and tokens — three concepts that are often confused but each play a distinct role.

First, a word about cookies

Cookies have a bad reputation. You have seen the banners, accepted the consent dialogs, read the headlines about tracking and privacy. So when developers say "we use cookies for authentication", it is worth clarifying: authentication cookies and tracking cookies are completely different things.

A cookie is simply a small piece of data that a server sends to your browser, and your browser sends back on every subsequent request to that server. That is all it is — a mechanism for the browser to remember something between requests.

Tracking cookies use this mechanism to follow you across websites for advertising purposes. Authentication cookies use the same mechanism to remember that you are logged in. The technology is identical; the purpose is entirely different. One is about privacy; the other is about keeping you signed in securely.

How sessions work

The classic approach to authentication is the server-side session. Here is the full flow:

• You submit your username and password
• The server verifies your credentials
• The server creates a session record — a small entry in memory or a database — containing your user ID and other relevant data
• The server assigns that session a unique ID and sends it to your browser as a cookie
• Your browser stores the cookie and sends it with every subsequent request
• On each request, the server reads the session ID from the cookie, looks up the session record, and knows who you are

This model is simple, well-understood, and has worked reliably for decades. When you log out, the server deletes the session record — and the cookie becomes worthless. If you want to force someone out immediately, you delete their session and they are gone.

Where sessions start to struggle

Sessions work well when you have a single server and a browser-based application. As soon as either of those assumptions changes, complications arise.

If your application runs on multiple servers behind a load balancer, each request might land on a different server. Server A created the session, but the next request goes to Server B — which knows nothing about it. You either need a shared session store that all servers can access, or you need sticky sessions that always route a user to the same server. Both add complexity and become a point of failure.

If you are building a mobile application or a single-page app that calls an API, cookies are awkward to work with. Mobile apps do not have a browser cookie jar. APIs called from JavaScript across different domains run into CORS restrictions. The session model was designed for a web that no longer looks like the web we build today.

How tokens change the equation

Tokens take a fundamentally different approach. Instead of the server storing your identity and giving you a key to look it up, the server encodes your identity directly into a token and gives it to you. The token is self-contained — everything a service needs to know about you is inside it.

The flow with tokens looks like this:

• You submit your credentials
• The server verifies them and issues a signed token containing your identity and permissions
• Your client stores the token — in memory, in local storage, or in a cookie
• On every subsequent request, the client sends the token in the request header
• Each service that receives the request verifies the token's signature independently — no database lookup, no shared state

Because the token is self-verifiable, any server that has the public key can validate it. There is no central session store to coordinate with. A request can land on any server in your cluster and be processed correctly.

Cookies vs tokens — it is not a binary choice

A common misconception is that cookies and tokens are competing alternatives. They are not — they operate at different layers and are often used together.

A cookie is a transport mechanism: it tells the browser to automatically attach a piece of data to every request. A token is a data format: it defines how identity information is encoded and verified. You can absolutely store a token inside a cookie — and many applications do exactly that, because cookies provide built-in browser protections like HttpOnly and Secure flags that prevent JavaScript from reading the token and ensure it is only sent over HTTPS.

The real choice is between session-based authentication and token-based authentication — and even that choice depends on your application's requirements. Traditional web applications with server-rendered pages often still use sessions. APIs, mobile applications, and distributed systems tend to prefer tokens.

Authentication without the plumbing

Whether your application needs sessions, tokens, or a combination of both, the underlying infrastructure — issuing tokens, managing certificates, handling expiry and revocation — requires careful implementation. IdentitySuite handles all of this out of the box, built on OpenIddict and ASP.NET Core Identity, so you can focus on your application rather than the authentication plumbing.