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.
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.
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_validfield for each user. Whenever you check/authenticate a token, you'd compared itsiat("issued at") claim with theearliest_validvalue, and reject the token if it was issued before that. Then when you need to log a user out, update itsearliest_validto 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.