JWT is a scam and your app doesn't need it | Hacker News Reader

JWT is a scam and your app doesn't need it

dusanmalusev.dev

The same criticism can be leveled against a signed session token. Also comparing decryption with a local redis get which is still much slower is wrong. The criticism against long expiration is valid but that is not unique to JWT, and token refresh is not a "patch" on a broken system. This is just way off on everything

Who uses JWT like this anyway?

Typical production architecture would look like - frontend only ever sees an opaque session cookie - bff stores the access token against session and attaches it when calling backend services

Yes, storing JWTs directly in the frontend client is a bad idea but surely there is a better way of communicating that than "JWT is a scam and your app doesn't need it".

> RS256 verification is in the same order of magnitude as a Redis lookup

But the point is that the verification is CPU bound and local to the service - which means that it is horizontally scalable.

Almost every OAuth2 service out there does exactly that: access token for client/bff, refresh token in HttpOnly cookie.

It’s a lot of work to get it right in SSR environments, since both the bff and the frontend need to be able to refresh the access token (preferably transparently during an in-flight request). Even then, access tokens really should expire within a minute or two, not hours or days.

JWT can be short-lived, for example 1 hour. Then on each request if the token is nearing expiration you decide whether to extend it or not, and if so return a replacement JWT with extended expiration. With a short-lived JWT you don't need to invalidate the JWT.

> just put the JWT in an httpOnly cookie

You can have two cookies, one that is signed and httpOnly, and another that is unsigned and readable by JavaScript. Both contain the same information. So JavaScript can read the information in the second cookie, but since it is unsigned, exfiltrating the cookie doesn't compromise security.

Still the same problem, if your account is compromised, you cannot invalidate the session, same for web, same for native app. You need to store it so that it can be blacklisted.

Let's say a friend sends you an exe file, a game they made. You run it, and immediately realize it wasn't actually your friend. The attacker has stolen your JWT session cookie. The attacker hasn't done anything yet - they are configuring their browser cookies to match yours. You go to invalidate your session / change your password, but it doesn't help. The attacker has a full hour to do whatever they want on your account. They use it to send the same malicious exe from your account. If you would've been able to invalidate the session, you could've stopped it.

> and immediately realize

That's a narrow scenario isn't it, if you have to "immediately" realize?

The pattern described is a common Discord account theft method and it has proven very effective at locking people out of their accounts.

The example requires immediate action. If the hacker beats you he can lock you out by taking over the account, it doesn't matter if it is JWT or some other tech.

Why would it require immediate action? Most chat services have a rate limit, stopping them at ANY point prevents it from spreading further. The messages don't get all sent at once, they will use the full access period to send as much as they can. Accounts can't typically be taken over with just a cookie, changing passwords normally requires you to confirm your current one. I hope you haven't designed any services where a cookie is enough to lock people out.

No, it's called an example. I refuse to provide an example for every possible scenario, as that would not fit in the Hacker News comment limit.

Add a client IP field to the JWT. Token is only valid if the request comes from the associated IP. Done.

Geez, I need to re-sign in every time my mobile data switches IP?? IPs are NOT static. Mobile networks change IPs CONSTANTLY. What if I use a VPN (I do) and my IP changes constantly? What if an IOT device on your network is serving as a public residential proxy that anyone can use (more common than you may think), or hell, you have CGNAT and your neighbor does? What if an entire country only goes through one IP[1]? Have you done this in practice?

[1] https://en.wikipedia.org/wiki/User:82.148.97.69

The IP field in particular: no. It was a top of my head solution to a situation that's pretty much fucked. The scenario where an attacker gets control of a client machine is very hard to defend against, regardless of Auth scheme.

But hey, since jwt is so insecure, why don't you go ahead and hack my Minecraft account? I implemented the JWT -based Auth they use, and my username is iworkatmojang.

Get back to me when you've changed my password

No, I will not send you malware. This scenario is about post-hacked where the malware is removed, but the attacker still has the cookies they collected. There should be a way to invalidate those cookies, just like how you can change your password if they got your password.

