电子邮件地址验证

邮箱验证 API 是一项提案，旨在让浏览器能够直接与邮件服务提供商通信，以验证用户是否拥有该电子邮件地址。用户输入电子邮件地址并提交表单后，网站会使用提供商验证浏览器发送的已签名电子邮件验证令牌，而无需发送电子邮件或中断用户流程。

在注册、登录、结账、订阅简报或账号恢复期间收集电子邮件地址时，网站通常会确认提交表单的人员是否控制该地址。现有的验证方法要求用户离开您的网站，切换应用以查看收件箱，复制一次性密码或点击验证链接。这种中断会增加人工用户和自动代理的流失率和会话放弃率。用户在使用现有验证方法时经常会遇到问题，例如电子邮件延迟、链接过期或代码无法识别。

邮箱验证用户提示演示
邮箱验证用户提示演示

邮箱验证功能可作为对现有流程的渐进增强：

  • 无中断：验证在后台进行，用户 填写表单时不会受到影响。
  • 无需进行功能检测：网站在其表单中添加电子邮件输入和隐藏 令牌输入。如果浏览器或提供商不支持邮箱验证，或者验证失败，网站会回退到其默认的电子邮件确认流程。
  • 最大限度地降低网络钓鱼风险：无需复制任何代码，也不会 将用户发送到虚假网站。

您可以在演示中测试该流程：

  • 颁发者演示：提供模拟电子邮件 账号和登录会话。
  • 验证方演示：验证演示 电子邮件或任何参与提供商电子邮件。

源试用注意事项

源试用是收集反馈的实验，因此，如果您以依赖方或身份提供商的身份参与，您的反馈至关重要。如需报告问题，请使用以下 GitHub 代码库：

如果您在 Chrome 实现中遇到 bug，请在以下组件中提交问题：

您可以通过添加源试用令牌，以每个响应为基础控制源试用功能。这样，您就可以将该功能限制为特定用户群体，例如 A/B 测试群体。或者，如果您有 Beta 版测试或早期预览版用户群组，您可能希望或需要为他们启用该功能。在这种情况下，请先对照提供的电子邮件地址进行检查，然后再颁发或验证令牌。

源试用还具有流量限制，以最大限度地减少网站在发布前对该功能的依赖。颁发者 API 正在开发中，您应该会看到向后不兼容的更改以及 Chrome UX 的更新。

随着开发工作的推进，请关注此处的博客和 evp-announce@chromium.org 邮件列表，了解更多更新。

邮箱验证流程

以下部分介绍了使用邮箱验证 API 时的关键术语和协议步骤。

关键术语

电子邮件验证 API 的关键术语包括：

  • 验证方：收集电子邮件地址并希望验证该地址的网站 。验证方也称为依赖方。
  • 邮件服务提供商：提供用户电子邮件地址的服务，例如 gmail.com。
  • 颁发者：管理用户电子邮件账号的服务，例如 accounts.google.com。颁发者也称为身份 提供商。

在某些情况下，邮件服务提供商和颁发者在同一网域中运行。不过，务必区分两者，因为电子邮件验证 API 使用浏览器中与身份提供商的活跃会话作为验证方法。例如，如需验证 example@gmail.com，用户必须在同一浏览器中使用该账号登录 google.com。

协议流程

邮箱验证流程架构
邮箱验证流程架构
  1. 表单呈现：依赖方提供一个 HTML 表单，其中包含 <input type="email"> 和一个隐藏输入，该输入标有 autocomplete="email-verification-token" 和每个实例唯一的 nonce。
  2. 电子邮件输入：当用户输入电子邮件地址（通过选择 自动填充建议或通过输入或粘贴并退出字段 (blur)）时，浏览器会在后台触发验证。
  3. 发现和会话：浏览器查询 _email-verification.<email-domain>的 DNS TXT 记录，以发现提供商的授权 颁发者来源，然后检查用户是否使用 颁发者的 .well-known/web-identity 配置和 FedCM 账号 端点拥有活跃会话。如果网域未发布 EVP 记录或不存在活跃会话，浏览器会停止验证，而不会提示用户。
  4. 令牌颁发：浏览器从 .well-known/email-verification 中发现提供商的 issuance_endpoint ，创建临时密钥对，并 使用 HTTP 消息签名 (RFC 9421) 发送 HTTP POST 请求，其中包含 颁发者的第一方会话 Cookie 和目标电子邮件地址，以接收 已签名的邮箱验证令牌 (EVT)。
  5. 密钥绑定和提交：浏览器将已签名的 EVT 绑定到密钥绑定 JWT (KB-JWT) 内的 依赖方来源和表单 nonce， 并显示一条小通知，告知用户其电子邮件 提供商已验证其地址。当用户提交表单时，Chrome 会使用组合令牌 (<EVT>~<KB-JWT>) 填充隐藏输入。
  6. 验证声明和 KB：依赖方服务器解析 <EVT>~<KB-JWT>令牌，验证预期声明（email、 email_verified、aud、nonce、iat和exp），并根据cnf.jwk中的临时公钥验证密钥 绑定签名。
  7. DNS 和公钥：依赖方查询 _email-verification.<email-domain> DNS TXT 记录以确认其与 令牌的 iss 声明匹配，然后从 jwks_uri 中提取颁发者的 .well-known/email-verification 元数据和公钥。
  8. 验证 EVT 并完成：依赖方使用提供商的公开 JWKS 验证颁发者的 EVT 签名。如果未收到任何令牌或任何验证步骤失败，网站会回退到其现有的电子邮件确认流程。

用户首次验证电子邮件地址时，Chrome 会在请求令牌之前显示权限提示（桌面设备上显示对话框，Android 设备上显示底部动作条）。如果获得授权，系统会记住每个电子邮件地址在参与网站中的此权限。

Chrome 浏览器设置

用户可以管理其已验证的电子邮件地址：

  • 在桌面设备上，依次点击设置 > 自动填充和密码 > 联系信息 > 已验证的电子邮件地址 （或打开 chrome://settings/contactInfo）
  • 在 Android 设备上，依次点击设置 > 地址等 > 已验证的电子邮件地址

用户可以完全停用该功能，也可以管理各个已验证的电子邮件地址。

应用场景注意事项

邮箱验证功能可作为对现有 flow 的渐进增强，用户无需离开您的网站即可检索动态密码或点击链接。网站可以将邮箱验证字段添加到所有相关表单，例如登录、简报注册、账号创建和密码恢复。EVP 仅在浏览器支持时触发。如果在提交时未收到任何代码或任何验证步骤失败，您可以回退到默认的电子邮件确认流程。这也意味着 API 没有功能检测；验证方网站将 EVT 视为可选，如果请求中存在 EVT，则会对其进行处理。

电子邮件验证可确认用户与其电子邮件地址的提供商拥有活跃会话， 但不会验证您的电子邮件是否已送达用户。您可能仍希望发送现有的欢迎电子邮件或入职电子邮件，并且可能希望或需要提示用户检查其垃圾邮件设置。