Question: Is keeping the entire tokens in blacklist app considered safe?

[bj00rn]

A question on security. Whats the motivation for keeping entire tokens in the blacklist apps outstanding/blacklisted token tables?

Wouldn't just keeping track of token jti's be enough?

If the database is somehow leaked an attacker would be able to use the outstanding tokens. If tokens are long-lived this could potentially be an even greater problem.

Or am I missing something?

Thanks for making great software!

[brhelwig]

My $0.02 worth is this.

If you are practicing defense in depth, storing the token is not great. Its one potential avenue for them being exposed by a direct DB breach. I would also like to see it dropped as I'm not sure what the use case is for the blacklist app.

The other would be for your signing key to be compromised which would allow you to generated new tokens anyway.

In either case you would want to be rotating out your key, but yeah I agree..token should be dropped.

[Andrew-Chen-Wang]

Sorry for late response; busy with school. TL;DR You should only need the blacklist app if you're using an SPA with logout functionality, non-secure HTTP, and not using httpOnly flag. If you've got an SPA but the index.html file is delivered by Django, then use session authorization with the httpOnly flag. Anyways:

I believe the point of the blacklist is to deny refresh tokens before their actual expiration point. For example, Microsoft's refresh tokens for authentication is 90 days, but they need to log users out since they use an SPA. That "logout" functionality is what's being stored in the blacklist (if I'm not wrong regarding the blacklist app; it's been awhile); though, I'd like to see the blacklist app be a part of a cache rather than DB for automatic expiration of these refresh tokens. The original purpose of the blacklist app wasn't my idea, and I'm also a bit lazy to go through the commit logs of the blacklist app rn.

If you are practicing defense in depth, storing the token is not great. Its one potential avenue for them being exposed by a direct DB breach.

It's the same conclusion with stateful authorization. Even stateless authorization have the same weakness as stateless: the assumption is that there is no breach in the first place. If your server is breached, signing key (stateless) is lost and forgery can happen or your session key (stateful) is lost and that can be forged. If you've got a DB breach, you've got bigger issues than people stealing credentials like updating rows without server-side validation.

Extra notes:

I personally don't use the blacklist app. It's a waste of resources. I personally use SimpleJWT for development with an SPA, but not the blacklist app since I obviously trust myself as the developer. But on deployment of the SPA, I'd deliver the HTML file from Django. If you're developing mobile, you can just send the token to the device via HTTPS (all platforms require HTTPS to be on their app/play store) and store it in their secret storage/keychain.

The security vulnerability is mostly with the browser.