The root of most of the points in the article is "when you use JWT for the wrong use case it is bad" which is self-evident. Other than that it is hyperbole imo.

Unnecessarly and overly dramatic, essentially arguing that because JWT/JOSE is insecure because it can be used in an insecure manner.

JWT is multiple layers of bad. My favorite summary is that it has poor implementations of a harebrained scheme designed to solve a problem you don't have.

The idea that I need to read the header, which is unauthenticated, to parse the token violates the Cryptographic Doom Principle. Has that led to vulnerabilities? Of course it has: I just said it violates the Cryptographic Doom Principle.

The idea that it has everything plus the kitchen sink -- even for drastically different behavior and opinions on how the world works, from symmetric encryption to asymmetric signing and multiple implementations of each at that, is anathema to modern cryptographic design. Wireguard has one scheme and it does a lot more complicated stuff than "encrypt a session token".

JWT's saving grace here is that few people implement all of it. And ... that's ... cool? Until they do, of course.

You can argue that something is an implementation problem and not a spec problem. Some issues definitely are, but if every major implementation has the same damn bug, then I think it's a spec problem. Unauthenticated headers are a spec problem. PKCS1V15 enc is a spec problem. The fact that an implementation can patch around it doesn't make it not a spec problem. I'm sitting on several more vulns in ~every JWT library that are, to cryptographers, literally too boring to publish even though one of them is _key recovery_.

Other posters have said that it's silly to say that merely the ability to use it unsafely is a problem. But good crypto looks exactly like bad crypto while you're doing it, and there's good crypto that doesn't have that set of problems, so why would you ever choose the poor design?

(Don't use JWT.)

Most people use the JWT compact serialization, which cannot carry the unprotected header at all. If you're exchanging JWT compact tokens, the header is protected by the signature or the encryption.

What? You mean protected by the _MAC_? The header is never encrypted: the header is how you even figure out what to do with the rest of the message at all. That is why it definitionally can not be protected by it (that's the definition of the cryptographic doom pricnople!) and is how the bugs I am referencing are exploited to begin with. The only sense that a JWT header is "protected" is that the spec calls it that.

Have you ever exploited a JWT vuln? Which one? Because odds are there's a way it boils back down to the JWT header design choice being silly.

I mean there's an easier way to have this conversation: if the header is "protected", how did the alg=none bug ever work?

In a JWS the header is integrity-protected by the signature if the alg isn't none. This is prominently noted in the specs and alg=none artifacts are referred to as "unsecured JWS". In a JWE the protected header is integrity protected by the AEAD cipher, because all encs must be AEAD.

The alg=none substitution issues happened because of bad usage of mediocre libraries. Other algorithm substitution can arise for the same reason. The invalid curve attacks were the ones that the spec didn't call out as a security consideration.

I support the arguments that say algorithmic agility is a bad idea and a new protocol with algorithmic agility shouldn't have come out at a time when other protocols (like TLS) were finally starting to catch on to this fact. But the JWT cat is out of the bag, and won't go back in: it's widely deployed and people are using it thinking it's solving problems they actually have. Education is the proper remedy.

The PASETO effort attempts to provide better answers and better design to an audience familiar with JWT, but there's also been an uptick in the kind of advice that heavily condemns JWT without supplying some migration paths. That latter brand of advice is harmful.

Same points I made before: if more than one library has a flaw, it’s a design flaw and not a one-off implementation flaw, and if you’re trusting the header before you validate (which is necessary!), then it is not meaningfully protecting anything, which is why those bugs work.

And, finally: we’ve put together an extensive list of recommendations, repeatedly, both in general and in the articles on this thread.

So it seems that the Cryptographic Right Answers is lacking a section on "stateless tokens carrying a small payload". What should one do in this case?

I mean, part of the answer is "don't do that" but if you have to, secretbox or PASETO. Part of the problem is that "stateless token" can mean a lot of things depending on context; for internal use you generally want symmetric MAC possibly w/ symmetric encryption, for external use you probably want signing -- all of which have answers in Cryptographic Right Answers :)

I was wondering more about how to format a payload that may be shared between agents in a standard, secure format, but that is probably not even a Cryptographic Question :)

Still the same answer unfortunately: depends on the use case. Sometimes you just want signing, sometimes it's OK to share a key, sometimes...