oAuth2.0 访问令牌混淆答案

【问题标题】：oAuth2.0 access token confusionoAuth2.0 访问令牌混淆
【发布时间】：2013-04-30 16:52:36
【问题描述】：

我正在关注本教程关于 OAuth2.0 https://developers.google.com/youtube/v3/guides/authentication

OAuth2.0 的工作原理看起来很清楚。但是我对访问令牌部分有点困惑。

获取用户的访问令牌后，您的应用程序可以使用该令牌代表该用户提交授权的 API 请求。 API 支持两种指定访问令牌的方法：访问令牌作为 access_token 查询参数的值：

www.googleapis.com/youtube/v3/videos?access_token=ACCESS_TOKEN

如果有人在 url 传输过程中获得了这个访问令牌，他们可以访问这个受保护的资源吗？

服务器如何知道请求是否来自最初请求访问令牌的客户端？

更新： 阅读这篇文章Are HTTPS headers encrypted? 后，我的困惑被清除了。我认为查询字符串在网络传输过程中没有加密。

【问题讨论】：

标签： oauth-2.0

【解决方案1】：

一般来说，我认为 OAuth 2.0 是一种服务器端技术，所有访问令牌和通信都应使用 SSL 传输，因为承载令牌需要尽可能安全。

【讨论】：

在我看来，这个请求 www.googleapis.com/youtube/v3/videos?access_token=ACCESS_TOKEN ACCESS_TOKEN 是 url 的一部分。不安全吧？为什么谷歌会这样传递访问令牌？

【解决方案2】：

另外，您需要知道 OAuth 2.0 中有两种类型的流
i) 隐式授权流程 - 这是用户登录到服务提供商并且他的浏览器获取访问令牌的流程。假设您有 X.com 并通过 Facebook 登录。一旦用户输入他的 FB 凭据，访问令牌就会发送到他的浏览器。

ii) 授权码流程 - 在这个流程中（再次考虑上述情况），facebook 将向用户的浏览器传递一个授权码。如果有人以某种方式截获授权码，他无能为力。当使用有效的客户端凭据传递时，可以将授权代码交换为访问。因此，当用户登录时，他的浏览器会获得一个授权代码，该代码会传递到您位于 X.com 的服务器。从那里您将点击 FB 提供的代码令牌交换端点并将访问令牌返回到您的服务器！

授权代码流增加了另一层安全性，其中访问令牌仅对客户端 + 服务器可见，而对用户代理不可见。正如您自己发现的那样，令牌是通过 HTTPS 传递的。

【讨论】：

授权码被拦截，同时恶意攻击者故意延迟响应的情况（可能有点做作）怎么样。然后，攻击者将在其浏览器中输入截获的 URL（其中包含授权代码），以立即访问受害者的资源。当然，Mr. Evil 可以将整个过程自动化到所有受害者都将被拒绝访问的程度，因为访问令牌已经被交换。