为什么我们构建了无需账户、密码或个人数据的身份验证

Source: Dev.to

我们不断看到的问题

在许多真实场景中，账户并不是产品本身：

• 活动访问（线上或线下）
• 一次性或短期会话
• 管理员或内部工具
• 为客户或合作伙伴提供的临时访问
• 存在性或控制权证明流程

然而大多数认证方案迫使你：

• 创建用户，
• 存储标识符，
• 管理恢复流程，
• 并承担你实际上并不需要的个人数据责任。

这会增加：

• 法律风险（GDPR、数据泄露），
• 工程复杂度，
• 用户的认知负担。

思路：无身份的访问

我们提出了一个简单的问题：如果认证是关于证明访问，而不是拥有账户会怎样？

于是我们不再使用用户，而是使用 访问通行证。

• 没有用户名
• 没有电子邮件
• 不存储个人数据
• 仅凭加密证明

工作原理（高层）

核心流程基于 QR + TOTP，但采用了不同的思维模型：

1. 服务生成一个临时访问通行证。
2. 通行证以二维码形式呈现。
3. 用户使用任意兼容 TOTP 的应用扫描二维码。
4. 服务器对代码进行加密验证。
5. 授予访问——不涉及账户。

关键特性

• 密钥永不离开用户设备。
• 服务器仅存储加密的、非个人身份信息（non‑PII）数据。
• 通行证可以是短期的、具有限定范围且可撤销。

从服务器的角度来看，没有任何用于识别个人的东西——只有证明是否有效。

为什么选 QR + TOTP？

我们有意避免使用：

• 专有应用，
• 魔法链接，
• 手机号码，
• 生物特征锁定。

TOTP 的优势在于：

• 广泛支持，
• 离线友好，
• 易于理解，
• 易于审计。

QR 的优势在于：

• 快速，
• 跨设备，
• 对非技术用户直观。

二者结合可以实现一种：

• 对用户友好，
• 对开发者可预测，
• 数据最小化的流程。

这不是

这 不是 以下的替代方案：

• 完整的用户账户，
• 社交登录，
• 身份管理。

如果你需要：

• 用户档案，
• 长期身份，
• 个性化，
• 社交图谱，

传统认证仍然是合理的选择。此方法适用于 身份是多余负担 的场景。

为什么提前分享

我们正在公开且谨慎地验证这种方法。我们关注：

• 可能遗漏的边缘案例，
• 该模型失效的情形，
• 仍然离不开账户的使用场景。

来自在真实系统中与认证复杂性搏斗的工程师的反馈尤为宝贵。

感谢阅读。欢迎在评论中讨论权衡、安保考量以及真实世界的约束。