The author presents some ideas for uses here, but TBH I still don't see how these uses are better than tracking these actions via a database too.
If you issue a "reset" token embedded in an emailed link, when it's consumed the stored token can be invalidated/deleted, enforcing that the token really is single-use.
A JWT used for this still opens up the same problems as with auth: it's open to re-use, and can't be invalidated. Yes it can have a much shorter TTL, but there's still potential for it to be abused.
The only real valid use I see from the article, is to replace presigned URLs, simply because it could be a standardised thing in CDNs, rather than the completely random implementations that are used now.
A place where I contracted used them to solve timing issues with the database.
Actions would be written to a database and a web page sent to the user, then the user would click something and a request would reach a web server, occasionally arriving before that server's database shard had seen the database write.
JWT passed the information via the user's browser, eliminating the race.
That's certainly not a use case I'd have ever imagined. With that scenario I'd have thought sessions (essentially binding a user to the same backend for a period of time) in the load balancer(s) would be a simpler solution, but that's just me.
Arguably that was done, if I remember the architecture well… the company had a rule against SPoFs, so there were ① several load balancers at different sites, with ② several clusters of servers behind them, and ③ several backends supplying data to the servers.
I think the JWT usage was in 2, but moving it to 1 would have presented the same problem, because in that case the mapping from user to backend would have to be coordinated for geographically dispersed load balancers, with the same timing constraints.
It would also be possible to use various techniques that add a delay to the user, such as avoiding anycast and having the client occasionally slow down while searching for a usable cluster.
The last time I ran into a similar thing I solved this race condition by not erroring out on an invalid lookup until a reasonable number of seconds to allow the backend to catch up.
If you issue a "reset" token embedded in an emailed link, when it's consumed the stored token can be invalidated/deleted, enforcing that the token really is single-use.
A JWT used for this still opens up the same problems as with auth: it's open to re-use, and can't be invalidated. Yes it can have a much shorter TTL, but there's still potential for it to be abused.
The only real valid use I see from the article, is to replace presigned URLs, simply because it could be a standardised thing in CDNs, rather than the completely random implementations that are used now.