基於哈希片段的安全性如何工作？

Question

我正在學習OAuth 2.0，無法在隱式授權流程中獲得保護訪問令牌的方法。 規范中有一些論文和一些看起來相互矛盾的SO答案。 有人可以清理一下嗎？ 來自SO答案和規范的引言令我感到困惑：

（來自規范）用於將訪問令牌傳遞到客戶端的重定向URI。 可以向訪問資源所有者的用戶代理的資源所有者或其他應用程序公開訪問令牌。
（來自規范）訪問令牌憑證（以及任何機密訪問令牌屬性）必須在傳輸和存儲中保密，並且僅在授權服務器，訪問令牌有效的資源服務器以及與之對應的客戶端之間共享。發出訪問令牌。 訪問令牌憑證必須僅使用TLS傳輸。
（來自接受和贊成的回答）在隱式流中，訪問令牌作為哈希片段傳遞，只有瀏覽器知道哈希片段。 瀏覽器會將哈希片段直接傳遞到目標網頁/重定向URI，即客戶端的網頁（哈希片段不是HTTP請求的一部分），因此您必須使用Javascript讀取哈希片段。 哈希片段不能被中間服務器/路由器攔截（這很重要）。

我的問題：

P1表示通過重定向URI和P2傳遞給客戶端的令牌表示傳遞通道必須是TLS編輯的。 但是P3說哈希片段沒有發送到網絡 。 如果訪問令牌沒有發送，那么它是如何到達客戶端的，因為它是哈希片段？ 無論如何，它必須通過網絡發送不是嗎？ 或者使用重定向URI發送令牌可以在沒有網絡交易的情

唯一可能的解釋 - 在引擎蓋下瀏覽器僅通過網絡發送url的非哈希部分，並且在加載新頁面之后，只需插入哈希片段並使其可用於JS。 如果我是對的，我仍然無法理解為什么我們不使用可靠，安全的HTTPS通道作為響應參數發送令牌？

Answer 1

OAuth提供程序使用HTTP響應重定向將訪問令牌發送回OAuth使用者：

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

請注意訪問令牌是如何通過網絡發送的，作為來自OAuth提供程序的HTTP響應的一部分，除了使用者之外，它還應該在HTTPS上。

然后，您的瀏覽器將對使用者端點執行新的HTTP GET請求：

GET /redirect_uri HTTP/1.1
Host: consumer.org

請注意如何通過網絡將訪問令牌發送給使用者。 consumer.org的服務器不會在此HTTP請求中收到令牌。 相反，從https://consumer.org/redirect_uri返回的網頁將包含能夠並將從url片段讀取訪問令牌的javascript。

因此，您需要信任從consumer.org（通過使用HTTPS）收到的javascript代碼，因為如果攻擊者可以注入代碼，它也可以間接獲取訪問令牌（並將其發送到任何地方）。

來自消費者的HTTP響應示例：

200 OK
Content-Type: text/html

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

基於哈希片段的安全性如何工作？

問題描述

1 個解決方案

解決方案1
9 已采納 2014-09-11 11:58:45

基於哈希片段的安全性如何工作？

問題描述

1 個解決方案

解決方案1 9 已采納 2014-09-11 11:58:45

解決方案1
9 已采納 2014-09-11 11:58:45