You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Right now there appears to be two possible behaviors when a refresh token is refreshed.
If the previous_refresh_token column exists then the refresh token / access token are both revoked when the TokenInfoController::show action is requested for the first time.
It would help if the comment describing this behavior were more specific about what "used" means.
If it does not exist both the refresh and access token are revoked immediately.
Desired behavior
I was wondering why we revoke both the refresh and access token at the same time when revoked immediately. I would have expected that the refresh token would be revoked, but that the old access token would remain valid until it expired. I had assumed I missed something in the RFC about this but could not find anything. I would try and hack this in, but since refresh tokens and access tokens use the same model + column for revocation it was not straight forward.
The text was updated successfully, but these errors were encountered:
@ransombriggs did you develop a workaround for this? I am also trying to enable an access token to be refreshed without revoking the previous access token
@jessieay Not exactly, we have a custom revocation process which excludes this case and allows for access tokens to remain functional after being refreshed, even though if you introspect them we will report that they are not. A real fix for this would require a database change to oauth_access_tokens to store that the refresh token has been revoked and creating a way to differentiate if you are thinking about an oauth_access_tokens from the perspective of access or refresh. I had to do a half baked strategy like this for another fix which was awkward but could be turned into a fully baked solution.
Technically it would probably require two columns, one for the revocation and one to toggle on before / after upgrade behavior to avoid a back fill of data from before the change since we do not know if the access or refresh token was revoked before the upgrade and would want to preserve current behavior until they are cleaned up.
Steps to reproduce
Right now there appears to be two possible behaviors when a refresh token is refreshed.
previous_refresh_token
column exists then the refresh token / access token are both revoked when theTokenInfoController::show
action is requested for the first time.Desired behavior
I was wondering why we revoke both the refresh and access token at the same time when revoked immediately. I would have expected that the refresh token would be revoked, but that the old access token would remain valid until it expired. I had assumed I missed something in the RFC about this but could not find anything. I would try and hack this in, but since refresh tokens and access tokens use the same model + column for revocation it was not straight forward.
The text was updated successfully, but these errors were encountered: