I would have expected a more in-depth analysis of JWT compared to other techniques. As much as I appreciate the effort to warn people away from bad security pra

I would have expected a more in-depth analysis of JWT compared to other techniques. As much as I appreciate the effort to warn people away from bad security practices, JWT is not as a technique fundementally broken. > JSON Web Signatures Makes Forgery Trivial > 1. Send a header that specifies the "none" algorithm be used Most JWT libraries require you to explicitly allow the none algorithm. I had to set a very explicit system property to even get the library I am using to accept none! Even so, anyone implementing JWT should make sure that only the algorithms actually used are accepted. > 2. Send a header that specifies the "HS256" algorithm when the application normally signs messages with an RSA public key. Being able to use the public RSA key used to sign an RS256 JWT as the key for a (forged) HS256 token requires the server to accept both RS256 and HS256, and (critically) to be able to use a key configured for RSA assymetric signing to validate HMAC SHA256 signatures. I have not been able to reproduce this latter bug with the library I am using, but even if it did, I still check the algorithm field beforehand: if a token claims it is HS256 signed, I use the (private) key configured for that (if HMAC SHA256 signing is allowed in my application); if it is RS256 signed, I use the (public) key configured for that. The library I use doesn't even get a choice in this; it either receives a JWT that claims to be RS256 together with a RSA 2048 public key, or it gets a JWT that claims to be HS256 together with a private signing key exlcusively used for HS256. The code preforming those checks between the REST-call receiving the JWT and the JWT library is trivial. This is all assuming that you would place a service configured to accept both HS256 and RS256 tokens at the same time in production. As with any security standard: don't use crap libraries; do your research; test your service for common vulnarabilities; follow recommendations made by experts; and don't deploy techniques you don't quite grasp in production software. > JSON Web Encryption is a Foot-Gun So is TLS, or hashing passwords. Security is hard and requires a lot of reading and grokking (but it is not too hard for any moderately experienced software engineer). > TL;DR Really? 'Too long; didn't read' for a handful of paragraphs? I'll grant the author this much; anyone who can't muster the attention span to read that much text without groping around for a single sentence summary shouldn't be implementing (any!) security standards. JSON Web Token is a well-documented accessible security standard with a lot of comprehensive information available. As with any technique, there are caveats, but these caveats do not discredit the technique as a whole.