If you want, however, we can simulate the scenario. Find your JWT token, change your password (commonly invalidates tokens aswell), and then post it here post-invalidation. If it works still, then thats the issue. Though, changing your password commonly requires your current password and not just a cookie, so I wouldn't be able to do that. But I could probably change your username as proof. If it doesn't work, then it was checked against some revocation database that the article talks about, where at that point, where you have you check a database anyway, you might as well just store the session on the server, since the JWT is no longer stateless and provides no advantage over typical sessions.

I've never said JWT is insecure. It's just hard to do it right, even with libraries. Most libraries just give you HERE IS THE SIGNED TOKEN, but everything else is on you. I've implemented JWT many, many times, and I'm really tired of implementing the same thing over and over again. Most of the things you do is boilerplate, but If you never thought about this boilerplate you're vulnerable.

It can be done right, but it's harder than doing something else. Take it like this: IF YOU KNOW WHAT YOU ARE DOING, OK, FINE, GOOD LUCK IF YOU DONT, STICK TO SOMETHING SIMPLER.

Simple solutions are better solutions, and developer time is important. Do you want to maintain simple authentication layer or you want this complex machinery, upgrade library, check for CVE, validate the library implementation, read the RFC. At that point I would be like... NO, I wanna go and do other things I'm interested in.

> Let's say a friend sends you an exe file, a game they made.

1995 called, they want their lame hacking tecniques back

This is badly written? I was gonna try to argument but it just sound like the writer had a bad day configuring a project IAM and put a generic rant online about JWT usage...

If your frontend application connects to multiple protected APIs, you just can't use a session. That's it. Mobile apps and some specific web application need this a lot.

The only true claim I see in this post is > almost every developer shipping it has no idea why.

That's the true problem. JWT is being used as a SSO strategy in the wrong way most of the times.

You dont need jwt so that you can authenticate API or Mobile app. people were doing exactly that long before JWT was invented.

Skill issue. I personally implemented the Minecraft Auth flow with JWT, and it handles ~250k req/s. It has the added benefit that already logged in users are unaffected if the Auth service goes down(Minecraft is a popular target for script kiddies and ddos attacks, so shit happens).

The entire argument the article does about invalidation confirms this: the bit about 5 year tokens. You do automatic token refreshes, which requires 5 extra lines of code on the client, and one network request every 30 minutes or so. Log out? Remove the token from the client, and let it expire in the next <30 minutes. Safe enough for most use cases.

It's fine to default to jwt, but yeah obviously you can screw it up if you implement it bad enough, and there are certain use cases where token expiry might not be safe enough (banking for example. But honestly with a short enough TTL it might be fine even there. You can totally do 5 minute tokens with automatic refresh gated behind user activity, if you need tighter security)

In the per-request cost table the author complains that signature validation is expensive, yet it's ~half the cost of a redis lookup according to the same table!

To me the entire article sounds like arguing that running shoes are bad because the author got a belly ache after eating one.

Can you explain how 30 minutes of unauthorized access is safe enough for most use cases? I feel like you glossed over that.

It's not 30 minutes of unauthorised access, it's 30 a minute window where you have some extra attack surface. It's safe enough because exploiting that small attack surface within the timelimit is sufficiently hard that it can be considered safe.

Of course the only completely hack-proof device is a brick.

I think the perspective is most systems don't need validation based security, only access based security.

So it's fine for some services to serve requests after the access has been revoked for a few extra minutes or seconds.

For some it isn't. I have no say on the matter, I feel like security lax-ness makes sense for games, since jacking sessions with jwt is significantly less consequential and you have other sources to validate session health, such as route and ip address.

You can always revoke jwt if the ip address for which it was issue has changed or the route is different and so on and can be even more secure against forgery attacks.

Still not perfect and I find OP's take the it's good enough for banking to be sus.

But it's definitely not a scam, it's simple easy and trivial to use for a lot of low risk services.

You should build a map of low risk and high risk access and not use jwt for anything high risk, because jwts definitely provider better user experience for relatively less effort and resources and technical complexity needed.

Apple App Store Connect has this issue for example. If you remove or downgrade someone from the store they retain access for however long... and they keep the ability to do destructive actions like remove or change the permissions of other users, at least they used to until a year or so ago when I last checked. They closed my security report as "by design" btw.

Yeah had a similar experience with a Youtube dashboard auth thing, folks in big tech don't care well either does my manager, it doesn't add to my KPIs and making things secure by making customer experience worse is just a product killer apparently and gets shot down real quick.

Honestly all this just makes me feel tired, like real tired, I honestly wished Mythos would set the software world on fire, some folks and companies deserve to burn.

But then I saw it's output and well.. I have KPIs to hit and a LLM slot machine lever to pull.

You can use a more nuanced approach.

What I did in the last systems I created:

1. The JWT expiration depends on the user. Admins get only 1 minute or so, but regular users 1 hour. If I had an SaaS for enterprise customers, I would use very short expiration times for paying enterprise users, but long for non-paying users.

2. When 95% of all requests are reads, and it's not sensitive data, only validate the JWT. For dangerous operations, always require validation of the user status.

3. I prefer to let the server control the JWT lifetime. So the server can respond to any request with a 'token too old' error, and the client knows it must renew it and retry. That allows you to configure the expiration date of the token depending on the operation and how critical it is.

I'm sure those 80 microseconds are going to ruin the performance of that WordPress/Django app!

Why would you want to deal with a bespoke session and authentication table when there's a standard solution out there already? What's the point in figuring out your custom little cookie signature system when every frontend and backend under the sun have a solution ready to go? And somehow, somewhere, Redis is now part of the design to prevent having to do a database round trip for every cookie?

Sounds to me like this is a whole load of work for little benefit. Sure, session cookies just work most of the time, but they have their own disadvantages.

The only tangible benefit to session cookies is that you can log out all existing sessions at the cost of doing a lookup for every request. Most websites don't even offer that functionality, though.

What about the other claims, aud and iss for example. And automatically being able to validate those tokens through OIDC?

And don't pretend that the 2 are not related because typically an OIDC provider is the thing issuing those JWTs.

So, can you simplify, sure. And now every part of your application needs access to that same table of sessions to get revocation.

It works fine for simple applications not for large solutions with many different systems that cross org boundaries. Because in a lot of orgs the boundaries of the services are more organizational than technical. If you want to be the one that makes them all depend on your SPOF, go ahead, I want to see you sell that idea to your CTO

I think JWT-like schemes can enable better machine-to-machine integration.

If you drink all of the koolaid, you can wind up with a system where two different parties securely authenticate sessions without any kind of secrets ever needing to be provided directly. Both parties generate and retain private key material in an HSM and perform signing ops there. The only thing that has to be trusted is the subject of the certificates. Keys can be rotated arbitrarily and the counterparty should not have any issues with this, assuming the standards are followed.

Short lifetime is the best solution to concerns around revocation. The vendor I last integrated with has their opaque tokens expire after 15 minutes. Immediate revocation sounds preferable but in practice there are other controls that will typically compensate for any gaps here (i.e., audit logs & the police). If you are firing someone and you think they might do a really bad thing that the business could never recover from, you should probably disable their accounts about an hour before the call with HR.

While this article raises some pain points, it is really bad advice and while it does seem to come up every now and then, the initial flaw with the argument, which typically leads to it confusing newbies while making more experianced users ignore the valid points is the conflation of Auth with Authz.

Authentication is the process of verifying who a user is, while authorization is the process of verifying what they have access to.

Note the opening claim:

> JWT promises stateless authentication and delivers neither

JWT claims typically are used to pass identity of authenticated users, not to authenticate users, that is important, and I cannot validate a opaque bearer token at all, while we do need something better, opaque bearer tokens are not an improvement for authorization.

> You can't. That's the answer. The token is valid until it expires, full stop. The only way to invalidate it is to store the jti server-side in a revocation list and check that list on every single request. Which is a database lookup. Which is the thing JWT was supposed to let you skip. Congratulations, you've reinvented sessions, badly.

Bloom filters, which are constant factor time add/remove, constant-space set data structure are trivial to implement, if you have something like the expiry time of a jwt to restrict their growth. Even if you had a scalable bloom filter for a narrow temporal high volume need, the sizes are tiny and the performance avoids needing to pound your redis revocation list.

While JWT doesn't have the information hiding capabilities of opaque tokens that must be validated through introspection, with every request needing a call to the authorization server or local cache, Nothing with JWT stops you from doing exactly the same, either in the positive case with a SPoF authorization call, or in the negative case with a bloom-filter in front of a revocation list on redis.

Basically all the options have limits, costs and tradeoffs.

Choosing between JWTs and opaque bearer tokens is a least worst option choice, About which one fits your application’s architecture, security model, and operational needs.

If you need information hiding JWT isn't probably the best choice, if you want flexibility, observability, and performance opaque bearer tokens are probably not the best choice.

Remember there is that nuance and temper your expectations from the clickbait, they don't know your system, your needs, or your risk tolerance.

This is a shift in complexity, not a change in complexity.

JWTs are very helpful if you maintain many downstream services on separate domains that need shared auth and identity infrastructure

How often do we need to revoke individual JWTs anyway? You solve for cookie theft with short expiry and key compromise by rotating keys. I don’t find the revocation issue very compelling as a reason to ditch JWTs.

You have never used "Log me out from everywhere" feature. I've used it. Also it's for I want to change my password and invalidate all sessions.

Is revocation really such a hard problem? Seems you could store a set of revoked tokens in memory and have a background task update it every couple of seconds. I guess it’s a separate set of infrastructure to maintain but I don’t see why it’s always presented as the thing that undermines an entire authentication scheme.

I guess if you need your tokens revoked this millisecond it’ll require an extra synchronous call on every request but that seems like a unlikely requirement. And not that any of this matter for your 10 user app anyway I guess.

I don’t recall ever in my life using that feature on the small number of services that offer it.

You have, and so unknowingly. If you change password, this one triggers, you have to login everywhere. e.g Instagram, Facebook, Github etc.

> JWT is a scam

The article doesn't need clickbait titles either, which is also not a savory practice. Other than that it is good to educate people to make informed decisions on JWT.

This article is completely AI-generated, anyone who reads LLM output often can confirm that. And Pangram confirms it as well. It's one of the more reliable LLM detectors and has an extremely low false positive rate, although in this case it marked Markdown parts too (they're irrelevant since it's a web article, not a normal post).

https://www.pangram.com/history/c68104cd-6072-4f7a-850b-e534...

To be fair here if you look at their "supporting evidence" most of it is pointing at markdown formatting. Some of the other things it points to are also just common in human writing, though the overuse leans more towards coming from an LLM, e.g. two instances of groups of three back to back with inconsistent use of the Oxford comma:

> If you're building a web app, a mobile app, or a first-party API: JWT is the wrong default and you should stop reaching for it. A row in Postgres with a bearer token in front of it is faster, simpler and strictly more secure.

Supporting evidence isn't what makes Pangram mark something as AI-generated, though. And I did call out that in my post specifically. But the post is still 100% generated, it has a distinct Claude-adjacent LLM style.

Some of the extremely obvious examples:

> The pitch is: the server signs it, the client carries it, every subsequent request only needs a signature verification — no database round-trip.

> You can't. That's the answer. The token is valid until it expires, full stop.

> A single opaque token, looked up in Redis with Postgres as the backing store, gives you the same security in one line of middleware. No refresh. No second token. No retry loop. Nothing.

> With opaque tokens this is just… how it works. No mismatch, no hidden tax, no "did they implement the checks correctly" question to lose sleep over.

K, I'll stop authorizing incoming OAuth 2 requests to Amazon AgentCore by validating JWTs before allowing access to agents and gateways.

JWT is fine. The problem is that people are using it for the wrong problems, like session cookies. But that has nothing to do with JWT.

> It's not "JWT is broken". The cryptography is fine. The tymondesigns/jwt-auth package is fine. The concept of using JWT as your app's session is what's broken.

If only that was true. JWT came with a lot of questionable cryptographic choices. It went hard on fine-grained cryptographic agility like it was 1995 all over again. It started with the wrong suite of outdated ciphers like RSA and no good security requirements and implementation guides, and even the notorious "none" algorithm. The end result is a string of CVEs that affected a wide swath of JWT libraries.

