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

Question

如果您有设备上的应用程序（例如桌面程序，移动设备应用程序），您可以使用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身份验证代理。

我想知道是否可以使用不同的方法：为什么应用程序不能简单地轮询身份验证服务器以获取身份验证尝试的状态？ 或者这种方法是否已经存在，如果是，流程或授权的名称是什么？

这是我提出的流程：

1. 当用户想要进行身份验证时，应用程序将像以前一样打开系统Web浏览器，但使用应用程序提供的一次性使用不透明ID的另一个参数。
2. 一旦系统浏览器打开，应用程序就会使用自己的HTTP客户端向验证服务器发出大约500ms左右的请求（即轮询循环），该客户端要求与之前相同的不透明ID关联的活动验证尝试的状态。
3. 从身份验证服务器到应用程序的初始几个响应可能是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