我正在学习OAuth 2.0,并且无法获得保护访问令牌的方式隐式授权流程。规范中有一些论文和一些有争议的SO答案看起来相互矛盾。有人可以清除它吗?来自SO答案和规范的引用令我感到困惑:基于哈希片段的安全性是如何工作的?
- (From spec)重定向URI用于将访问令牌传递给客户端。访问令牌可能会暴露给资源所有者或其他可以访问资源所有者的用户代理的应用程序。
- (来自规范)访问令牌凭证(以及任何机密访问令牌 属性)务必在传输和存储中保密,并且 仅在授权服务器,访问令牌有效的资源服务器之间共享,以及发出访问令牌为 的客户端。访问令牌凭证只能使用TLS传输。
- (From accepted and upvoted SO answer)在隐式流中,访问令牌作为散列片段传递,只有浏览器知道散列片段。浏览器会将散列片段直接传递到目标网页/客户端网页的重定向URI(散列片段不是HTTP请求的一部分),因此您必须使用Javascript读取散列片段。哈希片段不能被中间服务器/路由器拦截(这很重要)。
我的问题:
P1表示,令牌经由重定向URI和P2传送到客户说输送通道必须TLS-ED。但P3说散列片段没有发送到网络。访问令牌如果由于散列片段而未发送,它如何到达客户端?无论如何,它必须由网络发出是不是?或者使用重定向URI发送令牌会产生一些不带网络优惠的魔法?
唯一可能的解释 - 引擎盖下的浏览器只通过网络发送url的非哈希部分,并且在加载新页面后,只需插入哈希碎片并将其提供给JS。如果我是对的,我仍然不明白为什么我们不要简单地将可靠,安全的HTTPS频道作为响应参数发送令牌?
有关恶意软件的JS代码和HTTPS - 是的,大概HTTPS对客户端安装解决不良JS的问题,但不会散列片段魔法发明了非HTTPS客户?如果散列片段不能完全抵御像坏JS一样的攻击,那么简单地在客户端上使用HTTPS并发送令牌作为请求参数不是更好吗? – Baurzhan 2014-09-12 03:30:22
不,隐式授权流程不适用于非https客户端,它适用于没有后端的客户端。没有流将令牌作为请求参数发送。与隐式授权流程不同,授权代码流程将“代码”作为查询字符串参数提供给客户端后端。客户端后端随后将代码与令牌(使用客户端凭据的已验证请求) – 2014-09-12 09:08:41