Jwt-auth: Blacklist Based on User ID

Created on 24 Oct 2015  路  2Comments  路  Source: tymondesigns/jwt-auth

Is there a way to blacklist any JWTs that have been issued to a user, based only on that user's ID? Looking to put in a kind of "log out on all devices" feature for admins.

Most helpful comment

With the default set-up, no. The server maintains no record of what JWTs have been issued or not. This is a big part of the "statelessness" of JWT authentication systems, because it allows multiple services to use the same tokens without having to communicate or keep track of sessions or users. Since the blacklist runs on a per-token basis, it wouldn't be possible to add entries without knowing which tokens exist.

Check out the discussion here about tracking user tokens (and more at #282, #258, #97...).

If this is truly necessary, you could store every JWT in the database and whenever you need to log out a user, find all of their tokens and call invalidate() on each of them. (This is mentioned in the posts I linked.)

Alternatively, if you expect to only ever log out _all_ of a users tokens, you could have something like an earliest_valid field for each user. Whenever you check/authenticate a token, you'd compared its iat ("issued at") claim with the earliest_valid value, and reject the token if it was issued before that. Then when you need to log a user out, update its earliest_valid to the current moment.

I'm not a security expert though, so don't take these suggestions as professionally vetted. Also both of them start to undermine the statelessness of JWTs, so if you're working with keeping multiple systems in sync or keeping auth persistent after storage failures, it's going to make things a lot harder for you.

All 2 comments

With the default set-up, no. The server maintains no record of what JWTs have been issued or not. This is a big part of the "statelessness" of JWT authentication systems, because it allows multiple services to use the same tokens without having to communicate or keep track of sessions or users. Since the blacklist runs on a per-token basis, it wouldn't be possible to add entries without knowing which tokens exist.

Check out the discussion here about tracking user tokens (and more at #282, #258, #97...).

If this is truly necessary, you could store every JWT in the database and whenever you need to log out a user, find all of their tokens and call invalidate() on each of them. (This is mentioned in the posts I linked.)

Alternatively, if you expect to only ever log out _all_ of a users tokens, you could have something like an earliest_valid field for each user. Whenever you check/authenticate a token, you'd compared its iat ("issued at") claim with the earliest_valid value, and reject the token if it was issued before that. Then when you need to log a user out, update its earliest_valid to the current moment.

I'm not a security expert though, so don't take these suggestions as professionally vetted. Also both of them start to undermine the statelessness of JWTs, so if you're working with keeping multiple systems in sync or keeping auth persistent after storage failures, it's going to make things a lot harder for you.

Thanks! I was quite certain there wasn't any default tracking of JWTs, but good to have it confirmed. I'll check out the discussions you linked.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

aofdev picture aofdev  路  3Comments

harveyslash picture harveyslash  路  3Comments

agneshoving picture agneshoving  路  3Comments

shah-newaz picture shah-newaz  路  3Comments

johncloud200 picture johncloud200  路  3Comments