There are a number of easy-to-make mistakes with all security software. That doesn't mean it's not worth using; it just means that we should build the tooling we need in the open as shared software, so that the wisdom of crowds prevails.
Almost exactly the same set of problems exists with signed x509 certificates, but I doubt anybody would tell you not to use them. They'd just say "make sure you don't implement your own validation, unless you absolutely have to, which you don't, and even then only with lots and lots of review/audits." The wisdom with JWT should be the same, IMO.
In the context of security analysis, this is a vacuous statement. There's almost always something you can do to screw a security construction up. An important goal of security engineering --- and the overriding goal of modern cryptography engineering, in particular --- is to minimize the set of things that can go wrong. This is why we generally feel safer deploying Rust and Go code than C code, why we use Curve25519 instead of the NIST P-curves, and why crypto engineers generally recoil from JOSE and JWT, a set of standards that seem to have gone out of their way to maximize what can go wrong.
As a telling example, compare JWT to Macaroons, a standard built effectively on one extraordinarily simple cryptographic primitive that is simultaneously safer and does more than JWT.
From the vantage point of cryptographic security engineering, JWT is a cargo cult. Most projects would be better off avoiding it entirely.
To be honest, and with all due respect, avoiding JWT outright feels a lot like a cargo cult to me. I have yet to see a solid argument against JWT itself, aside from the criticisms you just gave of "it doesn't minimize the set of things that can go wrong." In reality, that statement is like saying "x509 doesn't minimize the set of things that can go wrong."
The criticism is leveled at JWT as if the JWT spec attempts to be anything but "a compact, URL-safe means of representing claims to be transferred between two parties," to quote the spec. I think JWT is better understood as what it intends to be, a simple standard for easily-understood claim sets, that more finely detailed, granular, and secure standards can be built atop.
Admittedly, I'm reading about macaroons for the first time, but from what I can tell they're a higher level concern than something like a JWT. I'm not sure I would actually try it, because it wouldn't be very efficient, but I'd wager you could implement macaroons securely, using JWT as the container for the claims (including claimed constraints) and HMAC signatures.
Maybe I'm totally off base, and if so I'd love to take the time to understand how, but I don't see how JWT as the tiny spec it is, or JWS/JWE, again rather small specs, have done anything to maximize what can go wrong, as much as they are deliberately reducing their surface area to be composable, and to allow other standards to compose them into more secure, minimally faulty specs.
I'm not sure how you can "cargo cult" not casually adopting some random piece of technology. The Pacific cargo cults transformed incidental interactions with modernity into religious venerations; aboriginal islanders got free supplies from visiting GIs, believed the experience to have been supernatural, and built wooden airplane replicas as idols in hopes of summoning those benefits anew. The comparison to JWT is pretty clear: people add these coconut phones to their applications in hopes of gaining some ineffable "cryptographic security". Meanwhile: the cryptography engineers look on in baffled wonderment.
I've written many, many times on HN about problems with JWT and I'm by no means the foremost critic of the standards. Here's a starting point:
I don't know anyone competent who believes the JWT/JOSE specs to be "tiny"; for instance, they incorporate X.509.
Here's a piece we wrote last year that goes into the tradeoffs between different inter-service auth mechanisms (including Macaroons), and discusses the various attributes you might, in the abstract, get from them:
I'm disappointed. From your reputation and from having heard you speak on podcasts, I expected a bit more enlightening and friendly conversation than condescension and subtle insults.
Regarding cargo cults around an opinion, consider this scenario:
1. Be a successful public figure in some domain.
2. Share opinion related to said domain.
3. People elevate opinion itself because of relation to successful individual without adequately examining and understanding the facts.
I'm not saying you're wrong, but I am saying I'm not satisfied with the arguments I've seen. The JWT spec (specifically, the RFC) simply leaves many decisions up to people building on top of it. Given its flexibility, I fail to see how any of your arguments preclude it from being used as part of a stricter standard that is more "misuse resistant."
Regarding blind buzzword acceptance, though, that's a human problem, not a technology problem. If something is useful, and intuitive enough that it gains popularity, I can guarantee that many people will find a way to misuse it while stamping the buzzword on their resume.
I believe the point being made is that flexibility is itself a misfeature that enables misuse. While you are absolutely correct that JWTs could be part of a stricter standard less enabling of misuse, they do not themselves constitute such. And for many purposes, other more specialized and suitable standards (such as Macaroons) already exist.
What podcasts have you heard me on? I think I've guested on one in my entire life? (Podcasters: invite me!) You might have me confused with Marco Arment.
I don't think you've written anything else here that I haven't already responded to with the links I've provided or things I've written in this thread, and don't see much point in repeating myself.
Shoot. I've gone and mixed you up with Patrick McKenzie. If I remember correctly, he must have talked about your interactions a lot on that particular podcast. My mistake.
Saying "all security software has flaws" advantages the software with the most flaws and disadvantages the software with the fewest number of flaws. There are many, many better solutions for the problem JWT solves, there are not many better solutions for X509, which is why people keep using X509.
It is significantly more difficult to misuse e.g. golang.org/x/crypto/nacl/secretbox than JWT.
I never said "all security software has flaws," since that has a substantially different meaning than my comment.
While I'm not arguing with your statement regarding ease of misuse, you should also consider the trade-offs. It's also significantly easier to misuse a pocket knife than a butter knife for the same reason. Butter knives are designed for a small set of problems and deliberately have duller edges to avoid some of the potential downsides of pocket knives. That doesn't make pocket knives useless, it just means that you might need to be trained on safely using a pocket knife, whereas I'm totally comfortable handing a butter knife to my four-year-old. If you're going to be trusted with security, you're really going to need either a) a sharper knife, or b) to understand which knives you're okay handing to your coworkers, or c) to be able to train your coworkers on proper knife safety so they can also use the more flexible tools, but still safely.
Well the good news is I've written about this exact subject at length!
I have seen JWT implementations at five or six different companies now, tokens have never been used for more than one use case. For each specific use case you'd actually want to use it with there is a better solution that doesn't involve JWT, like secretbox or HMAC-SHA256.
You might be happy to see the PASETO spec, which (for v2) uses XChaCha20-Poly1305 for encryption, Ed25519 for signatures, separates the two logically, and doesn't allow for runtime ciphersuite negotiation. (v1 achieves a similar result with AES-CTR+HMAC-SHA384-EtM and RSASSA-PSS.)
It's similar to the advice given above, but also caters to that itch that some project managers have to only implement industry standards (which PASETO is slowly becoming).
I don't think X509 or public key crypto is as scary as it looks, once you understand what you're actually dealing with and how the openssl related libraries work.
There is definitely a UX issue though, and—without intending to be disrespectful—junior devs coming into programming through Javascript, or building basic microservices, are going to see a lot written about JWT and how easy it can be to work with, and suddenly JWT is the solution.
The API for JWT in most cases is encode/decode, and you provide the payload, the options, and the key. The API for libraries linked with OpenSSL is typically a lot more verbose, so you have to understand what you need to work with, or how you might need to extract a fingerprint, convert to DER, or whatever.
Beyond that, a lot of us in the web world might associate X509 with SOAP and XML, and plenty of people will avoid XML at all costs by virtue of it being XML. There's no reason why you couldn't use X509 in a JSON payload.
I'd like to hear more about why X.509 and public key aren't scary, when the prevailing attitude in the crypto engineering community is that they're terrifying sources of surprising game-over vulnerabilities. How many people do you think there are in the world that can reliably and safely evaluate an arbitrary X.509 document in a de novo implementation?
Almost exactly the same set of problems exists with signed x509 certificates, but I doubt anybody would tell you not to use them. They'd just say "make sure you don't implement your own validation, unless you absolutely have to, which you don't, and even then only with lots and lots of review/audits." The wisdom with JWT should be the same, IMO.