Oauth2如何保護資源所有者？

Question

我花了最近幾個小時閱讀關於Oauth2協議。根據我的理解，此協議的主要動機是資源所有者不必與第三方（客戶端）應用程序共享其憑據，而只需與資源服務器共享憑據。

在這篇文章中我已經用作Oauth2 RFC定義的角色。但是我沒有區分資源服務器和授權服務器。爲簡單起見，我假定它們是相同的，並將它們稱爲「資源服務器」。

我可以看到事件的兩個不同的鏈。假定這兩種情況都是以資源所有者爲開始，目的是讓客戶訪問受保護的資源。由資源服務器提供

案例1，GUI
1.客戶端轉發資源所有者的資源服務器的登錄頁面。
2.資源所有者的資源服務器的GUI提供他/她的證書。
3.在成功的資源服務器轉發的資源所有者的客戶端，並提供用戶客戶端的令牌。由客戶
1.客戶提供

案例2，GUI詢問資源擁有者提供他/她的憑據，以它自己的GUI。
2.客戶端將提供的憑證發送到資源服務器。
3.成功時，客戶端獲得令牌並訪問資源服務器。

我擔心的是2的情況下是何等的難將是客戶端獲取資源服務器上的全部特權，如果它，而不是認證作爲客戶端，認證爲資源擁有者？該RFC狀態下爲理由，要求使用的，而不是讓客戶端處理資源所有者憑證的OAuth2：

「第三方應用程序獲取對資源 所有者的受保護的資源過於寬泛的訪問，使資源擁有者沒有任何 能夠限制持續時間或訪問有限的資源子集。「

的RFC進一步指出：

「第三方應用程序都需要存儲資源 所有者以供將來使用憑證，通常在 明文密碼。」

這很可能是由客戶端的情況下，保存的2

所以......你能假設實現的oauth2客戶端（在案例2中）是更安全的，然後一個不？資源服務器是否可以實現機制來防止這些事情發生？

Answer 1

你可以假設使用適當的OAuth2實現你的系統比傳統的用戶名/密碼爲基礎的系統更安全。

案例1明顯優於由於沒有用戶憑證被暴露給客戶端。

案例2只有一種可能，很多的OAuth2提供商不支持它。即使是標準的勸阻使用它，它似乎只是作爲一個後備時，普通的舊用戶/通過基於邏輯仍然必須用於一些奇怪的原因。由於客戶端應用程序可能根本不存儲您的憑證，因此這種情況仍然稍好一些。指定的憑據可以在創建OAuth請求後立即丟棄，並且只應存儲授予的令牌。獲得刷新令牌後，無需再次詢問您的用戶/傳遞。

注意，從應用程序竊取的標記仍然是一個安全隱患，但小偷不會有完全權限使用您的憑據，將只有您授予應用程序的訪問權限。此外，訪問令牌到期並且提供者應支持撤銷刷新令牌。

Answer 2

考慮2種情況：

比方說資源擁有者提供他/她的憑據，客戶端和你說的客戶端有一些地方保存密碼以純文本形式。

1），但我們可以相信客戶端，它不會未經您的許可訪問任何信息？
2）如果有人侵入客戶端數據庫並獲得所有可能包含敏感信息（如netbanking密碼等）的憑證，那該怎麼辦？

所以要防止這些安全問題，資源擁有者直接與資源服務器處理，並設置客戶端的權限來訪問這就是了，更不是有點唯一信息。然後，服務器向客戶端發出令牌（如門戶通道），並且每當客戶端需要一些信息時，它就必須發送令牌。

所以最好不要給客戶提供憑據出於安全原因。