如何通过 OAuth Resource Owner Password Credentials Grant 使用多因素身份验证？

Question

Why the Resource Owner Password Credentials Grant?

You almost certainly don't need the Resource Owner Password Credentials Grant (ROPC). Why do I want to?

I am working on a browserless device. The device is the Resource Server and uses an Authorization Server. In this use case (I say this use case because the device also supports other access methods), the device proxies credentials for the user and requests a token (a token to access itself) from the Authorization Server. Thus, the device proxies credentials for both authentication and authorization. It essentially says, "I am Device A. Here are User B's credentials. Please give me a token that allows Device A to access Device A on User B's behalf."

Again, the device has no browser. Based on Scott Brady's don't ever use OAuth article , this is about the only application for which the Resource Owner Password Credentials Grant (RFC 6749 § 4.3) is be a reasonable choice.

But I want to use multifactor authentication.

Neither RFC 6749 nor the documentation support sending a second factor. And that Scott Brady article says multifactor authentication is deliberately not supported.

So:

1. Does the one use case where ROPC makes sense necessarily imply that multifactor authentication is a bad idea or useless? Or
2. Is this a valid use case that the standard deliberately ignores to discourage people from abusing ROPC? Or
3. Is this a valid use case that is simply out of scope of the standard?

I'm basically asking, is it recommended to go off-standard in this case, or does this case mean I did something else wrong already?

Multifactor Requirements

To be clear on what I have in mind, this case requires two bits of added functionality:

1. A way to send a "second factor" to the Authorization endpoint.
2. A way for the Authorization endpoint to respond to a normal request saying that multifactor authentication is required.

My non-standard plan is to:

1. Add a custom parameter to the ROPC (eg "second_factor").
2. Use a special "error" parameter in the error response to signal that a second factor is needed.

For the error response, I came upon "interaction_required". I found one example where this seems to be used in relation to multifactor authentication, but in a different way.

Tagged with identityserver4 because I'm also interested in relevant best practices if there is nothing standard.

I found this related question but it concerns a different flow.

Answer 1

Prior to the OAuth 2.0 Device Flow for Browserless and Input Constrained Devices spec, you may have needed ROPC. But now you don't. The RFC (still in draft) is made for exactly this situation.

Instead of the Device handling the user's password, the Device contacts the Authorization Server and gets an end-user code. The user uses this code to log in to the Authorization Server and authorize the Device.

Figure 1 from the Draft 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.

A few obvious differences:

1. More secure: Device does not handle credentials. Less room for abuse or exploitation of Device vulnerabilities.
2. Easier on "Input Constrained" Devices since nothing needs to be entered on the Device.
3. User needs a secondary device with a browser.