How to use multifactor authentication with OAuth Resource Owner Password Credentials Grant?
为什么授予资源所有者密码凭证？
ROPC有意义的一个用例是否必然意味着多因素身份验证是一个坏主意或无用？或者
这是标准故意忽略的有效用例，以阻止人们滥用ROPC吗？或者
这是仅在标准范围之外的有效用例吗？
一种向授权端点发送"第二因素"的方法。
一种授权端点响应普通请求(要求进行多因素身份验证)的方式。
将自定义参数添加到ROPC(例如" second_factor ")。
在错误响应中使用特殊的"错误"参数以表明需要第二个因素。
更安全：设备不处理凭据。滥用或利用设备漏洞的空间较小。
由于不需要在设备上输入任何内容，因此在"输入受限"设备上更容易。
用户需要带有浏览器的辅助设备。
您几乎可以肯定不需要"资源所有者密码凭据授予(ROPC)"。为什么要呢？
我正在使用无浏览器的设备。该设备是资源服务器，并使用授权服务器。在这种使用情况下(我说这种使用情况是因为该设备还支持其他访问方法)，该设备代理用户的凭据并从授权服务器请求令牌(用于访问自身的令牌)。因此，设备代理用于认证和授权的凭证。它基本上说："我是设备A。这是用户B的凭据。请给我一个令牌，该令牌允许设备A代表用户B访问设备A。"
同样，该设备没有浏览器。基于Scott Brady的"永远不会使用OAuth"文章，这是关于"资源所有者密码凭据授予(RFC 6749？§4.3)"是唯一合理的选择的应用程序。
但是我想使用多因素身份验证。
RFC 6749和文档均不支持发送第二个因素。斯科特·布雷迪(Scott Brady)的文章说，故意不支持多因素身份验证。
所以：
我基本上是在问，是否建议在这种情况下不符合标准，或者这是否意味着我已经做错了其他事情？
多因素要求
要清楚说明我的想法，这种情况需要增加一些功能：
我的非标准计划是：
对于错误响应，我遇到了" interaction_required"。我找到了一个示例，该示例似乎与多因素身份验证有关，但是以不同的方式使用。
标记为identityserver4，因为如果没有标准，我也会对相关的最佳实践感兴趣。
我发现了这个相关问题，但涉及的流程有所不同。
在适用于"无浏览器和输入受限设备"的OAuth 2.0设备流程规范之前，您可能需要ROPC。但是现在你不知道了。 RFC(仍在草案中)正是针对这种情况。
设备代替设备处理用户密码，而是联系授权服务器并获取最终用户代码。用户使用此代码登录授权服务器并授权设备。
RFC草案(v.07)中的图1：
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 | +----------+ +----------------+ | |>---(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. |
一些明显的区别：