帶有半私密密鑰的OAuth授權代碼的安全

Question

我正在開發一個應用程序，其中的OAuth密鑰將無法完全保護;有一組用戶將被暴露在必要的情況下。所以想象下面這樣的情況：

一家公司正在開發它爲公衆託管的軟件，該軟件依靠OAuth2向某個第三方進行身份驗證。但是，這個應用程序的OAuth祕密不可避免地會暴露給公司的所有僱員。據推測，一些不好的員工可能會將其用於惡意目的，或與其他人分享。

我最初傾向於認爲這樣的環境應該使用OAuth2工作流程，該工作流程並非以在服務器上保留祕密的祕密密鑰爲依據。然而，我讀到的信息越多，我越傾向於認爲authorization code工作流可能實際上更適合於此，因爲祕密密鑰 - 儘管不完全保密 - 至少僅暴露於子集「值得信賴」的演員。

上午我相信這個authorization code工作流程將只有提高安全性的環境中，密鑰不能保持完全的祕密是否正確？如果祕密已被泄密，是否會通過使用authorization code而不是implicit工作流引入任何威脅？如果匿名/公衆用戶無法訪問密鑰，除012/之外是否有任何其他原因使用implicit工作流？

Answer 1

即使客戶端密鑰可能泄漏，授權代碼授權也比隱含更安全。這種情況與向公衆使用授權代碼授權相同，而不是保密的客戶端。

隱式授予的唯一好處是簡化和性能改進（避免客戶端和授權服務器之間的反向通道調用）。

隱授權具有至少這些弱點，其不存在於所述授權許可：

• 訪問令牌以URI片段發送其可將其暴露在未授權方（在瀏覽器高速緩存例如，參照網址參數，日誌）
• 在隱Grant資源所有者獲得訪問令牌

在情況下，祕密獲取授權授予泄露，潛在的攻擊者將能夠：

• 代表客戶端請求令牌（並可能模擬客戶端，例如通過DNS操作），但同樣適用於隱式授權
• 萬一攻擊者能夠獲得刷新令牌（通過危及客戶端），他將能夠重新使用它們（可以通過不存儲刷新令牌）

在任何情況下，您都應該確保授權服務器註冊您的客戶端的URL，並驗證授權代碼流中提供的redirect_uri對客戶端有效。您必須使用SSL/TLS將授權代碼傳輸到客戶端，並交換訪問令牌的授權代碼。

你可以找到關於這個問題的的OAuth 2.0威脅模型文件（http://tools.ietf.org/html/rfc6819）