Hacker News Reader

Comment by Alex3917 | Hacker News Reader

> they may keep you up late on a Friday scrambling to deploy a token blacklist

Because every token has an iat datetime, you don't need a token blacklist to invalidate tokens. You just need some sort of tokens_invalid_if_issued_before_datetime setting that gets checked whenever you validate the signature of a token.

The alternative is to store a UUID for each user, and just rotate those whenever they log out, change or reset their password, or there is some sort of security event. These are then stored in the payload and used as a secret. The one advantage over just using dates is that with the former, there can be weird bugs if you have multiple servers with clocks that are out of sync.

But you shouldn't ever need to blacklist specific tokens, at least not unless you have some highly specialized use case.

View on HN

Agreed. Revoking all user sessions instead of a specific token is the common case. The only usage I see for revoking a specific token is when the user is deactivating a specific client.

Also when a user changes his password, no ?

> The alternative is to store a UUID for each user

Is that not effectively a server-side session?

> Is that not effectively a server-side session?

With most web frameworks (e.g. Django), the user model is retrieved on every request anyway. So it would be perhaps more accurate to say that it's a server-side session that's effectively not a server-side session, since no additional lookups are needed, only the user model lookup that's already done anyway.

So every user on your system has to reauthenticate if one client token is compromised? That seems like an invitation to a thundering herd. Not necessarily fatal, but I'd consider it a nice feature to not have to invalidate everybody's tokens to get at one.

> So every user on your system has to reauthenticate if one client token is compromised?

No, because you would also store either a separate datetime or uuid on each user model. And if just one user has their credentials compromised, then you would bump the date or generate a new UUID for just that user.

The global datetime would only be bumped if some site wide vulnerability were found.

Got it, didn't catch that you were referring to storing that timestamp per-user.

That's what I do in my system.

So there is a db roundtrip involved? Like a inverted session. Whats the point of using jwt then?

For most web frameworks, the user model gets retrieved from the db automatically whenever an authenticated request is made. So there is no extra lookup.

Oh man.

Proponents say critics dont offer alternatives at the same time they always literally 'reverse' engineered sessions if you dig deep enough.

I give up. JWT is just a hip thing to do right now. :(

Reply on news.ycombinator.com