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:
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?
To be clear on what I have in mind, this case requires two bits of added functionality:
My non-standard plan is to:
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.
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:
The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.