I find it hard to recommend JWT unless you're already a security expert.
This is unfortunate, since JWT was meant to bring client-side tokens to the masses, but the reality is that:
1. JWT has amazing cross-language support, but most of the libraries out there are unaudited, and even the ones that are audited can change and, let's say, make the 'None' signer the default one:
https://github.com/lcobucci/jwt/commit/6507ac39be5a5e06457c8...
2. JWT can be used somewhat responsibly, but the JWT spec does n't enforce any security measure and doesn't even contain proper recommendations like:
a. Never use the None algorithm.
b. Never use the RSA algorithm.
c. Basically, only use HMAC (or Ed25519 if supported).
d. Always include an issue timestamp ('iat' claim) and possibly a unique nonce ('tid') to make tokens unique.
e. Always do key rotation using 'kid'.
f. Implement a blacklist-based token revocation mechanism (or use short-lived access tokens backed by DB-based refresh tokens).
g. Include the token expiry claim! Seriously, JWT doesn't even require token expiry!
h. Don't use JWE.
h. Associate your keys with signature algorithms, and _make sure that token is signed with the right alorithm_:
https://auth0.com/blog/critical-vulnerabilities-in-json-web-...
3. I'm yet to encounter a library which enforces good defaults on your JWT usage. Some libraries validate expiry by default (if the claim exists), but from my experience most of them don't set it by default. Almost no library contains an convenience method for setting the issue time or a nonce, let alone setting them by default.
4. No JWT library I know of provides help for implementing basic features like key rotation/revocation and token revocation. Without these features JWT security model becomes vastly inferior to database-backed tokens.
The reality is that developers implementing JWT choose it exactly because they don't want to delve into all these complications of using tokens, so they just pick up a library and hack something around it, expecting the JWT library to take care of all the security issues for them.
1. JWT has amazing cross-language support, but most of the libraries out there are unaudited, and even the ones that are audited can change and, let's say, make the 'None' signer the default one: https://github.com/lcobucci/jwt/commit/6507ac39be5a5e06457c8...
2. JWT can be used somewhat responsibly, but the JWT spec does n't enforce any security measure and doesn't even contain proper recommendations like:
a. Never use the None algorithm. b. Never use the RSA algorithm. c. Basically, only use HMAC (or Ed25519 if supported). d. Always include an issue timestamp ('iat' claim) and possibly a unique nonce ('tid') to make tokens unique. e. Always do key rotation using 'kid'. f. Implement a blacklist-based token revocation mechanism (or use short-lived access tokens backed by DB-based refresh tokens). g. Include the token expiry claim! Seriously, JWT doesn't even require token expiry! h. Don't use JWE. h. Associate your keys with signature algorithms, and _make sure that token is signed with the right alorithm_: https://auth0.com/blog/critical-vulnerabilities-in-json-web-...
3. I'm yet to encounter a library which enforces good defaults on your JWT usage. Some libraries validate expiry by default (if the claim exists), but from my experience most of them don't set it by default. Almost no library contains an convenience method for setting the issue time or a nonce, let alone setting them by default.
4. No JWT library I know of provides help for implementing basic features like key rotation/revocation and token revocation. Without these features JWT security model becomes vastly inferior to database-backed tokens.
The reality is that developers implementing JWT choose it exactly because they don't want to delve into all these complications of using tokens, so they just pick up a library and hack something around it, expecting the JWT library to take care of all the security issues for them.