Why Outstanding token exist and why it stores raw refresh token

[akhushnazarov]

Cant we just use one blacklist table to do the job?
Also why are we storing refresh token if we just use jti claim to lookup the blacklist?

[stelebrun]

Hello, any update on this issue ? @akhushnazarov maybe?
Why don't you hash the refresh tokens ?

[sshishov]

I have more general question, why not to store everything in 1 table. blacklisted_at would be None if token is active and have a timestamp if it is blacklisted. Much easier, no?

[Andrew-Chen-Wang]

Cant we just use one blacklist table to do the job?

Yes

Also why are we storing refresh token if we just use jti claim to lookup the blacklist?

Easier for observability lookups. Without it, you'd have to manually grab the jti claim.

I also think it has to do with the sliding token model. Though the token is changing due to a sliding expiration, the jti remains the same I believe

Why don't you hash the refresh tokens ?

I'm not sure there is a reason to hash it. If your database is leaked, sure refresh tokens are stolen, but that's precisely why you have a blacklist app. Session tokens in the default django app aren't hashed either, probably due to the short duration of a session.

I have more general question, why not to store everything in 1 table. blacklisted_at would be None if token is active and have a timestamp if it is blacklisted. Much easier, no?

I agree, this would make for a better design. I suspect the original intention was from the viewpoint that blacklisting tokens would be done from the Django admin view.

Currently, jti isn't even being indexed, and our token blacklist lookup utilizes the underlying OutstandingToken table to look up the un-indexed jti column. I'm open to PRs; this doesn't seem like a hard migration, just a major version upgrade again.

[adamJLev]

Ideally this should be configurable, but I think most people would rather only store the jti identifier and not the full raw token, for security and also for db space consumption reasons. I would even argue that the default should be to err on the side security on this.