当redirect_uri不适用时，是否有一个OpenID Connect授权类型或机制供应用程序轮询auth-code？

Question

If you have an on-device application (eg desktop program, mobile device app) you can use OpenID Connect with some caveats:

Using Resource Owner Credentials ( grant_type: password ) is the simplest, but might not be possible if the authentication server operator won't let you use that grant-type because of trust reasons (ie they don't want you collecting the user's username+password yourself) - or if they have a dynamic or custom authentication UI that would be hard to replicate in a native app.

With the interactive flows (implicit, hybrid) the authentication sever's authentication page is shown in an in-app web-view. Most users will have no idea that the application can snoop on the authentication page and capture their username and password, especially on mobile devices - but this way the application code can easily capture the authorization code and/or access token, and automatically dismiss the web-view without any additional user interaction. (I'm surprised I haven't heard of more cases of users' details being captured by malicious apps this way.)

...so the advice is to always open the authentication page using the system's web-browser, but on the Windows desktop there is no good, standard way for the system web-browser to return the server response to the application code, though there are a number of approaches currently in use:

• The authentication success page instructs the user to copy and paste a blob of text (containing the authorization code or access_token response) back into the desktop application.
• Show the page in an app-hosted web-view, as per the notes above.
• If the authentication process always only needs a username and password (for example) the application could still capture the user's username and password with its own UI and then make its own HTTP requests to make it seem like a user's web-browser session, and get the authorization code and/or access_token that way.
• On Windows only:
  • Have a small utility program authHelper.exe that when invoked forwards its command-line arguments to a named-pipe in the user's session.
  • The main client-application will register authHelper.exe as a temporary URI scheme handler in the per-user HKCU\\Software\\Classes key, eg my-application: such that the contents of any my-application: URI are passed as arguments into authHelper.exe .
  • The URI passed to the system web-browser to open the authentication page has the redirect_uri parameter set to my-application: , so after the user authenticates in the browser, the browser will request the custom URI scheme which is handled by Windows, which invokes authHelper.exe "access_token=..." which then sends the data down the named-pipe to the running application.
  • If the user doesn't have permission to write to their own HKCU\\Software\\Classes key, or if they're using a version of Windows that doesn't support custom URI scheme handlers with EXE registrations then this doesn't work.
• Windows UWP applications can also use the Web Authentication Broker.

I was wondering if a different approach could be used: why can't the application simply poll the authentication server for the status of the authentication attempt? Or does this approach already exist, and if so, what is the name of the flow or grant?

Here's the flow I'm proposing:

1. When the user wants to authenticate, the application opens the system web-browser as before, but with another parameter for a one-time-use opaque ID provided by the application.
2. As soon as the system browser is open, the application makes requests every 500ms or so (ie a polling loop) to the authentication server using its own HTTP client that asks for the status of the active authentication attempt associated with the same opaque ID as before.
3. The initial few responses from the authentication server to the application will presumably be status: pending , but eventually after the user successfully authenticates within a timeout window then the application's poll request would indicate a successful attempt and also contains the access_token or authorization code as is applicable. If the user failed to authenticate (eg 3 incorrect attempts) or left the window open long enough causing a timeout then the poll response would indicate failure.

Does this already exist and does it have a name? Are there any potential security risks or vulnerabilities with this approach?

Answer 1

It exists and has a name, "OAuth 2.0 Device Flow for Browserless and Input Constrained Devices", but is not yet fully standardized, see: https://tools.ietf.org/html/draft-ietf-oauth-device-flow

Google also implemented this flow avant-la-lettre in a vendor-specific way: https://developers.google.com/identity/protocols/OAuth2ForDevices