> JWTs (...) can’t be revoked easily and may expose sensitive data if not encrypted.
This is not true.
Revoking a JWT is as simple as adding the JWT ID to a list of revoked JWTs. If a JWT is valid and its JWT ID is in the revoked list, the JWT is refoked. The tradeoff is that resource servers need to periodically refresh this list.
Also, a JWT only leaks sensitive data if you purposely want the JWT to ship sensitive data. Nothing forces you to do that.
> Opaque tokens (...) offer better security and revocation control but come with extra overhead and reduced scalability.
This is simply wrong. Any security and revocation check you can do with a opaque token, you can do with a JWT as well.
Overall the quality of the article is quite poor.
now you need to synchronize a list of sessions everywhere..which is exactly what we were using JWT to avoid...
No. You just maintain a single deny list.
> which is exactly what we were using JWT to avoid...
JWTs were designed to allow servicss to do stateless checks. Originally this meant clients getting single-use bearer tokens, or worst case scenario short-lived tokens. Revocation lists are only relevant if JWTs are explicitly used in a way that goes against their design goals of being short-lived.
Nevertheless, you are also wrong: JWT denylists have absolutely nothing to do with sessions. The are a list of what JWTs should be rejected by resource servers. A client can and does handle many JWTs throughout their session, whereas resource servers only need to periodically refresh that list and check if a JWT ID is in it or not. This does not make JWTs more or less stateless.
TFA says a JWT _may_ expose sensitive data. Which is, as you yourself confirm, true.
Not really. The complain about JWTs leaking sensitive data reads like the bike fall meme. It's like complaining that REST APIs expose sensitive data if not encrypted. Well, that's not a REST trait or something caused by REST, is it? It's you who somehow decided to leak sensitive data through an interface. That's hardly the technology's fault.
No. Revocation is typically implemented as a shortcut to token expiration. Token expiration involves a grace period. The goal is to arbitrarily reject a long-lived token before it's expiration.
> (...) like if a service is dealing with very sensitive data.
No. That's why single-user tokens are used.