OAuth2.0 隐式授权流程。为什么要使用 url 哈希片段？答案

【问题标题】：OAuth2.0 Implicit Grant flow. Why use url hash fragments?OAuth2.0 隐式授权流程。为什么要使用 url 哈希片段？
【发布时间】：2013-05-19 23:45:09
【问题描述】：

通过新的 OAuth2.0 规范 (rfc 6749)，我看到隐式授予协议工作流使用 Url 哈希片段在授权服务器和公共客户端之间交换“access_token”。

查看规格：https://www.rfc-editor.org/rfc/rfc6749#section-4.2

不能将授权授予响应作为“查询参数”而不是 URL 片段发送，从而保持流程的其他部分不变吗？

基本上我无法理解 OAuth2 的规范作者选择 url 哈希片段进行隐式授权流授权的限制？

【问题讨论】：

标签： oauth-2.0

【解决方案1】：

加上我的 2 美分 ..

从安全的角度来看，使用 URI Fragment 代替查询参数。 URI 段永远不会通过网络发送到重定向 url。例如登录 Oauth 授权服务器后，location header 将有“ur redirect url”#access_token=uraccesstoken，响应码为 302。当浏览器看到 302 时，会自动重定向到 location header 值（用户代理它会自动执行，并且 javascript 无法停止此操作（afaik））。

由于它是一个 URI 片段，因此只有重定向 url 会通过网络发送，而不是 uri 片段。

如果是查询参数，查询参数也将通过网络发送。即使使用 TLS，查询参数也会在您的代理日志中可见，从而使我们的访问令牌被无意中的人知道，从而导致访问令牌泄漏。

【讨论】：

【解决方案2】：

隐式授权流程是为 java 脚本客户端完成的，我认为他们使用的是 '#' 而不是 '?'不将访问令牌发送到您的重定向 URL 的服务器端，但它仍然可以访问 javascript，在我们的例子中是客户端可能是出于安全原因“不通过网络共享您的访问令牌可能像用于重定向 URL 的那样不安全”

【讨论】：

谢谢波波！同意你的解释。阅读规范，我从来没有想过重定向到重定向不涉及 TLS，这使得令牌容易受到“中间人攻击”的影响
但这带来了一个与授权码授予流程相关的问题。此流程要求 Auth 服务器在成功验证时发出“代码”，并将用户代理与代码一起重定向到 redirect_url。由于此重定向不涉及 TLS，是否意味着授权“代码”的安全性受到损害？
该代码仅用于生成令牌一次，并且需要客户端 ID 和客户端密码，因此它是安全的，因为客户端密码不共享，只是客户端系统知道它。
@coderVishal Rails 是一个服务器端框架。 url 片段明确不会发送到服务器，因此您的 rails 应用程序将无法使用。这就是授权代码流的用途（顺便说一句，它也更安全）。
@coderVishal 不用担心，规范很长，而且经常会让人困惑。我个人从 Pluralsight 等在线课程中获益良多。