When you use the token_blacklist app to revoke tokens, the app stores the full refresh tokens in plain text in the DB. Which seems like a security risk if a DB gets leaked. Even a django Admin can impersonate a user by simply copying their token.
I'm not sure why this is needed, can't we use jti claim to revoke generated tokens? this would require us to decode the token before verifying it to look up the JTI_CLAIM in the BlacklistedToken Model objects. but it'd be safer. Similar to how django-rest-knox stores hashed tokens to protect against DB leaks.
I'm new to the library but I can attempt to draft a PR if the idea itself is approved.
It is not only stored in the database but also displayed in admin panel. I'm happy to make a PR if maintainers approve the idea of removing the field or at least not displaying it in the admin panel.
When you use the
token_blacklist
app to revoke tokens, the app stores the full refresh tokens in plain text in the DB. Which seems like a security risk if a DB gets leaked. Even a django Admin can impersonate a user by simply copying their token.I'm not sure why this is needed, can't we use
jti
claim to revoke generated tokens? this would require us to decode the token before verifying it to look up theJTI_CLAIM
in theBlacklistedToken
Model objects. but it'd be safer. Similar to howdjango-rest-knox
stores hashed tokens to protect against DB leaks.I'm new to the library but I can attempt to draft a PR if the idea itself is approved.
Thanks.