Token != Stateless

Jishant Sethi — Fri, 24 Jul 2026 18:12:39 +0000

What a Mobile Developer Learned Diving Into Cookies, Sessions, and Auth

A React Native developer's journey from "how do I keep a user logged in?" to the one distinction that made web auth finally click, plus a strong (and debatable) opinion on when to use each.

Back in 2022, I got an opportunity I am still grateful for: working on a real, live React Native project at my previous organization. It was the kind of project you learn a lot on. Along the way, as I picked up TypeScript, I also got my hands dirty with backend work in Node, and I ended up shipping a few backend projects I was genuinely proud of.

I never fully let that go. Even after moving on, I kept building small and medium side projects in Node, partly to stay sharp and partly because I enjoy it. Recently I sat down to catch up on what has changed in the ecosystem, and, as these things go, I fell down a rabbit hole. It started with something that looks deceptively simple: cookies and sessions.

I was not starting from zero. A few days earlier I had been revisiting the JWT, access token, and refresh token model from the mobile side, the stuff you deal with when your app talks to an API. So the vocabulary was not new. But I realized I understood it the way a lot of us do: I could use it, but I could not cleanly explain why it is built the way it is.

So I did the deep dive. Blogs, YouTube, AI tools, the works. And somewhere in there, the whole topic collapsed into one pair of words that tied everything together: stateful and stateless.

This post is me rephrasing that understanding in my own words, through the lens of a mobile developer, and taking a clear stance on the tradeoff at the end. I would genuinely love to hear where you agree or disagree. This is a topic where smart people land in different places.

The problem nobody explains first: HTTP forgets

Before any of this makes sense, one fact has to land: HTTP is stateless. Every request your browser or app sends is treated as if it is the first time the server has ever heard from you. The server handles it, sends a response, and then forgets you completely. The next request is a total stranger knocking at the door.

That is the whole problem. If the server forgets you after every request, how does it know, on your next request, that you already logged in a moment ago?

Everything that follows (cookies, sessions, tokens, the entire dance) exists to answer that single question. Once I framed it that way, the topic stopped feeling like trivia and started feeling like a series of deliberate design decisions.

Three ways to make the server remember you

The naive idea is to store the answer in a cookie, literally loggedIn=true, and let the browser send it back on every request. It works right up until the user opens DevTools and edits it. The data is sitting in the user's hands, so the user can rewrite it. Not acceptable.

The fix is a session. Keep the real data on the server, and hand the browser only a long, random, signed ID, a meaningless pointer. On each request the browser sends the ID, the server looks it up, and finds "this ID belongs to user 5, who is logged in." The sensitive data never leaves the server, so there is nothing worth tampering with in the user's hands.

The mental model that made this stick for me is a coat check. The session is your coat, kept safely behind the counter (the server). The cookie is just the numbered ticket in your pocket. The ticket does not contain your coat and it does not let you walk behind the counter. It only tells the staff which coat is yours. You can scribble a fake number on it, but it will not match any real coat, and you cannot guess a valid one because the real numbers are long and random.

The third approach is a token, most often a JWT. Instead of a meaningless pointer, the token is a signed statement that carries your details inside it: "this is user 5, and here is the proof." The server does not need to look anything up. It just verifies the signature, pure math, and trusts it. That "no lookup" property is the piece that matters, and it leads straight to the idea that reframed the whole topic for me.

(Worth knowing, because experts will ask: a JWT is only encoded, not encrypted. Anyone holding it can decode and read every value inside it. The signature does not hide the data, it only proves the data was not changed. So you put identity details in a token, never secrets.)

The insight: "token or session" is not the real question

For a long time I had these mentally filed as two competing choices, sessions on one side, tokens on the other. That framing is wrong, and untangling it was the single most useful thing I got from this deep dive.

There are really two separate questions here, and we usually jam them into one:

What is written on the thing the client sends? Is it just a reference number that means nothing by itself, or does it actually carry the user's details inside it? A reference number is a session ID. Think of a coat check ticket: the number 47 tells you nothing, it only points to locker 47. Details written on it make it a token. Think of an ID card: your name and role are printed right there on the card.
How does the server check that thing? Does it look it up in its own records, or does it just verify a signature and trust it without storing anything? Looking it up is stateful: the server remembers it. Verifying only the signature with no records is stateless: the server does not remember it, it rechecks it fresh every time.

Here is the part that reframed everything for me. These two questions are independent. Whether something is stateful or stateless is decided only by the second question, the record keeping. It does not matter whether the credential is a token or a session ID. A token that the server looks up in a list is stateful. A token the server only signature checks is stateless. Same token, opposite model. The shape does not decide it, the record keeping does.

	Stateless (no server record, verify by signature)	Stateful (server keeps a record, verify by lookup)
Token (carries data inside it)	Plain JWT. Fast, easy to scale, but you cannot revoke it early. This is your access token.	JWT plus a server side allow or block list. Revocable. This is your refresh token.
Session ID (a pointer)	(rare, not typical)	Classic session stored on the server. The default web setup.

In practice a refresh token is often an opaque random string (a pointer), not a self contained JWT. Either way, what defines it is the right hand column: it is stateful, and therefore revocable.

And here is the kicker: the refresh token you already use in your mobile app is a stateful token. It is stored on the server, looked up when used, and can be revoked. You have been using both flavors this whole time without labeling them. The access token is the stateless one, the refresh token is the stateful one.

So the real decision was never "token or session." It is "stateless or stateful," the storage model. "Token or session" is mostly about the credential's shape and how it travels.

