基于哈希片段的安全性究竟是如何工作的？

java user-agent oauth-2.0 oauth

2022-09-03 02:28:12

我正在学习 OAuth 2.0，无法在隐式授权流中获取保护访问令牌的方法。规范中有一些论文和一些投票的SO答案看起来相互矛盾。有人可以清除它吗？SO答案和规范中的引用让我感到困惑：

（从规格）用于将访问令牌传递到客户端的重定向 URI。访问令牌可能向资源所有者或有权访问资源所有者的用户代理的其他应用程序公开。
（从规格）访问令牌凭据（以及任何机密访问令牌属性）在传输和存储过程中必须保密，并且仅在授权服务器、访问令牌对其有效的资源服务器以及向其颁发访问令牌的客户端之间共享。访问令牌凭据只能使用 TLS 传输。
（来自接受和投票的SO答案）在隐式流中，访问令牌作为哈希片段传递，只有浏览器知道哈希片段。浏览器会将哈希片段直接传递到目标网页/重定向URI，这是客户端的网页（哈希片段不是HTTP请求的一部分），因此您必须使用Javascript读取哈希片段。哈希片段不能被中间服务器/路由器拦截（这很重要）。

我的问题：

P1表示通过重定向URI传递到客户端的令牌，P2表示传递通道必须是TLS-ed。但是P3说哈希片段不会发送到网络。如果访问令牌由于哈希片段而未发送，它如何到达客户端？无论如何，它必须通过网络发送，不是吗？或者发送带有重定向URI的令牌在没有网络交易的情况下会产生一些魔力？

唯一可能的解释 - 在引擎盖下，浏览器仅通过网络发送URL的非哈希部分，并且在加载新页面后，只需插入哈希片段并使其可供JS使用。如果我是对的，我仍然无法理解为什么我们不简单地发送带有可靠，安全的HTTPS通道作为响应参数的令牌？

答案 1

OAuth 提供程序使用 HTTP 响应重定向将访问令牌发送回 OAuth 使用者：

HTTP/1.1 302 Found
Location: https://consumer.org/redirect_uri#access_token=1111-2222-3333-4444

请注意访问令牌是如何通过网络发送的，作为来自 OAuth 提供程序的 HTTP 响应的一部分，除了使用者之外，OAuth 提供程序还应在 HTTPS 上。

然后，您的浏览器将向使用者终结点执行新的 HTTP GET 请求：

GET /redirect_uri HTTP/1.1
Host: consumer.org

请注意访问令牌如何不通过网络发送给使用者。服务器上不会在此 HTTP 请求中接收令牌。相反，从返回的网页将包含能够并且将从url片段读取访问令牌的javascript。consumer.orghttps://consumer.org/redirect_uri

因此，您需要信任从 consumer.org（通过使用HTTPS）收到的javascript代码，因为如果攻击者可以注入代码，它也可以间接获取访问令牌（并将其发送到任何地方）。

来自使用者的 HTTP 响应示例：

200 OK
Content-Type: text/html

<html><head><script> 
    alert(window.location.hash) 
</script>
</head><body></body></html>

答案 2