Google OAuth 令牌验证如何以及为何执行？

当 Google OAuth 文档指示我在访问令牌、刷新令牌、范围、受众和客户端 ID 之间进行操作时，我感到很困惑验证所有令牌 https://developers.google.com/accounts/docs/OAuth2UserAgent#validatetoken以防止副手混乱的问题。维基百科文章链接到 http://en.wikipedia.org/wiki/Confused_deputy_problem仅描述了较高级别的一般问题，而不是特定于 OAuth 甚至网络身份验证。如果我理解正确的话，令牌验证甚至不是 OAuth2 的一部分，但实际上取决于具体的实现。所以这是我的问题：

Google OAuth 令牌验证如何以及为何执行？

在这种情况下，混淆代表问题的具体例子将受到特别赞赏。另请注意，我是在完全客户端应用程序的背景下提出这个问题的，如果这有什么不同的话。

谷歌特意指的是access token.

在 OAuth 2.0 的背景下，混淆代理问题适用于隐式授予协议流程 https://www.rfc-editor.org/rfc/rfc6749#section-4.2当用于验证。 Google 所谓的“客户端应用程序的 OAuth 2.0”基于隐式授权协议流程。

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

验证访问令牌的关键步骤是应用程序验证访问令牌最初不是颁发给其他应用程序的。当谷歌说时，请注意这一点 https://developers.google.com/accounts/docs/OAuth2UserAgent#validatetoken:

注意：验证令牌时，确保响应中的受众字段与您在 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. 后来，爱丽丝登录了 EvilApp，它提供的游戏看起来很有趣。
5. 结果，EvilApp 获得了与 Google 用户 ID XYZ 关联的访问令牌。
6. EvilApp 的所有者现在可以构建 FileStore 的重定向 URI，插入为 Alice 的 Google 帐户颁发的访问令牌。
7. 攻击者连接到 FileStore，FileStore 将获取访问令牌并与 Google 核实以了解它适用于哪个用户。 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/02/more-on-oauth-implicit-flow-application.html
• http://www.thread-safe.com/2012/01/problem-with-oauth-for-authentication.html http://www.thread-safe.com/2012/01/problem-with-oauth-for-authentication.html
• https://www.rfc-editor.org/rfc/rfc6749#section-10.16 https://www.rfc-editor.org/rfc/rfc6749#section-10.16

我希望这能解释why客户端应用程序访问令牌验证的一部分，以及它与混乱的代理问题的关系。