How to logout/blacklist

[grantholle]

I can call $guard->logout() successfully, but then I can use that same token for the user I just logged out to call authenticated routes afterwards.

Looking at the function, it doesn't look like it's doing anything. Has this been implemented yet?

[emtudo]

Needs an implementation.

[jonagoldman]

I asked the same question about a year ago, this was the response: #7 (comment)

[Reached]

Any news on this? :)

[hernandev]

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.

[jonagoldman]

I think options 1 and 2 will cover most application needs.

Option 1 behaves like a regular logout, so is good enough for most apps and the app I'm currently working on. Its also the simplest, and that's a good think.

Option 2 downside is that it does not allow you to force a logout immediately, so if the user is doing damage to your application you will need to wait until the token expires. Also the front-end implementation is more complicated than it sounds, you can get into some problems in some edge cases.

Option 3 is an "advanced feature" only needed in advanced applications and affects performance for everyone else. Most apps don't need specific token blacklisting.

Regarding asymmetric encryption support, I don't know what that means :)