邮箱验证更新,2026 年 8 月

发布日期:2026 年 8 月 13 日,上次更新日期:2026 年 10 月 5 日

电子邮件验证源试用已在 Chrome 150 中开始。根据您的反馈,我们进行了一些修复和改进。本文简要介绍了这些变化,以及您应在网站或服务中采取的行动。

首先,我们来回顾一下电子邮件验证功能(如需了解详情,请参阅之前的公告)。网站上的一种常见模式是,用户在注册、登录、账号恢复等过程中输入电子邮件地址,然后必须前往自己的电子邮件收件箱,点击魔法链接或获取一次性密码。电子邮件验证功能通过在浏览器中直接向提供商验证电子邮件地址,对此进行了改进。然后,该网站会从浏览器收到一个令牌,该令牌可用于向电子邮件提供商进行验证,并完全跳过发送该电子邮件的步骤。

面向用户的更新

界面或面向用户的行为发生变化。

电子邮件地址输入

以前,用户必须使用自动补全或自动填充功能才能输入电子邮件地址。现在,只要用户以任何方式(例如,通过输入或粘贴)在相应字段中输入电子邮件地址,系统就会在用户退出 input 元素后立即触发验证流程,类似于 change 事件。这意味着,邮箱验证应能有效触发任何电子邮件地址条目。

进度指示器

我们还在 Chrome 152 及更高版本中测试验证流程的进度指示器。虽然验证流程很快,但用户仍有可能在流程完成之前提交表单。进度指示器在验证时会显示旋转图标,验证完成后会在输入字段的内嵌末尾(对于从左向右书写的语言,为右侧)显示对勾标记。

如果这导致任何问题或您发现任何意外行为,请提交 bug。

仅限桌面设备

电子邮件验证功能仅可在桌面设备上使用,且仅适用于 Chrome 152 及更低版本。我们也在积极探索在 Android 上提供支持,未来会在此处发布最新动态。

验证者更新

对于收集和验证电子邮件地址的网站,此功能有所变化。

令牌验证

电子邮件验证令牌以 JSON Web 令牌 (SD-JWT) 的选择性披露格式提供。原始格式如下所示:由颁发者签名的 JWT,后跟零个或多个披露信息,最后是密钥绑定 JWT,每个组成部分之间用波浪号分隔:

<Issuer-signed JWT>~<Disclosure.1>~<Disclosure.2>~...~<Disclosure.N>~<Key Binding JWT>

电子邮件验证令牌目前仅返回由签发者签名的 JWT 和密钥绑定 JWT,不包含任何披露信息。原始博文和演示的第一个迭代版本只是将令牌拆分为两部分,然后解析这两个 JWT。这种方法很脆弱,如果未来添加选择性披露,就会失效。

您不应依赖当前提案的此功能,而应确保您的实现方案能够根据 SD-JWT 规范正确解析 SD-JWT 令牌,最好是使用适用于您平台的库。例如,演示验证代码现在使用 @sd-jwt/core 解析令牌并验证密钥绑定(受众群体、随机数和哈希),然后使用 jose 验证签发者的 EVT 和浏览器的密钥绑定 JWT 的签名。

第三方来源试用

自 8 月起,邮箱验证不支持第三方来源试用。第三方源试用允许第三方源在其包含的网站上启用试用功能,例如跨源 JavaScript 依赖项。如果这对您的使用情形至关重要,请在跟踪 bug 中发表评论或关注该 bug。

不区分大小写的电子邮件比较

请注意,即使您在表单中提供了 demo.user@example.com,电子邮件服务提供商也可能会返回包含大写字母的规范电子邮件地址,例如 Demo.User@example.com。确保您正在对收到的电子邮件地址进行不区分大小写的比较。我们还修复了设置页面中的一个 bug,该 bug 可能会导致您看到列出的同一电子邮件地址存在区分大小写的变体。

提供方更新

针对电子邮件服务提供商的变更。

针对签发请求的 HTTP 消息签名

我们在 Chrome 153 中引入了一项重大变更,即签发请求将仅以 application/json 格式发送 email,并附带 HTTP 消息签名。

  • Chrome 152(及更早版本):签发端点会收到正文中包含 request_token 的 application/x-www-form-urlencoded POST 请求。
  • Chrome 153(及更高版本):内容类型更改为 application/json,包含 Signature、Signature-Input 和 Signature-Key 标头,以及仅包含 email 键的正文。

您可以根据当前流量水平和测试目标执行以下任一操作:

  • 支持这两种格式,并根据内容类型进行切换。Chrome 153 在 8 月底达到稳定版后,您可以评估流量,以移除旧版功能。
  • 只需切换到新格式,这意味着 Chrome 早期版本的用户将无法通过验证。

演示代码中的签发端点已更新,可使用 structured-headers 和 http-message-sig 处理这两个流程。

完整请求格式:

POST /email-verification/issuance HTTP/1.1
Host: provider.example
Accept: application/json
Content-Digest: sha-256=:aBc123aBc123aBc123aBc123aBc123=:
Content-Type: application/json
Signature: sig=:+dEf567dEf567/dEf567dEf567dEf567/dEf567==:
Signature-Input: sig=("@method" "@authority" "@path" "content-digest" "signature-key");created=1786455840
Signature-Key: sig=hwk;crv="Ed25519";kty="OKP";x="gHi890_gHi890_gHi890"

{email: "demo@example.com"}

响应格式保持不变:application/json 正文中的 issuance_token。


您可以访问以下提案代码库,阅读并提出更多反馈意见:WICG/email-verification 和 dickhardt/email-verification。到目前为止,社区的反馈非常有帮助,因此您可以期待我们继续推出更新和改进。