什么是证明令牌
证明令牌是一份签名声明，表明请求来自真实的浏览器或设备。设备向其平台自证，平台签发令牌，你的站点收到令牌，而无需让用户去解一个验证码。令牌不携带身份信息，因此不会跨站点追踪用户。
在 Web 上，这建立在 Private Access Tokens 与 Privacy Pass（RFC 9576）之上。一项更新的扩展 PACT —— Private Access Control Tokens —— 于 2026 年 6 月由 Cloudflare、Chrome、Firefox、Edge 与 Shopify 提出，用以拓展这些令牌的签发与使用方式。
其目标是让真实用户更频繁地跳过挑战，同时让验证从设计上保持隐私。
PACT 仍是早期提案，距离广泛部署尚需数年。CaptchaLa 目前已支持现有的 Private Access Tokens / Privacy Pass 机制，并会随提案演进持续跟进。这一切都不需要你等待。
CaptchaLa 如何使用它们
我们把证明令牌视为众多信任信号之一，而非全部决策依据。流程很简单：
令牌已验证，跳过挑战
如果存在有效的证明令牌，我们会用签发方的公钥进行校验。携带已验证令牌的低风险访客无需交互挑战即可通过。
回退到基于风险的验证
如果没有令牌，或令牌无法校验，CaptchaLa 会使用自有风险引擎 —— 结合设备、网络与行为信号 —— 仅在请求看起来可疑时才展示挑战。
适用范围：Web 与原生应用
设备证明并非处处一致。下面如实说明哪些可自动生效，哪些需要你自行配置。
Web —— Private Access Tokens / Privacy Pass
自动在 Web 上，CaptchaLa 用签发方的公钥校验 Private Access Tokens。你无需做任何设置 —— 受支持的浏览器与设备会生成令牌，我们负责读取。
iOS App Attest / Android Play Integrity
可选，需你配置这些原生证明绑定的是你自己应用的开发者身份，而非某个公共签发方。它们只能作为你为自有应用配置的可选信号，因此并非对所有人自动生效。
其余原生应用场景
我们自有的风险信号在未配置平台证明的场景下，原生应用依赖 CaptchaLa 自有的设备与行为风险信号 —— 与保护 Web 回退路径的是同一套引擎。
设备证明说“是真实设备”。我们补上“真实且未在滥用”。
设备证明能确认请求来自真实设备，却无法判断该设备是否正被用来滥用你的服务。这一空白正是 CaptchaLa 长期价值所在 —— 而且它不会因为设备证明落地而消失。
撞库
运行被盗用户名密码列表的真实设备，在证明令牌看来仍是真实设备。我们的风险引擎能识别这种模式。
代理与机器人农场
来自众多真实设备的分布式滥用能通过设备证明，却过不了行为与网络评分。
OTP 与注册滥用
批量注册账号与刷取一次性密码都来自真实手机。我们评估的是意图，而不只是设备的真实性。
欺诈与内容滥用
支付欺诈、垃圾信息与有害上传关乎行为，而设备证明不衡量行为 —— 这正是我们的风险引擎与内容审核所擅长的。