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

我正在學習OAuth 2.0，並且無法獲得保護訪問令牌的方式隱式授權流程。規範中有一些論文和一些有爭議的SO答案看起來相互矛盾。有人可以清除它嗎？來自SO答案和規範的引用令我感到困惑：基於哈希片段的安全性是如何工作的？

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

我的問題：

P1表示，令牌經由重定向URI和P2傳送到客戶說輸送通道必須TLS-ED。但P3說散列片段沒有發送到網絡。訪問令牌如果由於散列片段而未發送，它如何到達客戶端？無論如何，它必須由網絡發出是不是？或者使用重定向URI發送令牌會產生一些不帶網絡優惠的魔法？

唯一可能的解釋 - 引擎蓋下的瀏覽器只通過網絡發送url的非哈希部分，並且在加載新頁面後，只需插入哈希碎片並將其提供給JS。如果我是對的，我仍然不明白爲什麼我們不要簡單地將可靠，安全的HTTPS頻道作爲響應參數發送令牌？

來源

2014-09-10 Baurzhan

要OAuth提供者將訪問令牌回OAuth用戶用HTTP響應重定向：

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>

來源

2014-09-11 11:58:45

有關惡意軟件的JS代碼和HTTPS - 是的，大概HTTPS對客戶端安裝解決不良JS的問題，但不會散列片段魔法發明了非HTTPS客戶？如果散列片段不能完全抵禦像壞JS一樣的攻擊，那麼簡單地在客戶端上使用HTTPS併發送令牌作爲請求參數不是更好嗎？ – Baurzhan 2014-09-12 03:30:22

不，隱式授權流程不適用於非https客戶端，它適用於沒有後端的客戶端。沒有流將令牌作爲請求參數發送。與隱式授權流程不同，授權代碼流程將「代碼」作爲查詢字符串參數提供給客戶端後端。客戶端後端隨後將代碼與令牌（使用客戶端憑據的已驗證請求） – 2014-09-12 09:08:41

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

回答

相關問題