长话短说，我开发了一个浏览器扩展程序，在其中用户可以通过第三方文件主机进行身份验证以用作后端存储（到目前为止，仅适用于Dropbox和Google云端硬盘）。我的一些用户在扩展程序调用/ tokeninfo时报告了400个错误，这时应用程序已损坏，迫使他们重新进行身份验证。现在，我终于设法始终如一地重现了问题-
如果用户在两个或多个浏览器中使用Google云端硬盘安装并验证了此扩展程序，则仅从其中一个浏览器撤消一个访问令牌会导致其所有其他访问/刷新令牌对该应用程序无效。< / strong>。 Dropbox不会发生此问题。
这表明：
1）我对Google的/ revoke端点的理解是错误的，并且撤消一个令牌将始终撤消对整个应用程序的访问权限
2）Google对OAuth的revoke方法的实现不正确，不应撤消其他令牌的访问权限
3）Dropbox对OAuth的revoke方法的实现不正确，应该撤消所有其他令牌的访问权限
我recently filed a report使用了Google的问题跟踪器之一，尽管很遗憾，这似乎是一个不活跃的社区，我尚未收到任何反馈。
一种可能的解决方法是让令牌自行失效，但是我认为这会产生误导和安全问题，因为用户可能希望在将扩展名与Google云端硬盘断开链接后立即使访问凭据失效。
任何见解将不胜感激！
答案 0 :(得分：1)
我不认为Google的实现与Oauth规范不一致。 RFC 7009-由Oauth threat model引用，专门讨论令牌撤销，并指出：
根据授权服务器的撤销策略， 撤销特定令牌可能会导致相关令牌的撤销 令牌和基础授权授予。如果特别 令牌是刷新令牌，并且授权服务器支持 撤销访问令牌，然后授权服务器 也会基于相同的授权使所有访问令牌失效 拨款（请参见实施说明）。如果令牌传递给请求 是访问令牌，服务器可以撤消各自的刷新 令牌。
这种明显的疯狂背后有一种方法。如果有人吊销令牌，则表明它已被盗用。虽然可能会认为允许合法用户撤消攻击者的令牌是一件好事，但请考虑一下相对的方面：您不希望攻击者撤消合法用户的令牌并阻止他/她重新获得访问权限到他/她的帐户。最安全的是撤销所有内容。在Oauth threat model中，当他们谈论刷新令牌轮换（Oauth中的可选功能）时，便指出了这一点：
由于授权服务器无法确定攻击者还是攻击者 合法客户端正在尝试访问，如果有这样的访问 尝试有效的刷新令牌和访问授权 与之关联的两者都被撤销。
但是，我确实同意访问令牌感觉有些极端，因为这些令牌的生存时间和范围有限。刷新令牌更加严重，需要更高的安全性。 Auth0 implements refresh token revocation like this。