基于公私钥的匿名Web服务HTTP身份认证是否有标准化方案？

一、适配场景的标准化认证方法 #

• 公钥挑战-响应认证（遵循RFC 8230等公钥认证规范）
  这是最匹配你需求的标准方案：服务器生成随机挑战值，客户端用本地私钥对挑战签名，服务器用存储的公钥验签。全程服务器仅通过公钥关联用户的加密分片数据，完全不感知用户身份，也不会传输任何敏感身份信息，完美契合你的设计目标。
• OPAQUE协议（IETF标准化）
  OPAQUE原本是为无密码认证设计的标准化协议，核心是服务器不存储用户敏感凭证。适配到你的场景后，客户端可通过私钥完成密钥协商，服务器仅保留公钥相关的验证材料，全程不接触私钥或明文身份数据，完全符合无感知要求。
• JWS结合公钥认证（RFC 7515）
  客户端用私钥对包含公钥标识、请求元数据的JWS签名，服务器用对应公钥验签后确认身份。JWS是通用标准化格式，直接复用现有成熟库即可，无需从零开发。

二、私钥存储的最佳实践 #

• 优先用Web Crypto API存储密钥
  浏览器Web Crypto API支持将私钥标记为extractable: false，绑定当前浏览器上下文，无法直接导出，安全性远高于普通存储。如果用户需要跨设备访问，让其手动导出私钥（如PEM格式）自行保管，这是当前无感知服务的通用做法。
• 禁止将私钥存入Cookie
  哪怕设置了HttpOnly和Secure，Cookie仍有被XSS攻击窃取的风险，且会随请求自动发送，增加暴露概率。如果需要会话保持，可存储公钥哈希值或公钥唯一标识在Cookie中，服务器用这个标识关联数据，私钥始终留在客户端本地。
• 本地存储的安全处理
  若使用localStorage或sessionStorage，务必先对私钥加密（比如用用户设置的额外密码加密）后再存储，防止本地存储被恶意脚本读取。sessionStorage会在标签页关闭后自动清除，刚好满足你“避免遗留私钥”的需求。

三、避免重复造轮子的建议 #

• 椭圆曲线密码学相关操作，直接复用@noble/curves这类遵循RFC 8032等规范的成熟库，无需自行实现底层算法。
• OPAQUE协议可直接使用开源实现，不用自己编写复杂的密钥协商逻辑。
• 挑战-响应流程可基于HTTP的WWW-Authenticate头部扩展，遵循RFC 7235的HTTP认证框架，让你的认证流程符合HTTP标准。

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