一图看懂 Email Verification API：一个隐藏 input 如何改变邮箱验证

一图看懂 Email Verification API：一个隐藏 input 如何改变邮箱验证

【免费下载链接】email-verificationverified autofill项目地址: https://gitcode.com/GitHub_Trending/em/email-verification

本文带你用一张图看懂Email Verification API（邮箱验证协议，EVP）：网站只需在表单里加一个隐藏的 input字段，用户从自动填充列表选中邮箱后，浏览器就会自动向邮箱服务商索取一枚带密码学签名的 Email Verification Token（EVT），并在表单提交时悄悄填入——无需查收验证码邮件、无需点击魔法链接，注册转化率与安全性同时提升。

📧 痛点：为什么邮箱验证又慢又烦

先看一组扎心的数据：2025 年，访问排名最高的 50 个网站中95% 支持邮箱注册，而其中73% 强制要求先验证邮箱才能继续（来源：README.md#L17-L21）。

而今天，"验证邮箱"几乎全都靠同一个笨办法：

摩擦直接作用在"广告 → 发现服务 → 创建账号"的转化漏斗末端，是实打实的钱。

🧠 核心思路：用"登录态"换密码学证明

EVP 的灵感很巧妙：用户既然已经登录了自己的邮箱，何必再发一封邮件证明"邮箱是我的"？

整个协议是一个三方模型（来源：index.bs#L27-L31）：

• Verifier（验证方）：发起验证的网站
• User Agent（浏览器）：居中协调者，全程干脏活
• Issuer（发行方）：管理该邮箱的邮箱服务商

浏览器复用用户与邮箱服务商之间已有的登录会话，向服务商申请一枚签名令牌 EVT，再把它交给网站。网站验签即可确认邮箱所有权，全程不发一封邮件、不用用户手动粘贴任何验证码。

📋 一图看懂：完整验证流程

① 用户在邮箱输入框中选中一个邮箱地址 │ ▼ 网站表单 ──(内含一个隐藏 input，带 nonce)──▶ 浏览器 │ ▼ ② 浏览器查 DNS，找到该邮箱域名对应的"发行方" │ ▼ ③ 浏览器确认：用户当前已登录该发行方（邮箱服务商） │ ▼ ④ 浏览器弹出权限提示："与某网站共享邮箱验证令牌？" 用户点击【允许】 │ ▼ ⑤ 浏览器向发行方请求签名令牌 EVT（走第一方 Cookie） │ ▼ ⑥ 浏览器把 EVT 绑定到 nonce + 网站域名（防重放） │ ▼ ⑦ 用户点击"注册"——提交瞬间，浏览器自动把 令牌填入隐藏 input，随表单一起提交 │ ▼ ⑧ 网站服务器验证签名：通过 ✅ 直接放行， 不再发送任何验证邮件

对应提案中的完整时序，可参考 README.md#L49-L78。

✍️ 网站端接入：一行隐藏的 input 就够了

对网站的改动小到令人发指——在现有表单里多加一个隐藏输入框即可（来源：README.md#L109-L115）：

<input type="hidden" name="token" nonce="<?php generate_nonce() ?>" autocomplete="email-verification-token">

两个关键属性：

• autocomplete="email-verification-token"：告诉浏览器"这里要放邮箱验证令牌"
• nonce：服务端每次渲染页面时生成的随机数，把令牌绑死在"这一次表单"上，防止令牌被截获后重放

为什么最终选了<input type="hidden">？因为它天然满足四个条件：看不见、随表单提交、已支持 autocomplete 自动填充、只差一个 nonce 属性——是"渐进增强"的完美载体（来源：README.md#L482-L495）。

🔍 浏览器幕后：从选邮箱到填令牌的 7 个动作

规范文档 index.bs 中定义了完整的浏览器处理模型，核心动作依次为：

1. 捕获选择：用户从自动填充列表选中邮箱时触发（index.bs#L115-L139）
2. 发行方发现：通过 DNS TXT 记录查找邮箱域名对应的签发者，支持gmail.com这类邮箱域委托给accounts.google.com这类账号域
3. 账号校验：检查用户是否已登录发行方，再比对账号列表里是否包含所选邮箱（大小写不敏感）
4. 权限提示：由浏览器决定如何询问用户"是否共享验证令牌"
5. 令牌签发：浏览器生成临时密钥对，构造签名请求，服务商校验会话后返回 SD-JWT 格式的 EVT（index.bs#L173-L204）
6. 密钥绑定：浏览器将 nonce 与网站 Origin 绑进令牌（KB-JWT），一次性、不可转移
7. 提交注入：表单提交、onsubmit触发之前，浏览器把令牌值写进隐藏 input（index.bs#L141-L152）

任何一步不满足（比如浏览器不支持、用户没登录邮箱），流程就静默终止，网站收不到令牌，自动回退到传统 OTP 流程——这就是官方所说的"优雅降级"。

🧪 上手指南：在 Chrome 中快速测试邮箱验证

想亲手体验？HOWTO.md 给出了在 Chrome 里测试的步骤（来源：HOWTO.md#L5-L11）：

1. 安装 Chrome Canary
2. 访问chrome://flags/，搜索Email Verification Protocol并启用，重启浏览器
3. 到chrome://version确认版本在 145+
4. 到chrome://settings/addresses确认已添加支持 EVP 的邮箱地址
5. 保持登录该邮箱的状态，打开任何含 EVP 隐藏 input 的页面即可体验

🛡️ 隐私与安全：比 OTP 更强还是更弱？

项目附有一份完整的安全与隐私自审问卷（QUESTIONNAIRE.md），几个关键结论值得普通用户了解：

对隐私的改善✨

• 邮箱服务商被"致盲"：令牌签发请求不得携带网站 Origin，服务商不知道你在哪个网站注册（index.bs#L220-L224）
• 网站不再需要向你的邮箱发信，也少了一条"邮箱被收集"的渠道

对安全的影响🔒

• 防重放：令牌绑定 nonce + 网站域名 + 过期时间，拦截后无处可用
• 一个诚实的弱化点：EVT 证明的是"用户已登录该邮箱应用"，而不证明"邮件真实投递到了收件箱"，理论上比 OTP 弱一环——但官方认为实践中差异并不显著

❓ 常见问题 FAQ

问：用户还需要去收件箱查收验证码吗？不用。这正是 EVP 的核心价值——验证完全基于登录态，零邮件往返。

问：我的浏览器或邮箱服务商不支持会怎样？什么都不会坏。隐藏 input 只是保持空值，网站照走原有的 OTP/魔法链接流程。设计上刻意做到不需要所有浏览器、所有邮箱服务商同步升级。

问：它会不会取代 Passkey（密码密钥）或密码？官方态度是"共生共存"：EVT 是工具箱里新增的一件工具，不太可能削弱去密码化的进程（来源：README.md#L253-L261）。

问：一个表单里有多个邮箱字段（比如工作邮箱 + 个人邮箱）怎么办？目前是官方承认的开放问题之一，提案仍在探索中（来源：README.md#L341-L345）。

问：用户会看到什么新界面？仅多一次浏览器的权限询问弹窗（"是否共享邮箱验证令牌？"），除此之外行为与以往一致。

📚 延伸阅读：项目文件导航

一句话总结：Email Verification API 把"证明邮箱是我的"这件事，从"收发一次邮件 + 人工粘贴"压缩成了浏览器后台的自动握手——一个隐藏 input，就是用户体验与安全性双赢的支点。

【免费下载链接】email-verificationverified autofill项目地址: https://gitcode.com/GitHub_Trending/em/email-verification