应用错误收集

如果您拥有设备上的应用程序（例如桌面程序，移动设备应用程序），则可以使用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:，因此在用户在浏览器中进行身份验证之后，浏览器将请求自定义URI方案由Windows处理，Windows调用authHelper.exe "access_token=..."，然后将数据沿命名管道发送到正在运行的应用程序。
- 如果用户无权写入自己的HKCU\Software\Classes键，或者使用的Windows版本不支持带有EXE注册的自定义URI方案处理程序，则此操作不工作。
Windows UWP应用程序也可以使用Web身份验证代理。

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

这是我建议的流程：

当用户想要进行身份验证时，应用程序将像以前一样打开系统Web浏览器，但使用另一个参数来表示应用程序提供的一次性使用的不透明ID。
一旦打开系统浏览器，应用程序就会使用自己的HTTP客户端每500毫秒左右（即轮询循环）向身份验证服务器发出请求，该客户端请求与同一不透明关联的活动身份验证尝试的状态以前的ID。
从身份验证服务器到应用程序的最初几个响应大概是status: pending，但是最终在用户在超时窗口内成功进行身份验证之后，应用程序的轮询请求将表明尝试成功，并且还包含{{ 1}}或授权代码（如适用）。如果用户验证失败（例如3次不正确的尝试）或将窗口打开足够长时间而导致超时，则轮询响应将指示失败。

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

当redirect_uri不适用时，应用是否有OpenID Connect授予类型或机制可以让应用轮询授权代码？

1 个答案: