Passkey依赖方服务器实现六大技术问题咨询

1. 能否用UUID作为User ID并作为非认证实体的外键？ #

完全可以。UUID的原始二进制数据正好是16字节，符合文档对User ID的长度要求。返回给客户端时，只需将UUID的二进制数据转成base64url编码（和示例格式一致）即可。将其作为非认证相关实体的外键也没有问题，UUID的全局唯一性足够满足业务需求，且比自定义随机字符串更规范，便于后续维护。

2. name和displayName字段能否后续修改？ #

可以修改。这两个字段仅用于客户端（如系统密码管理器）的展示，和Passkey认证的核心逻辑不绑定。修改后，下次用户发起注册或认证请求时，服务器返回更新后的字段值即可，无需修改已存储的公钥凭证关联数据。

3. 注册阶段生成Challenge后，需要持久化哪些数据到数据库？ #

核心需要持久化的数据包括：

• 生成的Challenge字符串（base64url编码格式）
• 对应的用户标识（比如你使用的邮箱，或内部用户ID）
• 建议额外存储：Challenge的过期时间（防止重复使用）、请求中的RP信息、pubKeyCredParams参数（用于后续验证客户端返回的凭证是否匹配请求参数）

不需要存储整个返回的Challenge模型JSON，但要保留验证阶段需要用到的关键参数，避免后续验证时因参数不一致导致失败。

4. 注册请求Challenge时（用邮箱作为用户标识），是否需要检查用户是否存在？ #

不需要检查。如果根据用户是否存在返回不同的响应（比如存在返回200，不存在返回404），会给攻击者提供用户枚举的机会，违反隐私安全原则。无论用户是否已注册，都返回正常的Challenge响应即可，后续在注册完成阶段再处理用户创建或关联的逻辑。

5. 请求Challenge时是否应使用Basic Auth？有其他可选方案吗？ #

不建议使用Basic Auth，因为移动端的凭证存储存在风险，且Basic Auth仅通过base64编码（非加密）传输，安全性不足。可选方案包括：

• 邮箱+一次性验证码（OTP）：用户先输入邮箱，服务器发送OTP，客户端携带OTP和邮箱请求Challenge，验证OTP有效后返回
• 设备可信验证：利用Android SafetyNet、Apple DeviceCheck等厂商服务验证设备合法性，适合自有可信APP场景
• APP内会话：如果用户已通过其他方式（如账号密码）登录并持有有效会话，可通过会话验证身份，但注册阶段通常无有效会话，前两种方案更适用

6. Android测试Passkey是否必须部署到公网环境？ #

不是必须，但有以下注意事项：

• Android 14及以上版本支持localhost作为RP ID，但需在APP配置中开启android:usesCleartextTraffic="true"（仅测试环境使用），且RP ID需设置为localhost或127.0.0.1
• 低版本Android不支持localhost，可使用本地局域网IP（如192.168.x.x）作为RP ID，同时确保设备与服务器在同一局域网，且服务器SSL证书有效（可使用自签名证书，但需在Android设备上手动信任）
• 测试时需使用支持WebAuthn的环境：如Chrome浏览器，或APP集成Google Credential Manager等官方SDK，确保SDK兼容本地测试环境

内容的提问来源于stack exchange，提问作者Igor Karun