简单的说
我们希望强制执行 FIDO-only 以实现抗网络钓鱼身份验证，而不会出现降级攻击。但是遗留应用程序中的许多 WebView 不支持 WebAuthn。
用例：即使您的用户使用包含过时 WebView 的移动应用程序或桌面应用程序来呈现身份验证流程，如何强制执行 FIDO-only？
我们称之为 “分离式 FIDO 身份验证”：
- 提供跳出使用过时 WebView（不支持 WebAuthn）的应用程序进入操作系统标准浏览器的选项。
- 让用户在操作系统标准浏览器中执行 FIDO 认证（现代浏览器支持 WebAuthn）
- 让用户导航回应用程序的过时 WebView
- 如果流程的所有步骤都来自同一设备，则用户已通过应用程序的身份验证
这是一种解决方法，直到与我们相关的所有应用程序都集成了 WebAuthn 支持。解决方法不像直接从应用程序中使用 WebAuthn 那样用户友好，但比回退到非网络钓鱼抵抗 MFA 方法（如 SMS、Push & Co.）的替代选项更安全。
具体需求
背景
在Authenticate 2022 会议上的演讲中，我们介绍了我们如何在一家全球科技公司实施 FIDO 的历程。它是关于引入 FIDO2 标准，该标准可以选择强制执行带有身份验证的 FIDO 身份验证器注册以及随后的 FIDO2-only 身份验证。我们提到我们消除了实施仅 FIDO 身份验证的主要障碍。但是我们没有详细解释这个机制。让我们研究一下。
挑战
FIDO 2.0 是一个身份验证框架。该框架的一部分是 Web 身份验证 API (WebAuthn)。这个 API 由大多数流行的现代浏览器实现。FIDO 身份验证的一个重要且与众不同的特征是网络钓鱼抵抗。如果 WebAuthn API 由浏览器实现，则可以使用它。
FIDO 身份验证流程可以由身份提供者 (IDP) 为连接的应用程序提供。IDP 通常会提供不同的身份验证方法。如果 IDP 为用户提供了在身份验证机制（例如 FIDO、SMS OTP、推送通知等）之间进行选择的机会，则用户很容易受到网络钓鱼攻击。如果 IDP 强制执行仅 FIDO 身份验证，则可以避免这种情况。
如果 IDP 仅强制执行 FIDO，则用户必须使用实现 WebAuthn API 的浏览器。如果正在使用的应用程序是可以使用现代浏览器打开的常规 Web 应用程序，那很可能没有问题。用户只需选择支持 WebAuthn 的浏览器即可。
移动应用程序和桌面应用程序也可以通过 IDP 进行身份验证。这通常是通过嵌入式 WebView 完成的。WebView 集成到应用程序中，用户无法更换。如果应用程序使用不支持 WebAuthn 的遗留 WebView，则用户无法直接使用 FIDO 进行身份验证。如果 IDP 仅强制执行 FIDO，则用户无法使用该应用程序。
解决方式
如果应用程序不支持 WebAuthn，则会触发 “分离的 FIDO 身份验证”，因为它使用过时 WebViews 进行基于 Web 的身份验证流程。
通过 “分离的 FIDO 身份验证” 流程，可以 “跳出” 与 WebAuthn 不兼容的 WebView 并启动操作系统标准浏览器的实例。操作系统标准浏览器能够呈现 FIDO 身份验证流程并执行它，因为操作系统标准浏览器具有 WebAuthn 支持。“Detached FIDO Authentication” 流程要求一个指示器，表明来自与 WebAuthn 不兼容的 WebView 和 OS 标准浏览器的所有步骤都来自同一设备。这种 “同一设备” 检查可防止网络钓鱼过程中与 WebAuthn 不兼容的 WebView 部分。在操作系统标准浏览器内执行 FIDO 身份验证后，用户导航回应用程序并通过身份验证。
流程图：
实现步骤
如何从 WebView 启动标准浏览器
没有方便的 “一刀切” 解决方案可以跳出应用程序的遗留 WebView 进入操作系统标准浏览器。因此，应使用基于 JavaScript 的客户端指纹识别来确定最适合 “跳出” 技术的方法，该技术适用于正在使用的设备/应用程序/WebView。
为保证可以使用分离式 FIDO 身份验证，还必须实施稳健的回退解决方案。后备解决方案很可能对用户来说不太方便，但在任何地方都适用：只需在与文本相同的设备上的操作系统标准浏览器中显示要打开的链接。当然，这需要得到很好的描述，然后用户可以手动复制文本并在浏览器中打开链接。一种选择是将 JavaScript 共享和复制方法公开为链接文本旁边的按钮。
这里有几个方便的 “跳出” 机制的例子，一旦知道设备细节就可以执行这些机制。
在 Windows 上：
<a href=”microsoft-edge:https://example.com” target=”_blank”>Open</a>
在安卓上：
<a href="intent://example.com#Intent;scheme=https;action=android.intent.action.VIEW;end">Open</a>
在 iOS 上：
<a href=”https://example.com” target=”_blank”>Open</a>
<a href=”googlechrome://example.com”>Open</a>
<a href=”shortcuts://run-shortcut?name=OpenUrl&input=text&text=example.com”>Open</a>
免责声明：这些方法尚未在所有应用程序和设备上进行测试，但作为已证明在我们的部署中有用的技术示例😊。
验证流程的所有步骤是否源自同一设备
分离式 FIDO 身份验证方法使用两个松散耦合的通道来实现登录。第一个通道是应用程序使用的过时 WebView（不支持 WebAuthn），第二个通道是操作系统标准浏览器（支持 WebAuthn）。为了限制将受害者诱骗到应用程序（第一个通道）并因此控制过时 WebView 的攻击者提供 FIDO 身份验证（第二个通道）的机会，最好尝试确保两者频道来自同一台设备。
这种验证的一种简单方法是存储流程每个步骤的 IP 地址，并验证来自两个通道的 IP 地址是否相等。
免责声明：在某些边缘情况下，网络钓鱼代理服务器可能与执行 FIDO 身份验证的浏览器具有相同的 IP 地址（例如，无论出于何种原因，两者都在同一 NAT 之后，即 WLAN）
缓解 NAT 问题的方法可能是针对对您的 IDP 的特定请求强制执行 ipv6 连接，从而利用 Internet 上的设备被分配了唯一 IP 地址用于标识和位置定义的好处。
NAT 问题的另一个潜在缓解措施可能是您首先在设备上使用支持 fido 的 VPN 应用程序建立企业 VPN 连接。
无论如何，即使是简单的基于 IP 地址的关联也可以通过防止远程、分布式网络钓鱼活动来提供显着的好处。
如何防止验证攻击者的会话
我们如何防止攻击者说服受害者对攻击者的会话执行 FIDO 身份验证？我们还可以验证来自两个通道的 IP 地址是否相等。为了缓解攻击者在某些边缘情况下可能拥有相同 IP 地址的问题，我们可以使用 WebRTC 通过创建对等连接并验证连接的端点位于本地主机上来确保两个呈现的网站位于同一设备上。
设置和检查身份验证状态
分离式 FIDO 身份验证生成一个私有令牌和一个公共令牌。打开 OS 标准浏览器时，公共令牌作为查询参数与 url 一起传递。在操作系统标准浏览器中成功进行 FIDO 身份验证后，公共令牌用于将身份验证状态设置为成功。私有令牌在遗留 WebView 内部使用，以检查身份验证状态是否成功。这种检查可以通过例如轮询、WebSockets 或服务器发送的事件来实现。
仅在必要时激活它
将 “分离的 FIDO 身份验证” 流的使用限制为仅用于使用过时 WebView 的已连接应用程序是个好主意，因此需要此流。
在 SAML 和 OIDC 身份验证流程中，IDP 知道哪个应用程序想要对用户进行身份验证。因此 IDP 可以在应用程序实体上提供一个配置选项，启用或禁用 “分离的 FIDO 身份验证”。
如果应用程序实体是纯 Web 应用程序，没有移动应用程序或桌面应用程序，则很可能不需要 “Detached FIDO Authentication”。如果应用程序 webview 已经支持 WebAuthn，那么 “Detached FIDO Authentication” 也不是必需的。因此，只为真正需要它的应用程序细粒度地激活 “分离的 FIDO 身份验证” 是有意义的。
概括
可以肯定的是，“分离式 FIDO 身份验证” 不如浏览器本身的 WebAuthn 安全和用户友好，但是，从我们的角度来看，它比退回到传统的、可钓鱼的 MFA 更好。
将传统的 MFA 作为用户的一个选项仍然存在意味着用户容易受到降级攻击并且仍然可以被钓鱼。
当今市场上有许多使用本身不支持 WebAuthn 的 WebView 的流行应用程序。我们无法确定供应商是否以及何时会使用兼容 WebAuthn 的用户代理升级他们的应用程序，我们也不能无限期地等待供应商推出 FIDO2 支持。
独立于应用程序准备情况，我们现在可以通过使用 “分离的 FIDO 身份验证” 开始实施仅 FIDO 身份验证。它仍然是一种解决方法，但可能会一直存在，直到与我们相关的所有应用程序都集成了 WebAuthn 支持！
来自：https://denniskniep.github.io/posts/01-detached-fido-authentication/