24

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

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

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

4

2 回答 2

46

谷歌专门指的是访问令牌。

在 OAuth 2.0 的上下文中，混淆代理问题适用于用于身份验证时的隐式授权协议流。Google 称之为“客户端应用程序的 OAuth 2.0”是基于隐式授权协议流。

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

验证访问令牌的关键步骤是应用程序验证访问令牌最初不是颁发给不同的应用程序。当他们说：

注意：验证令牌时，确保响应中的受众字段与您在 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 的。

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

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

于 2013-07-03T03:46:42.073 回答
3

您如何使用 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

于 2013-06-22T20:43:05.050 回答