Email Verification API 开发者指南上如何用 email-verification-token 与 nonce 两个属性告别邮箱验证码【免费下载链接】email-verificationverified autofill项目地址: https://gitcode.com/GitHub_Trending/em/email-verificationEmail Verification API邮箱验证 API是 W3C 社区正在孵化的一项 Web 平台规范提案目标只有一个让用户在注册、登录、找回密码时不再手动抄写邮箱验证码OTP或点击魔法链接而是由浏览器自动向网站出示一份加密签名的邮箱所有权证明。本文将详解它的两个核心 HTML 扩展——autocompleteemail-verification-token自动填充属性与nonce属性帮你在注册表单里用2 行代码接入免验证码的邮箱验证体验。 先搞懂Email Verification API 要解决什么问题先看一组数据截至 2025 年访问量前 50 的网站中95% 支持邮箱注册/登录其中73% 会先验证邮箱才允许完成注册数据来源见 README.md。而当前的邮箱验证码OTP流程有三大痛点痛点说明 投递不可靠验证邮件有延迟还可能进垃圾箱 频繁切换上下文网站 → 邮箱 App → 再回网站体验割裂 易受钓鱼攻击恶意网站可以诱导用户粘贴验证码Email Verification API业内简称EVP的思路是复用用户已登录邮箱服务商的会话由浏览器居中协调向服务商Issuer请求一个加密签名的邮箱验证令牌EVT, Email Verification Token再自动提交给网站Verifier。整个过程无需发送任何验证邮件。三方模型谁负责什么规范采用清晰的三方模型见 index.bs角色是谁职责Verifier验证方你的网站在表单中声明需要一个邮箱验证令牌User Agent用户代理浏览器发现邮箱服务商、请求令牌、绑定后填入表单Issuer签发方邮箱服务商确认用户已登录签发加密签名的 EVT典型流程共 6 步登录 → 声明请求 → 发现并校验 → 签发令牌 → 绑定并填入表单 → 网站校验完整时序说明可参考 README.md 中的流程图。 核心属性一email-verification-token 详解email-verification-token是规范新增的HTML 自动填充字段名autofill field name通过autocomplete属性声明。它的意思是告诉浏览器如果用户在同一表单中选择了某个邮箱地址请在表单提交时把一份加密绑定的邮箱验证令牌EVT自动填入这个字段。规范原文的关键要点见 index.bs✅ 该关键词被正式加入 HTML 标准的自动填充字段名列表✅ 浏览器**应当SHOULD**在表单提交时尝试填入令牌✅ 通常配合input typehidden使用——用户看不见它但它会随表单一起提交。 核心属性二nonce 属性详解nonce原本只用于script和style元素配合内容安全策略 CSP。本规范将它扩展到了input元素见 index.bs。当nonce出现在autocompleteemail-verification-token的输入框上时它有三个硬性要求必须由服务端生成且是密码学强度的随机值每次页面渲染必须唯一MUST 级要求作用把签发的令牌绑定到这一次具体的表单呈现防止重放攻击Replay Attack。两个属性配合起来的分工属性写在哪谁生成作用autocompleteemail-verification-token隐藏输入框前端写死告诉浏览器这里要放邮箱验证令牌nonce同一个隐藏输入框服务端每次渲染动态生成令牌与本次表单一一绑定防重放网站在收到令牌后必须验证三要素audience令牌是否绑定了本站、nonce是否与本次表单一致、exp是否过期。任何一项不符即拒绝从根本上杜绝了截获令牌重放到其他网站的攻击安全要求详见 index.bs。 实战步骤给你的注册表单加上 2 行代码完整的开发者示例表单如下源自规范 index.bs 的官方示例form action/signup methodpost label foremail邮箱地址/label input typeemail idemail nameemail autocompleteemail !-- 只需新增这一个隐藏输入框 -- input typehidden nameevt autocompleteemail-verification-token noncexyz123456789 button typesubmit注册/button /form用户视角会发生什么规范中的浏览器交互示例见 index.bs用户聚焦邮箱输入框浏览器弹出自动填充建议如useremail.example用户选中该邮箱浏览器在后台发现邮箱服务商、校验登录状态并弹出授权提示“是否将 useremail.example 的已验证令牌共享给 rp.example[允许] [拒绝]”用户点允许后浏览器获取 EVT 并将其与你的站点来源origin nonce绑定用户点击注册提交表单时浏览器把绑定令牌自动填入隐藏字段服务端收到的请求即包含email与evt两个参数。你的服务端只需验证签名、origin、nonce 与邮箱一致性校验逻辑见 index.bs即可完成注册——全程没有发送任何验证邮件。优雅降级是设计底线如果浏览器不支持、邮箱服务商未接入、或用户点了拒绝隐藏字段就保持为空你的网站照常走传统 OTP 流程即可。规范在 README.md 中特别强调网站部署时不改变用户任何既有行为这是它能推广的关键。 安全与隐私为什么这个设计值得信任️防重放令牌通过 Key-Binding JWT 同时绑定 nonce 与网站 origin一次令牌只在一个网站的一次表单中有效️签发方致盲浏览器保证签发请求不携带 Referer/Origin 头邮箱服务商无法知道用户正在访问哪个网站见 index.bs✋显式授权每次验证都要求用户明确点允许隐私问答见 QUESTIONNAIRE.md第三方场景禁用iframe 等第三方上下文中该功能默认关闭。一个值得了解的技术细节EVT 证明的是用户已登录该邮箱服务而非验证邮件已被投递到收件箱——规范在 README.md 中坦承这比 OTP 略弱但在实践中两者差别不大。 快速上手在 Chrome 中亲手体验根据 HOWTO.md 的指引5 步即可体验安装 Chrome Canary打开chrome://flags/搜索Email Verification Protocol并启用重启浏览器到chrome://version确认版本为 145在chrome://settings/addresses中确保地址簿里有支持 EVP 的邮箱确认已登录该邮箱服务商然后访问接入 EVP 的演示表单试试效果。 项目文件导航想深入研读按下面的路径找到对应资料 README.md —— 提案全文背景数据、完整流程时序图、激活策略、隐私与安全考量 index.bs —— 规范源文件Bikeshed 格式HTML 扩展定义、浏览器处理模型 index.html —— 渲染后的完整规范文档含目录导航 HOWTO.md —— Chrome 中体验 EVP 的操作指南 QUESTIONNAIRE.md —— W3C 安全与隐私自审问卷的逐条回答 CONTRIBUTING.md —— 参与贡献指南✅ 小结本文拆解了 Email Verification API 中开发者最直接打交道的两个属性email-verification-token负责声明需求nonce负责防重放绑定。二者的组合让邮箱验证从发邮件、等收件、切 App、抄验证码变成一次无感的表单提交同时把验证成本从用户和网站两边都降到了最低。下篇预告浏览器内部到底做了什么我们将深入 EVT 签发协议EVP Protocol——DNS 发现、SD-JWT 签名、密钥绑定KB-JWT的完整链路以及网站服务端的令牌校验清单。【免费下载链接】email-verificationverified autofill项目地址: https://gitcode.com/GitHub_Trending/em/email-verification创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考