oauth - 当redirect_uri不适用时，应用程序是否有OpenID Connect授予类型或机制可以轮询应用程序的身份验证代码？

Question

如果您拥有设备上的应用程序（例如桌面程序，移动设备应用程序），则可以使用OpenID Connect并注意以下几点：

使用资源所有者凭证（grant_type: password）是最简单的方法，但是如果由于信任原因（例如，他们不希望您收集用户的用户名+），身份验证服务器操作员不允许您使用该授予类型，则可能无法使用您自己输入密码）-或者它们具有动态或自定义的身份验证用户界面，而该用户界面很难在本机应用中复制。

通过交互流程（隐式，混合），身份验证服务器的身份验证页面显示在应用程序内Web视图中。大多数用户都不知道应用程序可以监听身份验证页面并捕获其用户名和密码，尤其是在移动设备上-但是通过这种方式，应用程序代码可以轻松捕获授权代码和/或访问令牌，并自动关闭网络-view，无需任何其他用户交互。 （令我惊讶的是，我还没有听说过更多情况下这种恶意应用会捕获用户详细信息的情况。）

...因此建议始终使用系统的Web浏览器打开身份验证页面，但是在Windows桌面上，系统Web浏览器没有良好的标准方法来将服务器响应返回给应用程序代码，尽管有当前正在使用的许多方法：


身份验证成功页面指示用户将一小段文本（包含授权码或access_token响应）复制并粘贴回桌面应用程序。
按照上述说明，在应用托管的网络视图中显示页面。
例如，如果身份验证过程始终只需要用户名和密码，则应用程序仍可以使用其自己的UI捕获用户的用户名和密码，然后发出自己的HTTP请求，使其看起来像用户的网络浏览器会话，并获得授权代码和/或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次不正确的尝试）或将窗口打开足够长时间导致超时，则轮询响应将指示失败。


这个已经存在并且有名字吗？这种方法是否存在潜在的安全风险或漏洞？

Answer 1

它存在并且名称为“无浏览器和输入受限设备的OAuth 2.0设备流”，但尚未完全标准化，请参见：https://tools.ietf.org/html/draft-ietf-oauth-device-flow

Google还以特定于供应商的方式实施了此流程avant-la-lettre：
https://developers.google.com/identity/protocols/OAuth2ForDevices