Using Google's OAuth 2.0 revoke endpoint invalidates all other tokens for user

Question

So long story short, I developed a browser extension in which the user authenticates with third-party file hosts to use as backend storage (Currently just Dropbox and Google Drive so far). Some of my users are reporting 400 errors when the extension calls /tokeninfo, at which point the application is broken forcing them to re-authenticate. Now I've finally managed to consistently reproduce the problem-

If the user installs and authenticates this extension with Google Drive in two or more browsers, revoking a single access token from just one of the browsers causes all of their other access/refresh tokens become invalidated for the app.. This issue does not occur for Dropbox.

This suggests that either:

1) My understanding of Google's /revoke endpoint is wrong and revoking one token will always revoke access to the entire app

2) Google's implementation of OAuth's revoke method is incorrect and should not revoke access from additional tokens

3) Dropbox's implementation of OAuth's revoke method is incorrect and should be revoking access from all additional tokens

I recently filed a report on one of Google's issue trackers, though unfortunately it seems to be an inactive community and I have yet to receive any feedback.

One potential workaround may be to let tokens expire on their own, but I think this would be misleading and a security concern, as users are likely expecting access credentials to be immediately invalidated when unlinking the extension from Google Drive.

Any insights would be greatly appreciated!

Answer 1

I do not believe Google's implementation is inconsistent with the Oauth spec. RFC 7009 -- which is cited by the Oauth threat model specifically talks about token revocation, and states:

Depending on the authorization server's revocation policy, the revocation of a particular token may cause the revocation of related tokens and the underlying authorization grant. If the particular token is a refresh token and the authorization server supports the revocation of access tokens, then the authorization server SHOULD also invalidate all access tokens based on the same authorization grant (see Implementation Note). If the token passed to the request is an access token, the server MAY revoke the respective refresh token as well.

There is method behind this apparent madness. If somebody is revoking a token, that suggests that it has been compromised. While one may think it is good to allow the legitimate user to revoke the token of an attacker, think of the counter-side: you wouldn't want the attacker revoking the token of the legitimate user, and preventing him/her from regaining access to his/her account. The safest thing is to revoke everything. This exact point is made in the Oauth threat model when they talk about refresh token rotation (optional feature in Oauth):

Since the authorization server cannot determine whether the attacker or the legitimate client is trying to access, in case of such an access attempt the valid refresh token and the access authorization associated with it are both revoked.

However, I do agree that it feels a bit extreme for an access token since those tokens have limited life times and limited scopes. Refresh tokens are more serious and need higher security. Auth0 implements refresh token revocation like this.