Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

There is no way to refresh an access token without revoking the previous access token #1730

Open
ransombriggs opened this issue Sep 10, 2024 · 3 comments

Comments

@ransombriggs
Copy link
Contributor

Steps to reproduce

Right now there appears to be two possible behaviors when a refresh token is refreshed.

  1. 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.
  2. 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.

@jessieay
Copy link

@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

@ransombriggs
Copy link
Contributor Author

@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.

@ransombriggs
Copy link
Contributor Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants