如何通过 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. 用户需要带有浏览器的辅助设备。