2026 Chrome Email Verification API 提供方请求怎么验？

时间线结论：先验签，再签发

Chrome 153 起，签发请求转为 JSON 请求体和 HTTP Message Signatures；字段出现不等于验签通过。 本周建议先按 Chrome 当前签发端指南核对签名覆盖内容、Content-Digest、用户会话和目标邮箱，再为浏览器过渡期保留请求头兼容，并确保签发失败时邮件确认流程仍能走通。Chrome 官方将 Email Verification 标为 Origin Trial，实施细节仍可能调整。

这篇适合维护自家邮箱身份提供方或账号系统的后端开发者，也适合复核签名与会话边界的安全工程师。
负责签发端兼容性验收的 QA，可用下文的版本对照和负向用例建立测试集。

本文只讨论测试自家服务或获授权环境里的 Chrome Email Verification API 提供方请求验证。提供方负责验证浏览器发来的签发请求并决定是否签发令牌；网站验证方接收令牌后，另行验证令牌及其绑定信息。二者不是同一条验收责任。

先识别请求版本，别把过渡期当成单一格式

版本差异不只是请求体编码变了。旧格式请求不能被当成新版 JSON 签名请求直接解析；新版请求的签名校验也不应因为还保留旧分支而被跳过。Chrome 官方记录了 Chrome 152 及更早版本与 Chrome 153 起的请求格式差异，后续指南还记录了 Sec-Fetch-Dest 和签名算法标识的变化。

表中的版本与字段差异来自 Chrome 2026 年 8 月更新、Chrome 2026 年 10 月更新及官方签发端实施指南。版本号描述的是指南记录的请求演进，不等于所有接入环境都已完成升级。

后端开发者：把验签责任落实到每个字段

在 Chrome 153 起的请求中，Signature 携带签名值，Signature-Input 说明签名覆盖的组件及参数，Signature-Key 提供用于验证的临时公钥信息，Content-Digest 则对应请求内容摘要。提供方需要按 Chrome 的签发端规则解析并验证这些内容；不能把“请求走了 HTTPS”或“签名头存在”当成验签结果。HTTP Message Signatures 的通用验证机制见 RFC 9421。

可把实现拆成一条明确的拒绝链：

• 解析 Signature 与 Signature-Input，检查签名标签相互对应，并确认覆盖组件符合签发端规则。
• 使用 Signature-Key 中的公钥执行密码学验签；同时按 Chrome 当前文档接受适用的算法标识和旧版本可省略的 alg 情况。
• 对未经 JSON 解析或改写的原始请求体计算摘要，再与 Content-Digest 比对。若先解析后重新序列化，空白、编码或字段顺序变化可能让摘要计算对象不再是收到的字节。
• 任一解析、覆盖、摘要或验签步骤失败，停止签发并记录可排查的失败原因。

反向代理和负载均衡器是常见的隐性故障点。签名所覆盖的 @authority 指向浏览器请求的公网 authority，而应用内部看到的主机名可能是服务名或容器名；若用内部主机名重建签名基串，合法请求也可能验不过。只从可信代理恢复公网主机信息，并按照官方指南还原验证上下文；不要无条件信任客户端自行提供的转发头。

会话与账号维护者：验证当前用户，而非只认邮箱字符串

签名回答的是“这条受覆盖的 HTTP 消息是否由相应密钥签出且未被改动”，并不自动回答“当前浏览器会话属于哪个用户”。签发前仍需验证随请求到达的第一方会话凭据，确认用户已登录，并确认请求中的地址是该用户当前可验证的邮箱。Chrome 的流程说明将联系提供方、签发令牌和网站验证令牌列为不同环节；不能把其中一个环节的成功当成整个邮箱验证流程完成。

邮箱匹配时要把“内部用于找账户的值”和“令牌中要返回的字符串”分开处理。账号系统可用自身一致的规则确认请求地址对应当前用户；但 Chrome 156 起，EVT 中的 email 声明必须与请求值逐字节一致。也就是说，不能先将请求地址改成内部规范形式，再把修改后的地址放进令牌。应保留收到的原始请求邮箱用于令牌声明，同时单独完成账户匹配。相关版本变化以官方签发端指南和更新记录为准。

安全审核者：负向用例要证明系统真的会拒绝

只用正确签名的请求做集成测试，很难发现代码实际上忽略了验签结果。RFC 9421 的安全考虑提醒，验证器可能在消息格式仍有效的情况下忽略签名结果，因此应使用无效签名确认请求会按预期失败。

建议在不接触生产用户数据的隔离环境中，覆盖以下分支：

• ✅ 有效请求： 签名、摘要、会话和邮箱均匹配；应产生符合当前格式的签发结果。
• ❌ 签名缺失或无效： 删除签名字段、篡改签名值，或让 Signature 与 Signature-Input 标签不对应；确认没有令牌签发。
• ❌ 摘要不一致： 保持签名测试数据不变，只改请求体字节；确认摘要校验失败并拒绝。
• ❌ 会话失效： 使用过期、缺失或不属于测试用户的会话；确认不会因签名有效而放行。
• ❌ 邮箱不匹配： 请求另一测试邮箱，或让请求地址与登录账户绑定地址不符；确认不会签发给错误账号。

