revokeCredentials returns an error for invalid token

[adriano-di-giovanni]

As per the docs

This library comes with an OAuth2 client that allows you to retrieve an access token and refreshes the token and retry the request seamlessly if you also provide an expiry_date and the token is expired.

Unlike all other requests, the library doesn't refresh the token for revokeCredentials. It also doesn't retry the request.

[tmatsuo]

I have a question. I think revokeCredentials is for revoking the credentials. If the token is expired, is there a need to refresh the token and then retry? Can you just throw away the token and the credentials from the memory?

[adriano-di-giovanni]

AFAIK, revokeCredentials also removes third-party access. It’s something that doesn’t happen automatically when the access token expires

Inviato da iPhone

Il giorno 19 mag 2021, alle ore 18:38, Takashi Matsuo @.***> ha scritto:

 I have a question. I think revokeCredentials is for revoking the credentials. If the token is expired, is there a need to refresh the token and then retry? Can you just throw away the token and the credentials from the memory?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[JustinBeckwith]

Thanks for the issue! Under the hood, we are simply calling this endpoint: https://developers.google.com/identity/protocols/oauth2/web-server#tokenrevoke

Looking at the docs, the following is called out:

The token can be an access token or a refresh token. If the token is an access token and it has a corresponding refresh token, the refresh token will also be revoked.

If the revocation is successfully processed, then the HTTP status code of the response is 200. For error conditions, an HTTP status code 400 is returned along with an error code.

If I pass a nonsense access token to that endpoint, it throws a 400 on me. Thinking out loud here - today we always pass the access_token when we attempt to revoke the token. The only cases where we could refresh that access_token are cases where we also have the refresh_token available. What we could do here is:

• Attempt to revoke the access token. If that succeeds, it revokes the refresh token as well and we're done.
• If revoking the access token fails, and we have a refresh token available, we could just attempt to revoke that

@adriano-di-giovanni would that get you where you want to go? @bshaffer and @bcoe interested in your thoughts here as well.

[bshaffer]

I believe the assumption here is that an expired access token will result in an error for invalid token when attempting to revoke it, and so not revoke the underlying refresh token?

I do not believe this is how the revoke endpoint functions, but if we can confirm that it is, then @JustinBeckwith's solution seems like the right way to handle it.

[adriano-di-giovanni]

@JustinBeckwith, I think that your solution is much more efficient than refreshing the access token before revoking the credentials.

If we were sure that revoking a refresh token implicitly revokes the access token, we could revoke the refresh token first if it exists. Otherwise, we could initiate the workflow that @JustinBeckwith proposes. The workflow should return the invalid_token error if the refresh token doesn't exist.