JWT has many other ill-conceived features such as embedded JWK, token-declared URLs and the complex mess that is JWE (which you'll need if you want encryption). This complexity, useless features (the "none" algorithm), together with picking algorithms that are hard to implement correctly[1] and not setting any kind of security requirements made vulnerable libraries spread like wildfire, and introduced at least 5 different classes of vulnerabilities[2].

The craziest thing, is that easiest vulnerability to abuse (the "none" algorithm), is a required by the JWT RFC, you read it too literally:

  Of the signature and MAC algorithms specified in JSON Web Algorithms
  JWA], only HMAC SHA-256 ("HS256") and "none" MUST be implemented by
  conforming JWT implementations.

Now, the RFC writers obviously meant that conforming JWT libraries, should support "none" if explicitly requested, but did not mean that the libraries have to accept the "none" aglorithm by default. In fact, it's clearly stated:

  An Unsecured JWS uses the "alg" value "none" and is formatted
  identically to other JWSs [...]

  Implementations that support Unsecured JWSs MUST NOT accept such
  objects as valid unless the application specifies that it is
  acceptable for a specific object to not be integrity protected.
  Implementations MUST NOT accept Unsecured JWSs by default.  In order
  to mitigate downgrade attacks, applications MUST NOT signal
  acceptance of Unsecured JWSs at a global level, and SHOULD signal
  acceptance on a per-object basis

Or in another section:

  Unsecured JWSs (JWSs that use the "alg" value "none") provide no
  integrity protection.  Thus, they must only be used in contexts in
  which the payload is secured by means other than a digital signature
  or MAC value, or they need not be secured.

Unfortunately, the JWA spec is huge and complex because it needs to definy many useful, secure and totally not bonkers algorithms like PBES2-HS256+A128KW and RSAES-PKCS1-v1_5, and the very important(?) reasons for storing the coefficients for RSA. So I guess the end result is that almost nobody ever read the JWA RFC, and somehow half of the first crop of JWT libraries let anyone strip the signature, change "alg" to "none" in the header and freely manipulate the token. Good times.

So yes, stateless tokens are a bad tradeoff for many (if not most) web applications. But even if they weren't, there many formats that would do much better than JWT[3]. If you end up going with JWT, it's really better to thoroughly review your library, and stick to safer algorithms that doesn't result in a 5kb token (I'm looking at you RSA). Ed25519 is now supported by a decent amount of libraries.

[1] https://neilmadden.blog/2022/04/19/psychic-signatures-in-jav...

[2] https://pentesterlab.com/blog/jwt-vulnerabilities-attacks-gu...

[3] https://fly.io/blog/api-tokens-a-tedious-survey/

Thank you very much, YOU ARE SOMEONE YOU ACTUALLY UNDERSTAND WHAT IM RANTING HERE.

You dont need JWT, just use something else and you will be fine, this is the gist of it.

I have a pile of personal criticisms of jwt, but I don't think this article does a great job of arguing against JWTs. For example:

> You can't [invalidate a jwt]. That's the answer. The token is valid until it expires, full stop. The only way to invalidate it is to store the jti server-side in a revocation list and check that list on every single request.

...So the article says you can't invalidate a jwt, and not 2 sentences later, tells you how you can. Of course you can.

> [misc criticisms of refresh tokens]

Mostly agree with this part.

> RS256 verification is in the same order of magnitude as a Redis lookup. And you still have to parse JSON, validate exp, validate iss, validate aud, walk the JWKS cache for the right key, and allocate a few objects the GC has to clean up later. Multiply by your request rate.

I think this misses the mark a bit. Signing/validating a jwt can be done entirely on your application server, which should easily scale horizontally. Any kind of db lookup requires a roundtrip/bottleneck which introduces complexity. So, even if it's the same # of ms, there's still an inherent advantage for validating on your application server IMO.

> Almost no one does [front end verification]

Sure, agreed, but so what? It's a feature that no one uses. That doesn't invalidate other features of jwts.

