4 ms·
I have happily used JWTs as signed objects that can be easily parsed and validated by any API consumer, in any language, using library code. These objects can
by quesera 4y ago
I have happily used JWTs as signed objects that can be easily parsed and validated by any API consumer, in any language, using library code.
These objects can be transferred through untrusted channels, and retain their verifiability. That can be useful when moving data between organizations, or systems that do not talk directly (e.g. a mobile app that interacts with multiple unrelated backends).
RFC 7519 says:
JSON Web Token (JWT) is a compact, URL-safe means of representing
claims to be transferred between two parties.
Not all claims are authorization claims. Not all claims require ad hoc invalidation. Some claims can even be permanent!
Authors ad infinitum have pointed out the risks in using JWTs for authorization (linked web article says "authentication", but both could apply).
Those risks are:
- Invalidation/expiration controls are limited
- Receiver might not properly validate signature
- Protocol dumbly allows "none" algorithm
Only the first is an operational concern, the others are just "bad code works badly" problems.
The moral of the story is: If your claims do not fit the timed-expiration model of JWTs (e.g. some authorization claims), then don't use JWTs!
- marcosdumay 4y ago> the others are just "bad code works badly" problems Software should be hard to misuse. If you have a library intended for universal usage, and the library users have to remember to add some code every time they call it, then it's a bad library. If you have an specification intended for universal usage, and the implementers have to remember to always do 3 operations together, than it's a bad specification.
- kreetx 4y agoRight, but rm -fr / is also easy to write, but is pretty bad code. JWTs and statelessness have their uses, building in refreshing is not that difficult (if it's not built in already), and using "none" well, just don't use that.
- marcosdumay 4y agoThere are alternatives that won't accept "none" or broken encryption algorithms, and that won't allow you to access the token data without verifying its authenticity. JWT is just a bad standard all around.
- 0x457 4y agoMany issues of JWT are actually issues on library for nodejs to work with JWTs and partially the language: trick server to use public key as secret to validate JWT, trick server to use none. JWT itself is also poor by having things like "none" at all. Which means in every valid place to use JWT, you should really be using PASETO.
- ragona 4y agoYou're missing the core challenge of JWTs, which is revocation. If you just check the signature then users can't log out.
- quesera 4y agoRevocation == invalidation. User-initiated log out is easy, you just clear the token. Promiscuous token gathering is harder (but SSL..!) and makes the case for invalidation or short expiration periods. And forced logout is the legit operational problem case. Again though. If JWT does not fit your authnz model, don't use it. JWT works well in many applications outside of authnz, and some inside it as well.