Comment by quesera | Hacker News Reader

Comment by quesera | Hacker News Reader

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!

> 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.

Right, 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.

There 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.

Many 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.

You're missing the core challenge of JWTs, which is revocation. If you just check the signature then users can't log out.

Revocation == 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.

Reply on news.ycombinator.com