当redirect_uri不适用时，是否有一个OpenID Connect授权类型或机制供应用程序轮询auth-code？(Is there an OpenID Connect grant type or mechanism for an app to poll for the auth-code when redirect_uri doesn't apply?)

 如果您有设备上的应用程序（例如桌面程序，移动设备应用程序），您可以使用OpenID Connect一些警告： 
 
 使用资源所有者凭据（ grant_type: password ）是最简单的，但如果认证服务器操作员由于信任原因不允许您使用该授权类型（即他们不希望您收集用户的用户名+），则可能无法使用自己密码） - 或者如果他们有一个很难在本机应用程序中复制的动态或自定义身份验证UI。 
 
 通过交互式流（隐式，混合），身份验证服务器的身份验证页面显示在应用程序内的Web视图中。 大多数用户不知道应用程序可以窥探身份验证页面并捕获他们的用户名和密码，尤其是在移动设备上 - 但这样，应用程序代码可以轻松捕获授权代码和/或访问令牌，并自动关闭Web - 没有任何额外的用户交互。 （我很惊讶我没有听说过恶意应用程序以这种方式捕获更多用户详细信息的情况。） 
 
 ...所以建议总是使用系统的Web浏览器打开身份验证页面，但是在Windows桌面上没有好的标准方法让系统Web浏览器将服务器响应返回给应用程序代码，尽管那里目前正在使用的方法有很多种： 
 
 
 
 身份验证成功页面指示用户将一小段文本（包含授权代码或access_token响应）复制并粘贴回桌面应用程序。 
 
 
 根据上面的注释，在应用托管的Web视图中显示该页面。 
 
 
 如果身份验证过程始终只需要用户名和密码（例如），应用程序仍然可以使用自己的UI捕获用户的用户名和密码，然后创建自己的HTTP请求，使其看起来像用户的Web浏览器会话，并获取授权代码和/或access_token那种方式。 
 
 
 仅在Windows上： 
  
 
   
 有一个小的实用程序authHelper.exe ，在调用时会将其命令行参数转发到用户会话中的命名管道。 
 
   
 主客户端应用程序将authHelper.exe注册为每用户HKCU\Software\Classes键中的临时URI方案处理程序，例如my-application:这样任何my-application: URI的内容都作为参数传递给authHelper.exe 。 
 
   
 传递给系统Web浏览器以打开身份验证页面的URI将redirect_uri参数设置为my-application:因此在用户在浏览器中进行身份验证后，浏览器将请求由Windows处理的自定义URI方案，该方案将调用authHelper.exe "access_token=..."然后将命名管道中的数据发送到正在运行的应用程序。 
 
   
 如果用户没有权限写入他们自己的HKCU\Software\Classes键，或者他们使用的Windows版本不支持具有EXE注册的自定义URI方案处理程序，那么这不起作用。 
 
  
 
 
 Windows UWP应用程序也可以使用Web身份验证代理。 
 
 
 我想知道是否可以使用不同的方法：为什么应用程序不能简单地轮询身份验证服务器以获取身份验证尝试的状态？ 或者这种方法是否已经存在，如果是，那么流程或授权的名称是什么？ 
 
 这是我提出的流程： 
 
 
 
 当用户想要进行身份验证时，应用程序将像以前一样打开系统Web浏览器，但使用应用程序提供的一次性使用不透明ID的另一个参数。 
 
 
 一旦系统浏览器打开，应用程序就会使用自己的HTTP客户端每500毫秒左右（即一个轮询循环）向身份验证服务器发出请求，该客户端会询问与之前相同的不透明ID关联的活动身份验证尝试的状态。 。 
 
 
 从身份验证服务器到应用程序的初始几个响应可能是status: pending ，但最终在用户在超时窗口内成功进行身份验证之后，应用程序的轮询请求将指示成功尝试，并且还包含适用的access_token或授权代码。 如果用户未能进行身份验证（例如3次错误尝试）或者窗口打开时间过长导致超时，则轮询响应将指示失败。 
 
 
 这已经存在并且有名字吗？ 这种方法是否存在潜在的安全风险或漏洞？ 

If you have an on-device application (e.g. 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 (i.e. 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, e.g. 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:
 
 
 
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.
 
 
As soon as the system browser is open, the application makes requests every 500ms or so (i.e. 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.
 
 
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 (e.g. 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?

原文：https://stackoverflow.com/questions/51461295