'Stop using JWTs' meets the people who run JWTs at scale
A gist tells you to drop JWTs for plain session cookies. Then the AWS and identity-platform crowd showed up to point out the standard quietly authenticates half their infrastructure.
The gist's core claim: JWTs were built for ~5-minute tokens, not logins, and 'they are not designed for this purpose, they are not secure.' Use session cookies, or PASETO for signed tokens.
The recurring qualifier from the thread: that's true for browser sessions, and basically only browser sessions.
The flip: one commenter dared anyone to break AWS STS's AssumeRoleWithWebIdentity if JWTs are really that insecure. No takers.
A blanket verdict on a standard that secures the cloud
The gist, resurfaced after a FIFA breach, makes a flat case: "JWTs should not be used for keeping your user logged in. They are not designed for this purpose, they are not secure." Its argument: JWTs target very short-lived (~5 minute) tokens, true statelessness isn't safely achievable, and the spec itself "is not trusted by security experts." The fix it recommends is unglamorous: regular cookie-based sessions, with express-session and a store like connect-session-knex for Node, and PASETO when you genuinely need a signed token.
"For browser-based user sessions" — the missing four words
The most-upvoted response didn't argue the security claim. It scoped it:
"Necessary qualifier: for browser-based user sessions. Plenty of good uses for JWTs for service-to-service communication." — an infrastructure engineer with 8k karma
That same engineer then issued a dare in the thread: if JWTs are so horrifically insecure, go publish a break for AWS STS's AssumeRoleWithWebIdentity, "or don't publish and just exploit it by launching cryptominers in every Fortune 500 production AWS account." Nobody volunteered.
The revocation math runs the other way
The gist's strongest point is that you can't invalidate an individual JWT. But a freelance fullstack dev turned that into an argument for JWTs:
"JWTs have a limited expiry timestamp, so you only ever need to maintain a revocation list for tokens not expired yet... your list of valid sessions is probably orders of magnitudes higher than the revocation list." — a freelance TypeScript and .NET developer from Germany
A short revocation list of not-yet-expired tokens can be cheaper to query than a full table of every valid session. Others noted the XSS scare cuts both ways: cookies leak under XSS too, so "if your website is susceptible to XSS, skill issue."
The real complaint is the boogeyman, not the token
The sharpest line wasn't pro- or anti-JWT. It was anti-absolutism:
"They are secure if they fit your risk profile, a blanket statement like this is just disinformation. Don't treat your peers like idiots." — a commenter objecting to security-by-boogeyman
Strip the dare and the counter-math down and the thread converges on a boring truth the headline can't hold: "stop using JWTs" is right for keeping a browser logged in and wrong for everything else, which is most of where JWTs actually live. The token isn't the bug. Using one tool for a job it was never specced to do is.
Get breakdowns like this every day
The top Hacker News stories, unpacked — by email, Telegram, or RSS.
256KB of code to zero 64KB of memory, fixed mid-emulation
A compiler unrolled a stack-init loop into 65,536 separate write-byte instructions. The x86 emulator team was so offended they taught the translator to detect the pattern and quietly roll it back into a loop.