google-oauth - 如何以及为何执行 Google OAuth token 验证？

Question

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

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

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

Answer 1

谷歌专门指的是访问 token 。
在 OAuth 2.0 的上下文中，混淆代理问题适用于 Implicit Grant protocol flow用于身份验证时。 Google 称之为“客户端应用程序的 OAuth 2.0”是基于隐式授权协议(protocol)流。
由于隐式流程通过 URI 片段向最终用户公开访问 token ，因此它引入了访问 token 可能被篡改的可能性。合法应用程序(OAuth 客户端)可以通过接受颁发给不同(恶意)应用程序的访问 token 而成为困惑的代理，从而使攻击者可以访问受害者的帐户。
验证访问 token 的关键步骤是应用程序验证访问 token 最初不是颁发给不同的应用程序。 Google calls attention to this when they say :

Note: When verifying a token, it is critical to ensure the audience field in the response exactly matches your client_id registered in the APIs Console. This is the mitigation for the confused deputy issue, and it is absolutely vital to perform this step.

作为一个简化的示例，假设有两个应用程序:(1) FileStore，一个合法的文件存储应用程序，和 (2) EvilApp。这两个应用程序都使用 Google 的客户端应用程序身份验证流程。 Alice 是一个无辜的最终用户，她的 Google 用户 ID 是 XYZ。

Alice 使用 Google 登录 FileStore。

在身份验证过程之后，FileStore 为 Alice 创建一个帐户并将其与 Google 用户 ID XYZ 相关联。

Alice 将一些文件上传到她的 FileStore 帐户。到目前为止一切都很好。

后来，Alice 登录了 EvilApp，它提供的游戏看起来很有趣。

结果，EvilApp 获得了与 Google 用户 ID XYZ 关联的访问 token 。

EvilApp 的所有者现在可以为 FileStore 构造重定向 URI，插入它为 Alice 的 Google 帐户颁发的访问 token 。

攻击者连接到 FileStore，它会获取访问 token 并与 Google 核对以查看它是针对哪个用户的。谷歌会说它是用户 XYZ。

FileStore 将允许攻击者访问 Alice 的文件，因为攻击者拥有 Google 用户 XYZ 的访问 token 。

FileStore 的错误在于没有向 Google 验证它所提供的访问 token 确实是颁发给 FileStore 的； token 确实是发给 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

https://www.rfc-editor.org/rfc/rfc6749#section-10.16

我希望这能解释为什么使用客户端应用程序验证访问 token 的一部分，以及它与混淆代理问题的关系。