使用OAuth 2.0授權代碼流識別瀏覽器（用戶代理）會話

Question

在OAuth 2.0授權代碼流中，與客戶端協調瀏覽器/用戶代理會話的標准最佳實踐方法是什么？

在OAuth 2.0授權代碼流中，客戶端（您正在使用的Web應用程序）直接從授權服務器獲取訪問令牌。 訪問令牌永遠不會暴露給瀏覽器/用戶代理，這是代碼流的重要優點之一。 客戶端安全性保留訪問令牌（和刷新令牌，如果提供的話），以便它可以將其重用於用戶的后續請求（通過瀏覽器/用戶代理）。

這就引出了一個問題：客戶端和瀏覽器/用戶代理如何傳達用戶的會話，以便客戶端“知道”代表用戶使用的訪問令牌，並且這樣做可以嗎？

我找到了示例代碼，其中客戶端為瀏覽器/用戶代理創建了一個會話cookie。 這行得通，但似乎重新打開了基於cookie的漏洞利用的大門。 有防止這些攻擊的標准方法，但是我認為OAuth 2.0的好處之一就是完全避免了這些攻擊。 （此外，我們正在托管Web REST API，因此沒有任何形式的POST，並且我希望保持API接口的簡潔，簡潔並基於標准的安全方法。）

筆記：

• REST中的OAuth令牌和會話實際上並不能回答這個特定問題，盡管我也很喜歡Greg Beech的回答。

• 了解OAuth和客戶端會話的問題具有相似的意圖，但答案不適用於我們的情況。

• 這個問題是關於用戶代理的后續請求，而不是回調處理程序。

• 我們完全期望並希望我們的REST請求不會是無狀態的，並且客戶端將維護用戶會話的狀態信息。 出於非常好的原因（我不想在這里列舉），我們沒有建立無狀態的REST接口。

Answer 1

我將以我理解的方式重申您的問題。 OAuth2授權代碼流的好處是敏感訪問令牌不會通過用戶代理傳遞，因此不會受到用戶代理的安全漏洞的影響。 好吧，如果擔心用戶代理上的安全漏洞，那么為什么客戶端應該使用cookie來維護與用戶代理的會話？ 客戶端不應該使用其他機制來維護與用戶代理的會話嗎？

好吧，這是我的答案...

我認為最佳實踐仍然是Web應用程序OAuth客戶端與用戶代理保持會話的cookie。 Cookies具有眾所周知的安全性。 但是OAuth訪問令牌的用途不同於cookie。

我認為OAuth2並非旨在緩解基於Cookie的漏洞。 OAuth2的主要目的是允許用戶將對數據的訪問權限委派給客戶端，而無需向客戶端公開用戶憑據。 此外，使用OAuth隱式流，訪問令牌會以不使用cookie的方式在用戶代理中公開。

基於Cookie的漏洞利用無疑可以使攻擊者偽裝成用戶，並導致Web應用程序OAuth客戶端使用其訪問令牌訪問OAuth資源上的用戶數據。 但是，用戶本人是基於cookie的利用的主要攻擊媒介（例如：用戶訪問執行XSRF / CSRF的惡意站點）。 但這不是OAuth授權服務器的工作。 OAuth授權服務器的工作是確保正確的客戶端根據用戶的同意獲得正確的訪問令牌。