Stop Using JWTs? Inside the Authentication Debate That Refuses to Die

If you’ve shipped a web app, you’ve probably reached for a JWT. JSON Web Tokens have become the near-default way to handle logins. So why does a loud slice of the developer community keep insisting you should stop using them? A technology everyone once praised gets dragged into the town square every couple of years, and 2026 is no exception.

Let me be upfront: this isn’t a fresh scandal that broke last month. It’s a classic flame war that reignites on a schedule, like clockwork. So instead of chasing one Hacker News thread, let’s look at the structure underneath — why this argument refuses to stay settled.

What a JWT Actually Is

To get the debate, you need the old way first. The traditional approach is the session cookie. A user logs in, the server stores their session in memory or a database, and the user gets a tiny cookie in return. Think of it as a coat-check ticket. The ticket is meaningless on its own — the server holds the actual coat.

JWTs flip that idea. The server stores nothing. Instead, the user’s information gets packed into the token itself, signed, and handed back to the user. The server only verifies the signature on each request. It’s less a coat-check ticket and more a tamper-proof ID card the user carries around.

That distinction is the whole game. Sessions mean the server remembers you. JWTs mean the server just checks your papers. There’s a reason every “cookies vs. sessions vs. tokens” explainer racks up hundreds of thousands of views — miss this split, and the rest of the argument is noise.

Why Everyone Fell in Love

JWT’s headline feature is scalability. Since the server stores no session state, you can spin up a dozen servers without sweating it. A user logs into Server A, their next request lands on Server B, and it doesn’t matter — they’re carrying the token with them.

It also arrived right on time for the microservices era. When your app is sliced into a dozen small services, forcing each one to phone a shared session store is a drag. With JWTs, every service can verify a token independently. Mobile apps and third-party API integrations got easier too. The token travels anywhere.

In short, JWTs gave developers the freedom of a server that doesn’t have to remember anything. The catch — and there’s always a catch — is that the freedom came with a surprisingly steep bill.

So Why the “Don’t Use It” Crowd?

The core critique narrows to one painful problem: a token, once issued, is hard to revoke.

Sessions make this trivial. Want to force-log-out a user? Delete their session record on the server. Done. But a JWT lives in the user’s hands, and the server kept no copy. That token stays valid until it expires — on its own schedule. Change the password, suspend the account, it doesn’t matter. The token keeps working.

Now imagine an attacker steals one. With sessions, you kill it instantly. With JWTs, you can’t, not cleanly. The usual fix is a blacklist — a separate store that records “this token is revoked,” checked on every request. But look what just happened. The moment you add that store, JWT’s signature feature — the server remembers nothing — collapses. You’ve rebuilt a session, badly, just to get revocation back.

The second complaint is size. Because a JWT carries its payload inline, it’s far bulkier than a cookie. That heavyweight token rides along on every single request, and it adds up as overhead.

The third is the footgun problem. JWTs hand you a lot of knobs to turn yourself. Misconfigure the signing algorithm and attackers can forge tokens — a failure mode that’s been reported in the wild more than once. The more powerful the tool, the worse the cut when you grip it wrong. The infamous alg: none exploits are exhibit A.

Does That Mean Going Back to Sessions?

Here’s where you need a steady hand. “Stop using JWTs” is not the same as “sessions are always right.”

The critics’ real message is narrower: for most ordinary web apps, a JWT is overkill. If your service runs on one or two servers, session cookies are simpler, safer, and trivially revocable. The complaint is that too many developers bolt on JWTs they don’t need — because “everyone uses them” or “scalability sounds nice” — without asking whether the trade-off applies to them at all.

The pragmatic compromise the industry actually landed on is more interesting. Plenty of services blend both. They pair a short-lived access token (a JWT) with a refresh token that renews it. Set the access token to live just a few minutes, and even a stolen one expires before it does much damage. There’s a reason every serious auth tutorial teaches the “access token plus refresh token plus cookie” combo — real-world practice already patched pure JWT’s weak spots.

The Takeaway

The lesson buried in this debate is that fashion has no business driving technical decisions. JWTs aren’t a bad technology. They’re just not a master key that fits every lock. The question worth asking is whether your service genuinely needs stateless tokens — or whether you picked them because they looked sharp on a résumé.

So look at your own stack. Is your auth setup there because the problem demanded it, or because everyone else was doing it? That second answer is the one worth catching before it ships.