测试私钥、测试会话、邮箱数据和日志应与生产隔离。日志可以记录判定类别和请求关联标识，但不要为方便排查而落盘完整会话凭据或不必要的个人信息。团队也可参考隐私与数据处理说明，梳理测试数据的处理边界。

常见验收问答

Chrome Email Verification API 提供方收到请求后，还要检查什么？

除请求是否到达外，还要核对请求格式、签名覆盖组件、签名本身、请求体摘要、登录会话和邮箱归属。某项失败就应停止签发，而不是只返回成功状态。浏览器拿到签发结果后还要处理令牌；网站接收到令牌后也有独立的验证责任，因此这几种结果应分开记录。

Signature 和 Signature-Input 需要怎样配合验证？

按 RFC 9421 解析两个字段并确认对应标签，再依签发端策略重建签名基串、验证密码学签名及覆盖内容。Chrome 指南还要求处理 Signature-Key 和 Content-Digest。如果请求经过代理，重建时还要正确保留浏览器请求的公网 authority。字段存在、TLS 已启用或返回成功状态，都不能单独证明验签完成。

Chrome 154 之后 Sec-Fetch-Dest 的变化影响什么？

它影响签发端对请求上下文的检查：Chrome 153 使用不带连字符的值，Chrome 154 起改为带连字符的值。过渡测试需覆盖两种已记录的写法，确认目标浏览器版本不会被误拒，同时不接受任意未知值。这个请求头检查属于上下文防护，不能替代签名、会话或邮箱匹配。

怎样确认无效签名会被拒绝，而且测试邮件回退可用？

先对测试环境执行签名缺失、签名篡改、摘要不符、会话失效和邮箱错配等负向请求，确认都不会签发令牌；再模拟没有令牌或网站验证失败，确认自家原有邮件确认流程可继续。保存浏览器版本、请求格式、失败原因和回退结果。测试收件成功只能说明该次测试邮件有收件证据，不是生产邮件送达保证。

QA 与发布负责人：分开记录签发、令牌与回退结果

验收表至少要分开记录三类结果：签发端接受或拒绝请求、浏览器是否接受并取得令牌、网站是否完成令牌验证。签发端返回成功并不证明浏览器接受了令牌；浏览器取得令牌也不代表网站验证通过。Chrome 官方流程明确说明，无令牌或验证失败时，网站应回到既有邮件确认流程。具体职责和流程可对照Chrome Email Verification API 流程说明。

发布前可按这个顺序操作：

1. 在隔离环境部署签发端，使用专用测试账户、测试邮箱和非生产密钥。
2. 准备旧式表单请求与新版 JSON 请求，并记录测试浏览器版本；只保留业务确实需要支持的兼容分支。
3. 分别验证签名、摘要、会话和邮箱匹配；为每项失败准备明确的拒绝结果。
4. 对照当前指南验收合法请求生成的 issuance_token，再由浏览器和网站验证方完成后续测试。
5. 分别模拟不支持该能力、没有拿到令牌、签发被拒绝和网站验证失败，确认邮件确认流程仍可继续。
6. 留存版本、请求格式、关键判定结果和回退证据；不要把临时收件箱中的测试结果写成生产送达率承诺。

时效核对： 最后更新于 2026 年 10 月 30 日，请求格式、Chrome 版本差异和试验状态核实自 Chrome 官方签发端指南、2026 年 8 月与 10 月更新，以及 RFC 9421。该能力仍处于 Origin Trial，后续行为应以官方指南更新为准。

如果验收目标还包括自家产品的实际邮件确认回退，签发端测试之外还要单独检查邮件是否生成、是否进入测试收件箱；可参阅测试邮箱收信排查指南。对于只需临时注册或收一次测试验证码的场景，ZOSend 可作为隔离测试收件的方案之一，减少主邮箱暴露；它不能替代 Chrome API 签发端，也不构成邮件必达保证。

常见问题

签发请求到达后，服务端还要核对哪些条件？

请求到达只说明网络链路已触及端点，不代表身份已确认。签发端还需按当前协议解析请求，校验 HTTP Message Signatures 及请求摘要，确认请求属于有效的登录会话，并核对请求邮箱确实对应当前用户。任何一项不满足，都不应继续签发令牌。

Signature 和 Signature-Input 应怎样一起验证？

先按 RFC 9421 解析两个结构化字段，并确认签名标签对应；再按 Chrome 签发端指南要求的覆盖组件重建签名基串，使用 Signature-Key 中的公钥验签。同时核对 Content-Digest 是否对应原始请求体。仅检查字段存在、或只依赖 TLS，都不能替代密码学验签。

Chrome 154 之后 Sec-Fetch-Dest 的差异需要兼容吗？

需要在过渡期测试两种值：Chrome 153 使用不带连字符的 emailverification，Chrome 154 起使用 email-verification。不要根据某一台浏览器的单次请求就假设所有客户端都已切换；依据实际支持范围保留兼容判断，并将不符合允许值的请求拒绝或记录。

如何测试拒绝无效签名，同时保留邮件验证回退？

在隔离环境使用测试会话、邮箱和密钥，分别发送有效签名、缺失签名、错误签名、摘要不匹配及会话或邮箱不匹配的请求。负向请求必须不能触发令牌签发。再单独确认浏览器不支持、没有拿到令牌或网站验证失败时，自家既有邮件确认流程仍可完成。