我们的应用程序有一个OIDC提供程序，对于用户，我们使用标准的OAuth重定向流程，因为用户授权和身份验证在同一台设备上执行。但是，现在我们的应用程序中有移动用户，我们希望将身份验证扩展到应用程序。
我一直在寻找一个OIDC CIBA流程，不确定它是否适合我们，我想确定一下。
在OIDC的验证/认证阶段，我们通常会显示一个登录屏幕。但是，我认为对于移动的用例，我们可以只显示一个“轮询”屏幕，以指示已经发出了反向通道请求。
由于我们有设备令牌（通过之前某个点的配对阶段）我们可以向手机发送推送通知，并要求用户批准请求。使用mTLS加密，我可以确保与设备的安全连接。轮询屏幕将通过UUID轮询API以获得结果（移动的设备在批准后会进行一次成功的API调用），一旦有了结果，就会将用户重定向回OIDC重定向流程。
这意味着我们不需要引入CIBA，只需有一个新的验证屏幕，该屏幕将执行异步工作，然后在完成后重定向。
1条答案
按热度按时间kcrjzv8t1#
这里可能有几个你提到的用例，对于每一个用例，我都希望遵循最标准的解决方案，在应用程序中使用最简单的代码和最好的可扩展性选项。
在桌面上登录Web应用程序
有时在桌面浏览器中登录会涉及移动的设备，例如，如果我在桌面浏览器中登录gmail，我会被提示确认是我在移动设备上。这会触发对谷歌API的调用，同时登录屏幕会轮询相同的API，以检测是否完成。
移动的应用程序登录
将流程扩展到移动的端也是一样的。Gmail使用RFC8252中的AppAuth模式让我登录，然后显示相同的提示以确认是我。在这种情况下，不需要切换设备。当然，移动端登录不依赖于用户是否可以访问桌面，因此身份验证在移动端也是有效的。
代码流
以上两种都使用code flow，具有多因素身份验证。（用户知道的东西），
Polling Authenticator是第二个因素（要求用户拥有设备的所有权）。一旦您使用了代码流，您的应用程序支持many ways to authenticate，并且可以更改身份验证工作流，而无需在授权服务器上进行更改，而无需更改任何应用程序代码。移动的因素
这里有几种不同的类型：
*基于时间的一次性密码（TOTP）：Google身份验证器等应用程序会要求用户输入一个6位数字，该数字在设备和授权服务器上的计算结果相同。
*轮询：登录屏幕轮询授权服务器，后者又轮询外部系统，以查看用户登录是否已完成，如上面的gmail示例所示。
*应用程序对应用程序：在某些情况下，主要身份验证因素可以是外部应用程序。此类解决方案也可通过代码流实现，如app2app article中所述。
汽巴
这是一个不同的用例，通常在用户A需要临时访问用户B的一些资源时使用。典型的用例是呼叫中心接线员需要代表用户行事。呼叫中心应用程序随后触发一个流程，提示远程用户登录。请参见this tutorial and video示例。它确实提供了一些有趣的可能性。例如通过推送通知来递送令牌。
摘要
通过让用户在桌面上提供
something they know来实现移动的登录，然后发送推送通知，感觉过于复杂和非标准。它可能也会对移动架构起作用，例如，如果用户在火车上，则阻止登录。我倾向于AppAuth模式，并通过让用户在设备上提供
something they know，以标准方式实现移动的登录。这可能提供最安全的行为，也是最好的全面架构。如果你有特殊原因想要做不同的事情，你应该更新你的问题来解释为什么。