Things to Use Instead of JSON Web Tokens
In cryptography, we have a concept of &quot;misuse resistance&quot;. Misuse-resistant cryptography is designed to make implementation failures harder, in recognition of the fact that almost all cryptographic attacks, even the most sophisticated of them, are caused by implementation flaws and not fundamental breaks in crypto primitives. A good example of misuse-resistant cryptography is NMR, nonce-misuse resistance, such as SIV or AEZ. Misuse-resistant crypto is superior to crypto that isn&#x27;t. For instance, a measure of misuse-resistance is a large part of why cryptographers generally prefer Curve25519 over NIST P-256.<p>So, as someone who does some work in crypto engineering, arguments about JWT being problematic only if implementations are &quot;bungled&quot; or developers are &quot;incompetent&quot; are sort of an obvious &quot;tell&quot; that the people behind those arguments aren&#x27;t really crypto people. In crypto, this debate is over.<p>I know a lot of crypto people who do not like JWT. I don&#x27;t know one who does. Here are some general JWT concerns:<p>* It&#x27;s kitchen-sink complicated and designed without a single clear use case. The track record of cryptosystems with this property is very poor. Resilient cryptosystems tend to be simple and optimized for a specific use case.<p>* It&#x27;s designed by a committee and, as far as anyone I know can tell, that committee doesn&#x27;t include any serious cryptographers. I joked about this on Twitter after the last JWT disaster, saying that JWT&#x27;s support for static-ephemeral P-curve ECDH was the cryptographic engineering equivalent of a &quot;kick me&quot; sign on the standard. You could look at JWT, see that it supported both RSA and P-curve ECDH, and immediately conclude that crypto experts hadn&#x27;t had a guiding hand in the standard.<p>* Flaws in crypto protocols aren&#x27;t exclusive to, but tend to occur mostly in, the joinery of the protocol. So crypto protocol designers are moving away from algorithm and &quot;cipher suite&quot; negotiation towards other mechanisms. Trevor Perrin&#x27;s Noise framework is a great example: rather than negotiating, it defines a family of protocols and applications can adopt one or the other without committing themselves to supporting different ones dynamically. Not only does JWT do a form of negotiation, but it actually allows implementations to negotiate NO cryptography. That&#x27;s a disqualifying own-goal.<p>* JWT&#x27;s defaults are incoherent. For instance: non-replayability, one of the most basic questions to answer about a cryptographic token, is optional. Someone downthread made a weird comparison between JWT and Nacl (weird because Nacl is a library of primitives, not a protocol) based on forward-security. But for a token, replayability is a much more urgent concern.<p>* The protocol mixes metadata and application data in two different bag-of-attributes structures and generally does its best to maximize all the concerns you&#x27;d have doing cryptography with a format as malleable as JSON. Seemingly the only reason it does that is because it&#x27;s &quot;layered&quot; on JOSE, leaving the impression that making a pretty lego diagram is more important to its designers than coming up with a simple, secure standard.<p>* It&#x27;s 2017 and the standard still includes X.509, via JWK, which also includes indirected key lookups.<p>* The standard supports, and some implementations even default to, compressed plaintext. It feels like 2012 never happened for this project.<p>For almost every use I&#x27;ve seen in the real world, JWT is drastic overkill; often it&#x27;s just an gussied-up means of expressing a trivial bearer token, the kind that could be expressed securely with virtually no risk of implementation flaws simply by hexifying 20 bytes of urandom. For the rare instances that actually benefit from public key cryptography, JWT makes a hard task even harder. I don&#x27;t believe anyone is ever better off using JWT. Avoid it.