Good writeup of what you should be careful with with regards to JWT. There are some inaccuracies there too. First of all, JWT doesn't support encryption at all

Good writeup of what you should be careful with with regards to JWT. There are some inaccuracies there too. First of all, JWT doesn't support encryption at all - it's JWE that does that. It's an important distinction, since most JWT libraries I ran into don't feature encryption, so if you want encrypted tokens you'll need to use an extra JWE library, or a more full-featured JOSE library. JWE also support more than just RSA - it definitely does support Elliptic Curve Cryptography (although I would prefer if they chose Curve25519 instead of the NIST curves), and they are used with EC Diffie-Helman in a certain construction that actually gives you more forward secrecy than NaCl box. NaCl Box offers you no forward secrecy, whereas all the ECDH-ES algorithms in JWE offer you partial forward secrecy, which saves you when the sender key is leaked, but not when the receiver key is leaked. That's the best you can get: we can't have a two-way perfect forward secrecy in non-interactive protocol like JWT since we can't perform a direct negotiation of ephemeral keys between sender and receiver). Of course, we're actually comparing apples to oranges here: you can get the same partial forward secrecy guarantee with libsodium's sealed box (not in the original NaCl): https://download.libsodium.org/doc/public-key_cryptography/sealed_boxes.html https://download.libsodium.org/doc/public-key_cryptography/s... As for an alternative to JWT/JWE, I think it really depends on what people want, but I have slightly different suggestions: 1. For simple access tokens in low-medium load scenarios, access tokens stored in Redis are probably simpler to implement than JWT + revocation. 2. If you don't have any secret information inside the token, HMAC-SHA256. 3. If you have secret information, I'll actually go with libsodium's XChacha20-Poly1305 AEAD: https://download.libsodium.org/doc/secret-key_cryptography/xchacha20-poly1305_construction.html https://download.libsodium.org/doc/secret-key_cryptography/x... secretbox doesn't support AEAD, but you often have external data that you want to tie the token. It's very easy to implement exactly the same construct with XSalsa20, so it will really be just secretbox with AEAD support, but that's non-standard and you won't find any native library support. 4. Public signature of public data with Ed25519 (this is NaCl's crypto_sign). 5. Authenticated asymmetrically encrypted tokens: to get partial forward secrecy, the easiest way would be using sealedbox and then signing the result with crypto_sign. It's not the most efficient way to do this, but NaCl/libsodium don't have a tailored operation for this use-case, so you would have to use primitives directly. All in all, not quite clear cut, and nobody is making a library that does that for you, so it's easy to see where JOSE is coming from.