Refresh token should be revoked on password change if CHECK_REVOKE_TOKEN is used

[sshishov]

We are using the setting CHECK_REVOKE_TOKEN: True but if the user changes the password, the refresh token is not revoked, not blacklisted or anyhow even checked. I can continue refreshing my token again and again without any issues.

At the same time the hash is checked inside get_user of JWTAuthentication and producing 401 error with some code.

How all applications works:

1. login (get access and refresh tokens)
2. make api with access token, if HTTP 401 returned - refresh token
3. if refreshing token is failed with HTTP 401 - redirect to login + remove tokens

This is the basic flow without "special" handling of different codes.

But now this flow is broken as point 2 returns 401 (password changed) and we try to refresh token, token refreshed with HTTP 200, we trying api call and again having HTTP 401 (password changed) and going to infinite loop.

Instead we should check for the password hash on token refresh and raise HTTP 401 from there (additionally blacklisting this refresh token if blacklist is active)

What do you think guys? Does it make sense?

[mahdirahimi1999]

Thanks for the detailed report, @sshishov.

You are absolutely right. Your analysis of the token refresh flow is spot on. The current implementation doesn't check the password hash during refresh, which leads to the infinite loop you've described. This is definitely a bug and a gap in the intended functionality of the CHECK_REVOKE_TOKEN setting.

I've opened a pull request to address this. It implements the password hash check within the TokenRefreshSerializer, ensuring that refresh tokens are properly invalidated after a password change.

The fix is available for review here: #928