This is a feature I should have implemented long ago, but I haven't because I use short lived tokens (expired in an hour, with refresh tokens).

Blacklisting consists of explicitly store a valid, not expired token in some database or cache until the token is expired, and then can be removed from the database/cache.

The bad thing about this is the lookup times on every request, for small systems you would not even notice any difference

but on large systems, it may cause the whole thing to be slow.

So things to consider on a solution for this:

1) Do not blacklist tokens, but use a timestamp check on each user.

This would imply the user record has a forced_logout or similar column, with the timestamp where the user blacklisted any token issued before that date.
This solves the session hijacking problem, meaning if the users clicks logout, the time is stored and if a token is used, but issued before the logout, it means expired.

Pros: Simple, and the user record is most likely already being pulled from database, so no overhead other than simple integer unix timestamp comparison.

Cons: It does not allow for single token blacklisting, meaning if you blacklist an user session it will kill it's sessions on every device.

2) Use short life tokens, and refresh then often, but not always.

This means every time the token expires, the frontend will use the refresh token to issue a new one.
The blacklist will then be done on the refresh token used, that will be rendered invalid.

This is for for me, but may complicate frontend implementations.

This also covers the case on always refresh tokens, meaning each request will exchange a token by a new one. This is a bad idea on every angle I see, and I think it's trivial to deduce that, but I can talk more about it if requested.

3) do the actual blacklisting.

The actual blacklisting would imply doing cached token blacklisting.
The main problem here is lookup times and flushing expired blacklisted tokens.
The way to flush is to cronjob it, since doing it every N requests would result in a poor end-user experience periodically.

Now, please @Reached @jonagoldman @emtudo @grantholle please make your case about blacklisting, because I can't see a very good reason to make this an urgent matter.

For those on the ultimate need of this, please, just store a custom field on the database for a session identifier, and allow this identifier on the token itself as a custom claim.

After a logout, change that value and old tokens will be invalid because the session id does not match, and forging the jwt token will result in a invalid signature.

The most urgent thing I think on this right now is asymmetric encryption support. But I can give more thought on it if needed.

How to logout/blacklist #39

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions