為什么我不應該在OAuth 2.0的移動應用中保留client_secret（授權代碼授予流程）

Question

我們有一個應用程序，該應用程序應通過作為授權服務器的第三方OAuth 2.0服務器使用身份驗證。

據我了解，有兩種可能性。

“正確”的是：

1. 移動應用程序商店client_id
2. 移動應用以GET / auth開頭以接收authorization_code
3. 授權服務器返回帶有重定向到redirect_uri和附加授權代碼的響應。 我們假設redirect_uri是我們自己服務器上的端點。
4. 移動應用遵循重定向
5. 我們的服務器接收請求，從查詢中獲取授權代碼，然后使用POST / token方法和client_secret（存儲在服務器上）將其交換為access_token。
6. 服務器對具有access_token的移動應用程序的響應
7. 移動應用獲取access_token並在以后的請求中使用它。

“壞”的是：

1. 移動應用程序存儲client_id 和client_secret
2. 移動應用以GET / auth開頭以接收authorization_code
3. 授權服務器返回帶有重定向到redirect_uri和附加授權代碼的響應。 我們假設該應用程序攔截了它並采用了授權代碼（我們可以簡單地要求重定向到本地主機）。
4. 移動應用使用POST / token方法和client_secret將其交換為access_token。
5. 移動應用接受access_token並在以后的所有請求中使用它。

所以我看不到這兩種選擇之間的真正區別。 在這兩種情況下，我們最終都會獲得訪問令牌。 在這兩種情況下，我們都需要真實用戶在相當安全的Web視圖中輸入其登錄名和密碼。

即使某些壞蛋會散布偽造的應用程序……又是什么禁止他們使用我們服務器的回調函數為access_token交換授權代碼呢？ 我們的服務器無法區分“不良”和“良好”應用程序-它僅接收請求GET \\ callback？code = blablabla並使用access_token進行回復。

那么，為什么我們要對服務器保密呢？ 假冒應用程序欺詐的情況如何？

Answer 1

使用OAuth，您可以根據需要/設置使用不同的流程。 根據不同的流程，OAuth角色的行為也將有所不同。

從您的描述中，我不確定要在客戶角色中扮演什么角色。 但是選項是：

1. 后端服務器是客戶端
2. 移動應用是客戶

對於情況1，您不需要在應用程序中存儲客戶端ID或客戶端密鑰，因為它將是您自己的后端服務器，可以與授權服務器和資源服務器進行通信。 如果是這種情況，那么您可以遵循授權碼流程。

對於情況2，將是與授權和資源服務器通信的應用程序本身。 在這種情況下，建議使用“隱式流”。 它不被視為安全流程，移動設備或Web應用也不被視為存儲客戶端密鑰的安全場所，因為您必須以某種方式將它們存儲在應用的代碼中。 下面是一個（有點費解的）方案來解釋為什么這種方法不安全：客戶端機密由授權服務器或服務注冊表發布，任何黑客攻擊都需要您對其進行更改，這可能意味着更改代碼。 對於移動應用程序，這意味着您的用戶將更新到新版本。 普遍認為，作為安全性的額外步驟（而不是客戶端機密）的一種建議是，使用“狀態”或“隨機數”字段來確保授權請求來自向其頒發令牌的同一應用程序。 從RFC第4.1.1節（ http://tools.ietf.org/html/rfc6749#section-4.1.1 ）：

州

  RECOMMENDED. An opaque value used by the client to maintain state between the request and callback. The authorization server includes this value when redirecting the user-agent back to the client. The parameter SHOULD be used for preventing cross-site request forgery as described in Section 10.12. 

要在狀態字段中傳遞的值取決於提出請求的人。 您可以生成一個隨機（或偽隨機）數字。 授權服務器發回的答復將完全填充客戶端發送狀態字段的狀態字段。 然后，您可以將收到的狀態字段與發送的字段匹配，以查看它們是否匹配。

您可以采取的另一步驟是讓客戶端發送帶有令牌請求的重定向URI。 這很有用，以便授權服務器可以驗證請求中的重定向URI是否與它與客戶端ID關聯的重定向URI匹配。 如果您使用的是第三方授權服務器，則應檢查它是否具有此行為。

作為最終的安全建議， 與授權服務器或資源服務器進行通信時 ，請始終與HTTPS一起使用 。

這篇文章很好地解釋了OAuth的不同流程： https : //www.digitalocean.com/community/tutorials/an-introduction-to-oauth-2

Answer 2

We assume, that redirect_uri is an endpoint on our own server.

我相信您在這里混淆了客戶端和資源服務器的角色。 當然，資源服務器（托管API的服務器）永遠不要將令牌返回給移動應用程序（客戶端），因為它首先需要該令牌對客戶端進行身份驗證。

在OAuth2中，客戶端應在與資源服務器進行通信之前從授權服務器獲取令牌。

它可以使用隱式授予或授權代碼授予 。 在后一種情況下，它應在不提供客戶機密的情況下使用授權，因為移動客戶端被視為無法安全存儲機密的公共客戶端。