oAuth2.0访问令牌混淆

我正在关注本教程中有关OAuth2.0的信息https://developers.google.com/youtube/v3/guides/authentication oAuth2.0访问令牌混淆

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

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

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

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

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

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

来源

2013-05-06 wwli

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

来源

2013-05-06 21:11:44 Jammer

在此请求中，我认为www.googleapis.com/youtube/v3/videos?access_token=ACCESS_TOKEN ACCESS_TOKEN是url的一部分。这不安全吗？为什么谷歌像这样传递访问令牌？ – wwli 2013-05-06 21:16:18

另外，你需要知道，有两种类型的OAuth的流量2.0
我）隐性补助流 - 这是在给服务提供商的用户登录和他的浏览器获得访问令牌中的流。假设你有X.com并通过Facebook登录。一旦用户键入他的FB凭证，访问令牌就会发送到他的浏览器。

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

授权代码流添加了另一个安全层，其中访问令牌仅对客户端+服务器可见，而对用户代理不可见。当你自己想出来的时候，令牌就通过HTTPS传递。

来源

2013-05-07 04:30:48 divyanshm

那么在授权代码被截获的同时，恶意攻击者故意延迟响应的情况（可能有点人为的）呢？然后，攻击者将在浏览器中输入截获的URL（具有授权码），以便即时访问受害者的资源。当然，邪恶先生可以自动化整个过程，所有受害者都将被拒绝访问，因为访问令牌已经被交换。 – simou 2015-09-16 10:44:39

oAuth2.0访问令牌混淆

回答

相关问题