What is the point of using a blacklist for tokens?

[rlam3]

What is the point of using a blacklist? Shouldn't this be dealt with revoking access on the user management database side?

[vimalloc]

The use case I have for it is if a refresh token for a user was stolen. That could happen with a bug in the frontend application, or perhaps a situation like an employee that was fired had an existing login to the system.

We can disable the user or change their password, but whoever has that refresh token can still freely access all of the endpoints that the user could access (except for the ones using fresh_jwt_required). At that point, the only way to stop them (well, not the only way, see bellow) would be to change the secret_key, which would invalidate their token. It would also have the side effect of invalidating every other token created by the system, in effect logging everyone out.

If the blacklist is enabled, we can go in and blacklist that single token. It will prevent them from being able to access the system any more, while not logging every other user out of the system.

This same effect could be done by checking the user rights on the database, and in many cases that may make more sense to do. That does have the side effect of checking a database for every endpoint though, which depending on the application could be expensive. By setting the access tokens to a very low expires time, and only checking the refresh token, we can avoid the db/redis/whatever lookup costs the majority of the time.

That said, this is totally an optional feature, which is disabled by default :)

[vimalloc]

Totally unrelated, most of this stuff has been loosely tested via curl, but it's been changing fast and I'm sure there are bugs or things that straight up don't work right now. I'm hoping to have unit tests up today to help with that. If you notice any bugs, etc, or have any suggestions on making the user facing api better, I would love to hear them :)

[rlam3]

@vimalloc Just a thought... If a hacker or an account was compromised. Wouldn't it be much safer to just invalidate everybody and have them log in again instead of blacklisting just one account? Assuming that hacker is going to steal accounts, they probably will be going for the whole basket full instead of targeting one... It is really rare to hear that only ONE account of an organization was compromised, usually I think there are more than a few.

[vimalloc]

Very true, and in that case I completely agree.

An example for what I'm thinking of might be a large scale email application. If they had a breach on their backend where a hacker was able to access their database or something along those lines, they should most certainly change the secret key (along with changing user passwords and all that other fun song and dance).

But I'm sure there users get attacked all the time via phishing attempts, viruses on their computer, brute forces, other companies being hacked and users sharing the same passwords across accounts, that sort of thing. Forcing everyone to re-login in when one person got compromised would be a huge pain for the end users. It would be much easier for them if we could change the password of just the compromised account, then revoke any current tokens they are using to access the application (or, as you mentioned above, forgo the token revoking and build some logic to check the user management db on all the views).

[rlam3]

Just a suggestion too. Following Flask-JWT. You should allow give user the ability to change "Bearer" Header to the JWT.

[vimalloc]

Can do!