If the blacklist app is enabled mark rotated refresh tokens as outstanding #519
Conversation
|
|
||
| OutstandingToken.objects.create( | ||
| user=user, | ||
| user_id=self[api_settings.USER_ID_CLAIM], |
There was a problem hiding this comment.
| user_id=self[api_settings.USER_ID_CLAIM], | |
| user_pk=self[api_settings.USER_ID_CLAIM], |
There was a problem hiding this comment.
The point is that TokenRefreshSerializer.validate() (the new caller for this helper) doesn't currently hold a User object. Using just the id here avoids needing to query the database for one.
Another alternative that comes to mind would be just doing RefreshToken.for_user() at refresh instead of the current RefreshToken(attrs["refresh"]) (create a new token from scratch instead of copying the claims from the previous one). That would require the query, though.
There was a problem hiding this comment.
The suggested change of user_id to user_pk doesn't pass tests, and I can't find any hint that that syntax would be supported by the Django ORM.
There was a problem hiding this comment.
However after looking at this a bit more, I don't think anything guarantees that api_settings.USER_ID_FIELD == User.id. So perhaps the query at TokenRefreshSerializer.validate() is unavoidable?
|
Just came across this because I believe I have the same issue. When a token is initially created, it is added to the OutstandingToken table. However, when that same token is refreshed, the new refresh token isn't added to the new OutstandingToken table, causing it to then be rejected when there is an attempt to use it to refresh. Is that right @vainu-arto? |
In my case refreshing tokens succeeds. At least the version of this lib I'm running doesn't require that the token exists in OutstandingToken before allowing it to be refreshed. |
…tanding The token blacklisting itself works without this (the OutstandingToken object will be created when adding a token to the blacklist), but the list of outstanding tokens would very quickly get out of date in the presence of refresh token rotation, and be unusable for any other purpose (for example being able to tell which users have valid outstanding tokens).
for more information, see https://pre-commit.ci
vainu-arto
force-pushed
the
create-outstanding-token-for-rotated-refresh-token
branch
from
a79b9de to
77ffaca
Compare
The token blacklisting itself works without this (the OutstandingToken
object will be created when adding a token to the blacklist), but the list
of outstanding tokens would very quickly get out of date in the presence of
refresh token rotation, and be unusable for any other purpose (for example
being able to tell which users have valid outstanding tokens).
Fixes #363 and #25