[komerdoor]

I am using JWT for my projects to keep stateless sessions between servers and for some other tokens (refresh, register, reset pass etc.). Of course extra security measures are required (MitM protection [HTTPS etc.], XSS / CSFR prevention etc.), but this has nothing to do with JWT. I use encryption with a frequently rotated private key to encrypt the part of the payload that only the server may read.

A good read at: https://stormpath.com/blog/where-to-store-your-jwts-cookies-...

[unscaled]

The problems with JWT are not related to MITM, XSS or CSRF vulnerabilities. You'll have to address these issues regardless of the type of token you're using.

The problems with JWT can be divided into two classes: 1. Too many options, making it easy to misuse. Even if you disallow the 'none' algorithm (like most newer JWT libraries), there are still many other ways to break it. e.g.: https://auth0.com/blog/critical-vulnerabilities-in-json-web-...

2. Misguided cipher choice. AES-GCM (easy target for nonce-reuse), RSA, NIST P-curves.

So in short, even if you're using encryption, JWT just makes it easy for the crypto itself to fail.

[komerdoor]

I agree. Thank you for pointing that out. That is why I restricted my JWT code to only accept / use certain options. Of course I could still have chosen the wrong cipher for my specific use case and am aware that JWT will not solve this for me.

What JWT is doing is actually not that special as it is just a standardized container (akin to MKV and supported codecs) inside which existing technologies can be used. Easy to write something similar if you know what you are doing. I did that before, but still missed some extra verifications already build into JWT.

Of course, the chosen technologies allowed to be used inside a JWT can still be prone to vulnerabilities. I am not sure if that can be blamed on JWT. People should still think about which options to use.