A Guide to Bearer Tokens: JWT vs. Opaque Tokens | Hacker News Reader

A Guide to Bearer Tokens: JWT vs. Opaque Tokens

permit.io

19 pointsbubblehack3r9 comments

From the article:

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

> Also, a JWT only leaks sensitive data if you purposely want the JWT to ship sensitive data. Nothing forces you to do that.

TFA says a JWT _may_ expose sensitive data. Which is, as you yourself confirm, true.

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

by that logic cookies could leak sensitive data too

>adding the JWT ID to a list of revoked JWTs

now you need to synchronize a list of sessions everywhere..which is exactly what we were using JWT to avoid...

> now you need to synchronize a list of sessions everywhere..

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.

If there is a deny list, and you have multiple services, you either do need to sync it or have a service fully responsible for this, and this does come with the burden of dealing with consistency guarantees, so it’s not as simple as “periodically refreshing the list” especially if the need is high for accurate revocation information, like if a service is dealing with very sensitive data. Handling the list is arguably a bit easier than dealing with a bespoke session, since it’s less data to handle and can be scaled more easily, but I think it’s disingenuous to argue that you “just need to maintain a single deny list”.

Revocation checking could be moved to the proxy level.

> If there is a deny list, and you have multiple services, you either do need to sync it or have a service fully responsible for this, and this does come with the burden of dealing with consistency guarantees (...)

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.

Reply on news.ycombinator.com