如何以及为什么执行Google OAuth令牌验证? [英] How and why is Google OAuth token validation performed?

问题描述

在访问令牌，刷新令牌，范围，访问者和客户端ID之间，当Google OAuth文档指示我链接到Wikipedia的文章仅在较高级别上描述了一般问题，而不是特定于OAuth甚至网络身份验证.如果我正确理解，令牌验证甚至不是OAuth2的一部分，而是实际上取决于特定的实现.所以这是我的问题:

Between access tokens, refresh tokens, scopes, audiences, and client IDs, I was confused when the Google OAuth documentation instructed me to validate all tokens in order to prevent the confused deputy problem. The Wikipedia article linked to only describes the general problem at a high level, not specific to OAuth or even network authentication. If I understand it correctly, token validation is not even part of OAuth2 but actually depends on the specific implementation. So here is my question:

如何以及为什么执行Google OAuth令牌验证?

在此情况下，代理副手问题的具体示例将特别受到赞赏.还要注意，我问的是在完全客户端应用程序的情况下，是否有所作为.

A concrete example of the confused deputy problem in this context would be especially appreciated. Also note that I ask this in the context of entirely client-side apps, if that makes a difference.

推荐答案

Google专指 access 令牌.

Google is referring specifically to the access token.

在OAuth 2.0的上下文中，困惑的代理问题适用于隐式授予协议流，当用于身份验证. Google所说的用于客户端应用程序的OAuth 2.0"是基于隐式授予协议流的.

In the context of OAuth 2.0, the confused deputy problem applies to the Implicit Grant protocol flow when used for authentication. What Google calls "OAuth 2.0 for Client-side Applications" is based on the implicit grant protocol flow.

由于隐式流通过URI片段将访问令牌公开给最终用户，因此它引入了可能会篡改访问令牌的可能性.合法的应用程序(OAuth客户端)可以通过接受颁发给其他(恶意)应用程序的访问令牌来使自己感到困惑，从而使攻击者可以访问受害者的帐户.

Since the implicit flow exposes the access token to the end user through the URI fragment, it introduces the possiblity that the access token might be tampered with. A legitimate app (an OAuth client) can become the confused deputy by accepting an access token that was issued to a different (malicious) app, thereby giving an attacker access to a victim's account.

验证访问令牌的关键步骤是应用程序验证访问令牌最初不是发给其他应用程序的. Google在他们说""时引起注意:

The critical step in validating the access token is that the app verifies that the access token was not originally issued to a different app. Google calls attention to this when they say:

注意:验证令牌时，确保响应中的受众"字段与在API控制台中注册的client_id完全匹配至关重要.这是缓解代理人困惑的问题，执行此步骤绝对至关重要.

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.

As a simplified example, imagine there are two apps: (1) FileStore, a legitimate file storage app, and (2) EvilApp. Both apps use Google's authentication process for client-side apps. Alice is an innocent end user, and her Google user ID is XYZ.

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

FileStore的错误是未与Google确认所获得的访问令牌是否确实发给了FileStore；该令牌确实已发行给EvilApp.

FileStore's mistake was not verifying with Google that the access token it was given was truly issued to FileStore; the token was really issued to EvilApp.

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

Others have described this much more elegantly than I:

• 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

• 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

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

I hope this explains the why part of access token validation with client-side apps, and how it relates to the confused deputy problem.

这篇关于如何以及为什么执行Google OAuth令牌验证?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！