> The advice goes: don't put the JWT in localStorage because XSS will steal it — put it in an httpOnly, Secure, SameSite cookie so JavaScript can't touch it. Read that sentence one more time. You have just described a session cookie. The browser attaches it automatically, the server reads it on every request, the client can't see what's inside.

Yes, I think from a client perspective, it's fine to think of it like just a session cookie. As many other commenters have pointed out though, it's like a session cookie _with super powers_ because once the request is validated by some kind of front end app server, you can pass that same token around to other backend server and trust the claims inside it and save each of those services from having to do their own lookup. This I Think is the real value of JWTs over plain ol' session cookies.

Yes you can invalidate them, but comes at the cost that you have to write the machinery yourself, that is the point. If you miss something, that's security issues, and I say you can't just because people are not doing it, dont know about it, or think ITS SIGNED, I DONT HAVE TO DO ANYTHING ELSE. Which is false pretenses. Also term invalidation is kinda tricky. YOU CANNOT INVALIDATE IT in a sense token is invalid. It's backlist invalidation, you store it and say this is invalid if you encounter it. You can say it's the same thing for session, yes and no, session have to be stored, deleting them is invalidating them, jwt is build on promise that you dont need to do all this, and this is the pitfall.

> Sure, agreed, but so what? It's a feature that no one uses. That doesn't invalidate other features of jwts.

True is unused feature, but then stateless part falls apart, you don't save anything but introduce complexity and maintainance problems, someone will have to go over that code, understand it and not crew things up.

> I think this misses the mark a bit. Signing/validating a jwt can be done entirely on your application server, which should easily scale horizontally. Any kind of db lookup requires a roundtrip/bottleneck which introduces complexity. So, even if it's the same # of ms, there's still an inherent advantage for validating on your application server IMO.

My position here is, if I have to hit the database, well why then I need the signing part, or encryption part, whats the benefit of it. What I understand from JWT, you dont have to store anything. That was the promise of it, and yet for secure systems you have to store something, at least to be GDPR compliant. AFAIK you need to provide the feature LOGOUT FROM EVERYTHING by GDPR, dont quote me on that, it's what I've seen, not a lawyer, simple developer.

> Yes you can invalidate them

All I'm saying is that if you clearly can, then don't claim that you can't. Maybe claim it's inconvenient or impractical, but it's an absurd paragraph in the original article.

> True is unused feature, but then stateless part falls apart

Maybe a miscommunication, but that part of my comment was referring to validating the token on the client. I don't see how this makes them not stateless. The stateful/statelessness can be entirely confined to the server.

> My position here is, if I have to hit the database, well why then I need the signing part, or encryption part, whats the benefit of it.

It provides a useful token that can be validated once by some kind of front end application server, and then passed around from there to backend microservices which trust the validation from the front end app server. None of the backend microservices need to hit the database again. I tend to agree that the signing/encryption parts are not particularly useful, but that doesn't make jwt a scam (the premise of the article).

> yet for secure systems you have to store something, at least to be GDPR compliant. AFAIK you need to provide the feature LOGOUT FROM EVERYTHING by GDPR, dont quote me on that, it's what I've seen, not a lawyer, simple developer.

To do this minimally, you don't have to store anything under normal conditions. You only have to store the ids of revoked tokens, and only for the lifetime of the token that is invalidated.

Eh. JWTs are super handy if you have a single web experience spread across multiple backend apps on the same domain, with a single SSO server to set up the user auth. Definitely not for storing anything sensitive, but treating it like a fancy session cookie with the minimal amount one needs to securely access resources - customerId or whatever - makes life a lot easier than trying to wire up cookie / session management across a lot of different, disparate apps.

How that is possible, when every web framework has a package for handling sessions, and in a secure manner. Rolling everything on your own is time consuming and error prone. I know you should not use library for everything, but this is solved problem for a long long time (like crypto), and just using of the shelf solution is right choice to me. You can set the session to be across multiple subdomains and it will work out of the box.

Eveything else can use plain tokens stored in the DB

Yeah... but you can't just move a session across a heterogeneous set of servers with different backends, etc... Maybe some of your APIs are on one platform, the apps themselves on another. There are several libs that can help you do that.

