OAuth2.0隐式授权流程，为什么使用URL哈希片段？

Question

浏览新的OAuth2.0规范（rfc 6749）时，我发现隐式授权协议工作流程使用Url Hash Fragments在授权服务器和公共客户端之间交换“access_token”。

请参见规范：https://www.rfc-editor.org/rfc/rfc6749#section-4.2

除了Url片段，不能将授权授予响应作为“查询参数”发送，保持其他部分不变吗？

基本上，我无法理解使OAuth2的规范作者选择url hash fragments用于隐式授权流程授权的限制是什么？

- aknon

Answer 1

隐式授权流程是为 JavaScript 客户端设计的，我认为他们使用 '#' 而不是 '?' 来避免将访问令牌发送到重定向 URL 的服务器端，但仍然可以到达 JavaScript，这在我们的情况下是客户端，可能是出于安全原因，“不共享访问令牌以避免在网络上不安全，例如重定向 URL 所使用的访问令牌”。

- Bassem Reda Zohdy

---

谢谢Bobo！我同意你的解释。在阅读规范时，我从未想到重定向到重定向不涉及TLS，这使得令牌容易受到“中间人攻击”的影响。 - aknon

但是这带来了一个与授权码授权流相关的问题。该流程要求Auth服务器在成功验证后发出“代码”，并将用户代理重定向到redirect_url以及代码。由于此重定向不涉及TLS，这是否意味着授权“代码”的安全性受到威胁？ - aknon

代码仅用于生成令牌一次，需要客户端ID和客户端密码，因此它是安全的，因为客户端密码不会被共享，只有客户端系统知道它。 - Bassem Reda Zohdy

@coderVishal Rails是一个服务器端框架。URL片段明确地不会被发送到服务器，因此将无法在Rails应用程序中使用。这就是授权代码流的作用（顺便说一句，它也更安全）。 - Robba

@coderVishal 不用担心，规范很长，而且常常令人困惑。我个人从在线课程中受益匪浅，比如你可以在Pluralsight上找到。 - Robba

Answer 2

在安全性方面，URI Fragment被用来代替查询参数。URI片段永远不会被发送到重定向的URL网络上。例如，在Oauth授权服务器登录后，位置标头将有"ur redirect url＃access_token = uraccesstoken"，响应代码将为302。当浏览器看到302时，它会自动重定向到位置标头值(用户代理程序自动执行此操作，并且JavaScript无法停止此操作(据我所知) )。

由于它是一个URI片段，因此只有重定向URL被发送到网络上，URI片段则不会被发送。

如果它是一个查询参数，则查询参数也将被发送到网络上。即使使用TLS，查询参数也将显示在代理日志中，从而使我们的访问令牌暴露给意外的人，导致访问令牌泄漏。

- Vaya