用 Private Access Tokens 取代 CAPTCHA

一句话判断

Private Access Tokens 让 iOS 16 和 macOS Ventura 的用户自动跳过 CAPTCHA——你的服务器信任 Apple 设备的身份证明，而不需要用户证明自己不是机器人。

这场 Session 讲了什么

CAPTCHA 是 Web 上最令人厌烦的体验之一。它存在的目的是防欺诈，但代价是伤害正常用户体验、侵犯隐私（通过 IP 追踪）和制造无障碍障碍。

Private Access Tokens 提供了一种替代方案。当用户访问你的网站时，iOS 设备可以向 iCloud Attester 证明自己是合法的 Apple 设备（通过 Secure Enclave 中的证书），然后获得 Token Issuer 签发的匿名 Token。你的服务器验证这个 Token 就可以信任该请求，无需 CAPTCHA。

协议基于 IETF Privacy Pass 工作组正在标准化的技术，使用 RSA Blind Signature 确保 Token 不可追踪——服务器只能验证 Token 是否有效，无法识别或追踪用户。Fastly 和 Cloudflare 已经支持作为 Token Issuer。

值得深挖的点

• 协议流程的六个步骤：客户端请求 → 服务器返回 PrivateToken 挑战 → 客户端向 iCloud Attester 发起设备认证 → Attester 验证后委托 Issuer 签发 Token → 客户端 unblind Token → 客户端将 Token 发送给服务器。整个过程对用户完全透明。
• Blind Signature 的隐私保证：Token 请求经过 blinding 处理，Issuer 签名时看不到原始内容。客户端 unblind 后才能使用。这意味着 Issuer 无法关联 Token 和特定用户。
• 服务端接入的三步走：选择 Token Issuer（Fastly 或 Cloudflare）、发送 PrivateToken 认证挑战、验证返回的 Token 签名。挑战必须来自一级域名。
• 防重放攻击：Token 设计为一次性使用。服务器需要检查 Token 是否被重复使用，可以在挑战中包含唯一值让 Token 绑定到特定请求。

代码片段

# 服务端发送 PrivateToken 认证挑战
# 当客户端首次访问需要验证的页面时
WWW-Authenticate: PrivateToken challenge="abc123...",
    token-key="issuer-public-key...", max-age=0

# 客户端（iOS 16+ / macOS Ventura+）自动处理
# 1. 检测到 PrivateToken 挑战
# 2. 向 iCloud Attester 请求设备证明
# 3. 获取 Token Issuer 签发的匿名 Token
# 4. 在后续请求中携带 Token
Authorization: PrivateToken token="signed-token..."

# 服务端验证 Token
# 1. 用 Issuer 的公钥验证签名
# 2. 检查 Token 是否已使用（防重放）
# 3. 验证通过 → 跳过 CAPTCHA

最佳实践

• 认证挑战不要阻塞主页面加载，作为可选的验证手段
• 同时支持有 Token 和无 Token 的客户端，向后兼容
• Token 验证失败时降级到传统 CAPTCHA，不要直接拒绝
• 选择 Fastly 或 Cloudflare 作为 Issuer，它们已经集成好了
• 挑战必须来自一级域名，不能是嵌入的第三方域名

还有什么值得关注

• register.apple.com 后续会开放更多 Issuer 注册
• iCloud Private Relay 和 Mail Privacy Protection 是 Apple 隐私保护的另一面
• 如果你使用 Cloudflare 或 Fastly 的 CDN，接入成本极低
• “Meet passkeys” 是另一项消除密码的技术，与 Private Access Tokens 互补