Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Blacklist Based on User ID #300

Closed
chenkie opened this issue Oct 23, 2015 · 2 comments
Closed

Blacklist Based on User ID #300

chenkie opened this issue Oct 23, 2015 · 2 comments

Comments

@chenkie
Copy link

chenkie commented Oct 23, 2015

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.

@tdhsmith
Copy link
Contributor

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.

@chenkie
Copy link
Author

chenkie commented Oct 25, 2015

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants