Google OAuth令牌验证的执行方式和原因是什么？

Question

在访问令牌，刷新令牌，范围，受众和客户ID之间，当Google OAuth文档指示我validate all tokens以防止混淆的代理问题时，我感到很困惑。 The Wikipedia article linked to仅描述高级别的一般问题，而不是特定于OAuth甚至网络身份验证。如果我理解正确，令牌验证甚至不是OAuth2的一部分，但实际上取决于具体的实现。所以这是我的问题：

Google OAuth令牌验证的执行方式和原因是什么？

在这种情况下，混淆的代理问题的具体例子将特别受到赞赏。另请注意，我在完全客户端应用程序的上下文中询问这一点，如果这有所不同。

Answer 1

Google专指 access 令牌。

在OAuth 2.0的上下文中，当用于身份验证时，混淆的代理问题适用于Implicit Grant protocol flow。谷歌称之为客户端应用程序的＃OA; OAuth 2.0＆＃34;基于隐式授权协议流程。

由于隐式流通过URI片段向最终用户公开访问令牌，因此它引入了访问令牌可能被篡改的可能性。合法的应用程序（OAuth客户端）可以通过接受发给不同（恶意）应用程序的访问令牌而成为混乱的代理，从而使攻击者能够访问受害者的帐户。

验证访问令牌的关键步骤是应用程序验证访问令牌最初是否未发布到其他应用程序。 Google calls attention to this when they say：

  

注意：验证令牌时，确保响应中的受众群体字段与在API控制台中注册的client_id完全匹配至关重要。这是对混乱的副问题的缓解，执行这一步绝对至关重要。

作为简化示例，假设有两个应用程序：（1）FileStore，合法文件存储应用程序，以及（2）EvilApp。这两款应用都使用Google的身份验证流程来处理客户端应用。 Alice是无辜的最终用户，她的Google用户ID是XYZ。

1. Alice使用Google登录FileStore。
2. 在身份验证过程之后，FileStore会为Alice创建一个帐户，并将其与Google用户ID XYZ关联。
3. Alice将一些文件上传到她的FileStore帐户。到目前为止一切都很好。
4. 稍后，Alice登录EvilApp，它提供的游戏看起来很有趣。
5. 因此，EvilApp获得了与Google用户ID XYZ相关联的访问令牌。
6. EvilApp的所有者现在可以构建FileStore的重定向URI，插入为Alice的Google帐户发出的访问令牌。
7. 攻击者连接到FileStore，后者将获取访问令牌并与Google核对以查看其用户。谷歌会说它是用户XYZ。
8. FileStore会让攻击者访问Alice的文件，因为攻击者拥有Google用户XYZ的访问令牌。

FileStore的错误并未通过Google验证它所提供的访问令牌是真正发给FileStore的;该令牌真的发给了EvilApp。

其他人比我更优雅地描述了这个：

• http://www.thread-safe.com/2012/02/more-on-oauth-implicit-flow-application.html
• http://www.thread-safe.com/2012/01/problem-with-oauth-for-authentication.html
• http://tools.ietf.org/html/rfc6749#section-10.16

我希望这能解释为什么部分访问令牌验证与客户端应用程序，以及它如何与困惑的代理问题相关。

Answer 2

你是如何使用OAuth2的？您是否获得授权代码并交换刷新令牌？或者您是通过前端直接获得访问权限？

如果您收到了授权码，那么您就完成了，因为Google在后端执行的client_secret检查可以保证为您的应用程序发出的所有代币都是为了授权代码而返回的。

如果您通过前端收到access_token + id_token，则应使用推荐的库验证id_token签名，然后验证id_token中的'aud'字段是否与您为Google应用程序注册的字段匹配。为了获得完整的安全性，还要使用id_token交叉验证access_token（id_token包含access_token的截断哈希值'at_hash'），如下所述：https://developers.google.com/accounts/docs/OAuth2Login