JWT is not a solution for that, any regular token fixes this problem. If you need something like that you can build an auth server, and everybody talks to auth server. I've built these kinds of systems, they are complex and working on them is not fun, you have to be really careful not to mess things up and if I have to worry about JWT as well, this is one more problem in a distributed system that if I can avoid, I would gladly.

TBH, I've not found use case for JWTs, maybe I'm not experienced enough and if it's there, there must be a use case for it. But I've found that there are simpler authentication schemes you can do, and I try to do them instead of implementing JWT.

What are you talking about? Good frameworks have support for using guards on endpoints. Typically you add an annotation to the handler and that's it - and your system is then going to be much more secure than most alternative approaches, because the simple one-line guard ensures that only users who are authorized to access a specific resource can access it.

You just haven't understood what JWTs are good for. See my other comment in this thread.

It's so easy to have an LLM generate your blog post without meandering in circles and without all the LLM tells, so why not do it?

I mean, honestly, there are really only two options here:

1. You don't know how to "tune" the LLM output, or

2. The LLM output can't be tuned.

Either one means that you should probably write your own thoughts and not have a probabilistic generator create this word-salad that I found extremely hard to follow!

This post needs an important clarification, which is that it's talking about using JWT for authentication, not authorization.

The uses described in the article assume that authorization of access to resources is handled in some way external to the JWT. This literally takes a system designed to support authorization, ignores that, and uses some other back-end authorization mechanism.

One of the most important features of JWT is its support for capability security[1], via signed claims. If you're just using JWT to authenticate, you're kind of missing the point.

> The payload usually holds a user id, an iat, an exp, a jti, maybe some scopes.

This demonstrates the point nicely. At best, scopes provide some sort of broad authorization such as "read" or "write". But what if you want to prevent IDOR attacks[2] at a low level in your system, to eliminate any possibility of developers accidentally allowing them? Tokens with nothing more than scopes don't help with that at all.

All you need to do to solve that is to add the entity types and IDs that the bearer is authorized to access. So if they're going to a page that displays an invoice, then in the JWT claims you include "invoiceId" (often along with some kind of type field, like "type": "invoice".) The target page checks that the JWT matches the requested resource, and that can indeed be done without any further back-end verification. You would also typically include a tenant ID and other such authorizing identifiers.

Doing this alone will give a system stronger security than 99.9% of systems out there.

Regarding revocation, the point about the above approach is that the tokens are essentially single-use: they authorize access to a particular resource for a short period of time. Basically, whatever the normal "log user out after inactivity" timeout is, the token expiry should be no longer than that.

If you create tokens valid for days or weeks, that's a mistake. You can prevent this simply by giving devs a library that creates the tokens according to org policy.

So yeah, JWTs purely for authentication and doing authorization some other way is a dumb idea, but that doesn't make JWTs a scam, that makes the user ignorant of their real purpose.

[1] https://en.wikipedia.org/wiki/Capability-based_security

[2] https://cheatsheetseries.owasp.org/cheatsheets/Insecure_Dire...

> I am tired of pretending JWT is fine.

I don't get it. Why were you lying to people??? Why were you pretending? Thats not healthy and pretty anti-social.

That's how cargo-culting works.

Who’s still on x86 in 2026?

Who is not, X86_64 is an extension to X86. Same thing, no need to nitpick

Friendly reminder: Some nuclear silo facilities in the US still use 3,5" diskettes. Some highly complex system are by architecture, security issues or by incompetence still stuck in decades old tech. We as engineers oftentimes have to work with that, and keep the system running, if we like it or not.

You cannot refactor an battlecarrier designed in 1979 so easily ;)

> The rest of this post is me showing my work.

No, the rest of the post was written by an LLM.

Why post this AI-generated article? Just to ragebait?

It's not, it's just something that I've had problem with a long time. Not everything is AI generated, and I hate if someone writes AI articles especially something important like this. These are my general thoughts about it, everything here that I explained is the things I've seen in the wild, and what people are doing. I'm just fed up with it

One thing that I did AI generate is the website itself. I really didn't have the time to do it on my own and I vibe coded it

Reply on news.ycombinator.com