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:
access_token
response) back into the desktop application. access_token
that way. authHelper.exe
that when invoked forwards its command-line arguments to a named-pipe in the user's session. 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
. 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. 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. 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:
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?
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
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.