如何使用OAuth资源所有者密码凭据授予多因素身份验证？

Question

为什么资源所有者密码凭据授予？

您几乎肯定不需要资源所有者密码凭据授权（ROPC）。我为什么要这样做？

我正在使用无浏览器设备。该设备是资源服务器并使用授权服务器。在此用例中（我说此用例因为设备还支持其他访问方法），设备代理用户的凭据并从授权服务器请求令牌（令牌自己访问）。因此，设备代理认证和授权的凭证。它基本上说，“我是设备A.这是用户B的凭据。请给我一个令牌，允许设备A代表用户B访问设备A.”

同样，该设备没有浏览器。基于Scott Brady's don't ever use OAuth article，这是关于资源所有者密码凭证授权（RFC6749§4.3）是合理选择的唯一应用程序。

但我想使用多因素身份验证。

RFC 6749和the documentation都不支持发送第二个因素。 that Scott Brady article表示故意不支持多因素身份验证。

所以：

1. ROPC有意义的一个用例是否必然意味着多因素身份验证是一个坏主意或无用的？或
2. 这是一个有效的用例，标准是故意忽略以阻止人们滥用ROPC吗？或
3. 这是一个有效的用例，仅仅超出了标准的范围吗？

我基本上都在问，是否建议在这种情况下不合标准，或者这种情况是否意味着我已经做了其他错误了？

多因素要求

要清楚我的想法，这种情况需要两位额外的功能：

1. 向授权端点发送“第二个因素”的方法。
2. 授权端点响应正常请求的方式，该请求表示需要进行多因素身份验证。

我的非标准计划是：

1. 将自定义参数添加到ROPC（例如“second_factor”）。
2. 在错误响应中使用特殊的“错误”参数来表示需要第二个因素。

对于错误响应，我遇到了“interaction_required”。我发现one example这似乎与多因素身份验证有关，但方式不同。

标记为identityserver4，因为如果没有标准的话，我也对相关的最佳实践感兴趣。

我找到this related question，但它涉及不同的流程。

Answer 1

在OAuth 2.0 Device Flow for Browserless and Input Constrained Devices规范之前，您可能需要ROPC。但是现在你没有。 RFC（仍在草案中）是针对这种情况而制定的。

设备与授权服务器联系并获取最终用户代码，而不是设备处理用户的密码。用户使用此代码登录授权服务器并授权设备。

RFC草案（v.07）中的图1：

  +----------+                                +----------------+
  |          |>---(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. 用户需要带浏览器的辅助设备。