浏览新的OAuth2.0规范(rfc 6749)时,我发现隐式授权协议工作流程使用Url Hash Fragments在授权服务器和公共客户端之间交换“access_token”。
请参见规范:https://www.rfc-editor.org/rfc/rfc6749#section-4.2
除了Url片段,不能将授权授予响应作为“查询参数”发送,保持其他部分不变吗?
基本上,我无法理解使OAuth2的规范作者选择url hash fragments用于隐式授权流程授权的限制是什么?
浏览新的OAuth2.0规范(rfc 6749)时,我发现隐式授权协议工作流程使用Url Hash Fragments在授权服务器和公共客户端之间交换“access_token”。
请参见规范:https://www.rfc-editor.org/rfc/rfc6749#section-4.2
除了Url片段,不能将授权授予响应作为“查询参数”发送,保持其他部分不变吗?
基本上,我无法理解使OAuth2的规范作者选择url hash fragments用于隐式授权流程授权的限制是什么?
隐式授权流程是为 JavaScript 客户端设计的,我认为他们使用 '#' 而不是 '?' 来避免将访问令牌发送到重定向 URL 的服务器端,但仍然可以到达 JavaScript,这在我们的情况下是客户端,可能是出于安全原因,“不共享访问令牌以避免在网络上不安全,例如重定向 URL 所使用的访问令牌”。
在安全性方面,URI Fragment被用来代替查询参数。URI片段永远不会被发送到重定向的URL网络上。例如,在Oauth授权服务器登录后,位置标头将有"ur redirect url#access_token = uraccesstoken",响应代码将为302。当浏览器看到302时,它会自动重定向到位置标头值(用户代理程序自动执行此操作,并且JavaScript无法停止此操作(据我所知) )。
由于它是一个URI片段,因此只有重定向URL被发送到网络上,URI片段则不会被发送。
如果它是一个查询参数,则查询参数也将被发送到网络上。即使使用TLS,查询参数也将显示在代理日志中,从而使我们的访问令牌暴露给意外的人,导致访问令牌泄漏。