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

> 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/

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.

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.

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.

I'm not, first of all, English is not my first language and I dont see any problems with this sentence. This is not AI, and I'm not lying, but you can believe in whatever you want, I really dont care