Why this clicked through a mobile lens

As a mobile developer, the fog cleared when I mapped it onto things I already knew.

Within a single request, a backend often attaches data to a request object (like req.user in Express) through middleware and passes it down the chain. That is exactly an Intent extra. It is transient, alive for this one trip, and gone afterward. It cannot carry anything to the next request, the same way an Intent extra does not survive to your next app launch.

To persist across requests, you need something stored. On the web that is the cookie. On mobile, the closest equivalent is SharedPreferences, or, for anything sensitive, the Keystore, Keychain, or EncryptedSharedPreferences: a small, persisted piece of state, one per user, that outlives a single interaction.

And this reveals why mobile leans on tokens in the first place. A browser automatically stores and sends cookies back for you. It is free. A mobile app has no such built in mechanism. So you store the token yourself (in Keystore) and attach it to every outgoing call by hand, which, if you have ever written an OkHttp interceptor that injects an Authorization header, is a pattern you already know by heart. The interceptor is you doing by hand what the browser does automatically with cookies.

That single realization, that tokens are what you use when there is no browser to manage cookies for you, explained more than any tutorial had.

The real tradeoff: speed and scale versus control and simplicity

Once it is framed as stateless versus stateful, the tradeoff is clean.

Stateless (for example a plain JWT) verifies with signature math and touches no database. That makes it fast and, more importantly, easy to scale across many servers, because any server in your fleet can verify a token on its own with no shared store to consult. This is why distributed systems, microservices, and serverless functions love it. The cost is real though: because the server keeps no record, you cannot revoke a stateless token before it expires, not without adding server side state, which partly defeats the point. Your only lever is to make it expire quickly.

Stateful (a session, or a token the server tracks) verifies by looking the credential up in a store the server controls. That gives you instant revocation: kill it immediately, see every active session, log someone out on demand. It is also simpler on the client, since the browser handles the cookie. The cost: every request pays for a lookup, and the moment you run more than one server, you need a shared store (Redis, a database) that all servers can reach. At modest scale this is trivial. At very large or highly distributed scale it becomes a genuine consideration. (To be clear for the experts reading: sessions absolutely can scale with something like Redis. The point is that it is an added dependency and a cost on every request, not that it is impossible.)

This tradeoff is also exactly why the access token and refresh token pairing exists. The access token is stateless and expires quickly (often about 15 minutes) so it is fast and low risk if stolen, because it dies soon. The refresh token is stateful, lives a long time, is sent rarely, and is stored on the server so it can be revoked, and so it can quietly mint new access tokens without forcing the user to log in every 15 minutes. You get stateless speed where the traffic is constant, and stateful control where you can afford the lookup.

The recommended hardening here, refresh token rotation with reuse detection, is worth knowing and worth being honest about. Each time a refresh token is used, the server retires it and issues a new one. If a retired token ever shows up again, that reuse is treated as a theft signal and the whole token family is revoked. It is clever, but be precise about what it does: it detects a compromise after the fact and limits the damage. It does not prevent the initial theft, and it relies on the real client eventually colliding with the stolen one. No single mechanism here is a silver bullet, which is really the recurring theme of the whole topic.

So which should you use? My stance.

Here is where I will plant a flag, and where I most want your pushback.

My default is stateful, meaning sessions. For a typical web application, a browser front end (rendered on the server or a single page app) talking to a single backend at ordinary scale, sessions give you simplicity and instant revocation, and the scaling "cost" is largely theoretical at the sizes most apps actually operate at. I would argue that reaching for stateless JWTs "because they scale" is, for a lot of teams, solving a problem they do not have while quietly giving up revocation. This is not a fringe view either. A sizeable and vocal part of the security community argues against using JWTs as your session mechanism for exactly this reason.

I go stateless when the topology actually demands it. Concretely, I lean toward tokens when any of these are true:

There is a native mobile app (no browser to manage cookies automatically).
The system is microservices or serverless, where a shared session store becomes a bottleneck or an awkward dependency.
The API is consumed by third parties or many independent clients.
There is a genuine need for horizontal scale where session lookups on every request across a large fleet actually hurt.
You are using an identity provider or SSO (OAuth 2.0 or OIDC) that hands you tokens as part of the protocol anyway.

Notice what decides it: topology and requirements, not the language, and not the word "enterprise." As an aside, this is why Java and Spring apps feel stateful by default (the servlet HttpSession has been the native path since the 1990s) while modern Spring REST APIs and microservices happily go stateless with JWT. Same rule, different starting defaults.

If I had to compress it to one sentence: stateless is a trade you make to buy scale and distribution, so if you are not buying those, do not pay the price.

The bigger takeaway

Two things stuck with me beyond the auth details.

First, good security is layered tradeoffs, not walls. You rarely make an attack impossible. You make the direct attack impractical, then stack defenses that detect and limit the indirect ones. Tokens that expire quickly, rotation, reuse detection, HTTPS, HttpOnly, revocation: each closes a different gap, and none is sufficient alone.

Second, and this mattered most for me as someone still growing into backend, almost none of this is Node specific. Cookies, sessions, tokens, statelessness, the client and server split: these are properties of the web, not of one language or framework. The syntax and library names change when you move to FastAPI or Spring. The concepts do not. That portability is exactly why deep diving once, from first principles, is worth far more than memorizing one framework's auth recipe.

That is my understanding, rephrased in my own words. I am sure many of you have scars and strong opinions here, so I will ask directly: in your last project, did you go stateful or stateless, and what actually made the call? I would love to learn where your experience differs from mine.

DEV Community: Jishant Sethi