如何通過 OAuth Resource Owner Password Credentials Grant 使用多因素身份驗證？

Question

為什么要授予資源所有者密碼憑據？

您幾乎肯定不需要資源所有者密碼憑據授予 (ROPC)。 為什么我想要？

我正在使用無瀏覽器的設備。 該設備是資源服務器並使用授權服務器。 在這個用例中（我說這個用例是因為設備還支持其他訪問方法），設備代理用戶的憑據並從授權服務器請求令牌（用於訪問自身的令牌）。 因此，設備代理身份驗證和授權的憑據。 它本質上說，“我是設備 A。這是用戶 B 的憑據。請給我一個令牌，允許設備 A 代表用戶 B 訪問設備 A。”

同樣，該設備沒有瀏覽器。 基於Scott Brady 的不要使用 OAuth 文章，這是關於資源所有者密碼憑據授予 (RFC 6749 § 4.3) 是合理選擇的唯一應用程序。

但我想使用多因素身份驗證。

RFC 6749 和文檔都不支持發送第二個因素。 Scott Brady 的那篇文章稱，故意不支持多因素身份驗證。

所以：

1. ROPC 有意義的一個用例是否一定意味着多因素身份驗證是一個壞主意或無用？ 或者
2. 這是標准故意忽略以阻止人們濫用 ROPC 的有效用例嗎？ 或者
3. 這是一個完全超出標准范圍的有效用例嗎？

我基本上是問，在這種情況下是否建議不符合標准，或者這種情況是否意味着我已經做錯了什么？

多因素要求

為了清楚我的想法，這種情況需要兩個附加功能：

1. 一種向授權端點發送“第二個因素”的方法。
2. 授權端點響應表示需要多因素身份驗證的正常請求的一種方式。

我的非標准計划是：

1. 向 ROPC 添加自定義參數（例如“second_factor”）。
2. 在錯誤響應中使用特殊的“錯誤”參數來表示需要第二個因素。

對於錯誤響應，我遇到了“interaction_required”。 我發現了一個示例，其中這似乎與多因素身份驗證相關，但以不同的方式使用。

標記為 identityserver4 因為如果沒有標准，我也對相關的最佳實踐感興趣。

我發現了這個相關的問題，但它涉及不同的流程。

Answer 1

在OAuth 2.0 Device Flow for Browserless and Input Constrained Devices規范之前，您可能需要 ROPC。 但現在你沒有。 RFC（仍在草案中）正是針對這種情況制定的。

設備不是處理用戶密碼，而是聯系授權服務器並獲取最終用戶代碼。 用戶使用此代碼登錄授權服務器並對設備進行授權。

圖 1 來自 RFC (v. 07) 草案：

  +----------+                                +----------------+
  |          |>---(A)-- Client Identifier --->|                |
  |          |                                |                |
  |          |<---(B)-- Verification Code, --<|                |
  |          |              User Code,        |                |
  |          |         & Verification URI     |                |
  |  Device  |                                |                |
  |  Client  |         Client Identifier &    |                |
  |          |>---(E)-- Verification Code --->|                |
  |          |    polling...                  |                |
  |          |>---(E)-- Verification Code --->|                |
  |          |                                |  Authorization |
  |          |<---(F)-- Access Token --------<|     Server     |
  +----------+  (w/ Optional Refresh Token)   |                |
        v                                     |                |
        :                                     |                |
       (C) User Code & Verification URI       |                |
        :                                     |                |
        v                                     |                |
  +----------+                                |                |
  | End-user |                                |                |
  |    at    |<---(D)-- User authenticates -->|                |
  |  Browser |                                |                |
  +----------+                                +----------------+

                      Figure 1: Device Flow.

幾個明顯的區別：

1. 更安全：設備不處理憑據。 濫用或利用設備漏洞的空間較小。
2. 在“輸入受限”設備上更容易，因為不需要在設備上輸入任何內容。
3. 用戶需要帶有瀏覽器的輔助設備。