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

Question

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

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

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

Answer 1

Google特指访问令牌.

在OAuth 2.0的上下文中,混淆的代理问题在用于身份验证时适用于隐式授权协议流.Google称之为"OAuth 2.0 for Client-side Applications"基于隐式授权协议流程.

由于隐式流通过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.

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

• 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

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