电子邮件地址验证

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

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

电子邮件验证用户提示演示
电子邮件验证用户提示演示

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

  • 无中断：验证在后台进行，用户填写表单时不会受到影响。
  • 无需进行功能检测：网站只需向其表单添加电子邮件输入和隐藏的令牌输入即可。如果浏览器或提供商不支持电子邮件验证，或者验证失败，网站会回退到其默认的电子邮件确认流程。
  • 降低钓鱼式攻击风险：没有可供复制的代码，也不会将用户引导至虚假网站。

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

源试用注意事项

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

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

您可以通过添加源试用令牌，按响应控制源试用功能。这样一来，您就可以将该功能限制为仅供特定用户群（例如 A/B 测试群体）使用。或者，如果您有一组参与 Beta 版测试或早期预览版测试的用户，您可能需要为他们启用此功能。在这种情况下，请在签发或验证令牌之前，对照所提供的电子邮件地址进行检查。

源试用还设置了流量限制，以尽量减少在发布之前依赖该功能的网站数量。签发方 API 正在开发中，您应了解，随着 Chrome 用户体验的更新，该 API 会发生向后不兼容的变更。

随着开发工作的推进，请随时关注此博客和 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 绑定到可信方来源和表单 nonce（在密钥绑定 JWT [KB-JWT] 内）。当用户提交表单时，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，则会处理它。

电子邮件验证可确认用户是否与电子邮件地址提供商建立了有效会话。它不会验证您的电子邮件是否已送达用户。您可能仍想发送现有的欢迎电子邮件或新手入门电子邮件，并且可能想或需要提示用户检查其垃圾邮件设置。