对于已有网页或应用程序的开发人员来说，如果希望实施 FIDO 身份验证，则必须对应用程序进行两处修改： 1) 修改贵机构网站或移动应用程序的登录和注册页面，以便使用FIDO协议；以及 2) 设置 FIDO 服务器，以验证任何 FIDO 注册或验证请求。 接下来的两节将简要介绍这两项变更所应采取的步骤。
修改注册和登录
如果您的应用程序已经具备注册和登录账户的功能，那么添加 FIDO 身份验证功能就像修改注册和登录屏幕一样简单。
首先要做出的设计决定是使用 FIDO 进行第一要素身份验证（无密码）还是第二要素身份验证。 做出这一决定需要考虑的因素太多（易用性、平台可用性、应用类型、风险承受能力等），这里就不一一讨论了，但好消息是，无论使用 FIDO 作为第一要素还是第二要素，其实施方法看起来都大致相同。
注册
将 FIDO 与您的注册网页整合，只需调用正确的注册 API 调用即可。 每种 FIDO 规范的注册电话是
- uaf: uaf_operation (
iOS
,
安卓
) – UAF 客户端 API 规范定义了一个安卓 Intent 和 iOS x-callback 方案（分别），其操作类型为 UAF_OPERATION，其中 UAF_OPERATION 的第一个参数告诉验证器要执行注册。 - U2F：
注册()
– U2F 规范定义了在浏览器中执行注册的 JavaScript API。 - FIDO2 / WebAuthn：
navigator.credentials.create()
– WebAuthn 规范（FIDO2 项目的一部分）定义了一个 navigator.credentials.create() API，用于在浏览器中创建新凭证（又称注册）。
每个 API 调用都要求您的应用程序从服务器获取一个挑战（大随机数），并将其传递给相应的 API 调用。 服务器将确保发送到验证器的验证信息与接收到的信息一致，因此您的应用程序可能需要某种会话管理（如 cookie）来跟踪验证信息和用户名/用户账户。 在进行 API 调用后，API 调用产生的 JSON 消息将被发回服务器（通常是通过服务器定义的 REST 端点），服务器将验证注册消息的挑战、签名、来源和其他关键安全特征。 每个 FIDO 规范都对服务器为验证信息而必须执行的验证进行了说明：
- UAF：UAF 协议规范定义了服务器处理和验证注册请求的方式
注册请求
和
验证（又称登录）请求的方式
- U2F：
服务器验证在
在 U2F JavaScript API 规范中定义 - FIDO2 / WebAuthn：WebAuthn 规范
规定了
依赖方/服务器在接收注册或登录请求时应执行的所有步骤。
服务器将根据注册成功或失败给出成功或失败的回复。
值得一提的是，每个用户的账户都可能注册了多个身份验证器，因此要确保用户体验流程允许用户添加多个身份验证器，为它们命名以示区分，并删除身份验证器（例如，如果身份验证器丢失或被盗）。
登录
使用 FIDO 登录与注册非常相似。 就像每个 FIDO 规范都有一个注册调用一样，也有一个类似的登录 API：
- uaf: uaf_operation (
iOS
,
安卓
) – UAF 客户端 API 规范定义了一个安卓 Intent 和 iOS x-callback 方案（分别），其操作类型为 UAF_OPERATION，其中 UAF_OPERATION 的第一个参数告诉验证器执行登录。 - U2F：
sign()
– U2F 规范定义了在浏览器中签署断言（又称登录）的 JavaScript API。 - WebAuthn：
navigator.credentials.get()
– WebAuthn 规范定义了一个 navigator.credentials.get() API，用于通过浏览器使用凭证（又称登录）。
同样，与注册调用类似，登录 API 调用也需要来自服务器的挑战。 根据应用程序接口的不同，它可能还需要其他信息–例如，WebAuthn 可能需要以前注册账户的 “凭证 ID”。 前面提到需要某种会话管理，这里也同样适用，API 流程的其余部分与注册基本相同：向 API 调用传递挑战、向服务器返回 JSON 并等待服务器的成功/失败响应。
添加 FIDO 服务器
将 FIDO 服务器与现有身份验证流程集成的方法太多了，这里无法一一详述。 例如，FIDO 服务器可以与网络或应用服务器集成，可以作为现有 IAM 框架中的一个模块提供，也可以是一个独立的服务器，或者对于非常广泛和复杂的服务来说，可以是上述几种方式的任意组合。 此外，FIDO 还可与特定于应用程序的用户数据存储（如 MySQL 或 Mongo 数据库）、LDAP/ActiveDirectory 集成，通过 OpenID Connect (OIDC) 身份提供程序 (IDP) 提供 SSO 等。 由于后端身份验证架构和使用案例多种多样，因此很难谈及 FIDO 服务器集成的所有细节，以下是 FIDO 服务器部署的一般提示和注意事项。 具体的服务器供应商及其文档应提供更多信息，说明如何将 FIDO 集成到任何已有的 IAM 环境中。
除了为服务器设置硬件和软件外，还有几个步骤在大多数服务器部署中都是通用的：
- 服务器通常使用 REST 端点与客户端通信。 这需要正确的防火墙配置，以便与客户进行通信。 如前所述，这些端点可以是现有应用（如网络服务器或移动应用服务器）的一部分，也可以使用微服务架构或 ESB 将信息路由到独立的 FIDO 服务器。
- 服务器需要 https 通信，因此需要有效的 https TLS 证书（或在前面加上 TLS 终结符）。
- 服务器可能有用于确定何时允许注册和身份验证的策略配置。 对于金融或政府机构来说，这可能包括使用FIDO元数据服务（MDS）来验证正在访问服务的验证器的安全性。
- 服务器需要与某种形式的用户数据存储（LDAP、ActiveDirectory、MySQL、MongoDB 等）集成。 对于新服务来说，这只是一个将某种存储与每个用户的账户相关联的问题。 对于现有的应用程序，这将需要修改数据模式–通常是在用户账户和他们将注册的验证器/凭证之间添加某种形式的一对多关系。
有关 FIDO 服务器架构和配置的其他帮助论坛，请访问 这里 [链接到社区资源页面].
