如何判断WebAuthn异常是否应向用户展示？

针对PublicKeyCredential.create()和get()的异常处理，可按用户感知、错误属性及浏览器差异划分处理逻辑，同时通过规范细节和业务上下文来区分场景：

一、异常分类与处理原则 #

• 无需通知，静默处理：用户主动触发的操作场景，比如用户取消认证弹窗、主动退出设备选择流程。这类操作用户完全知情，额外提示反而干扰体验。
• 必须通知用户：属于用户无法自行感知的实际错误场景，包括：
  • options对象格式错误（参数不符合WebAuthn规范要求）
  • 浏览器内部错误（如设备接口调用失败、安全模块异常）
  • 硬件密钥故障（比如密钥损坏、无法被浏览器识别）
    这类情况需明确告知用户问题，例如提示“认证参数错误，请重试”或“浏览器认证服务异常，请稍后再试”。
• 浏览器差异场景的适配：像你提到的「用户选择的密钥不在allowCredentials列表中」，Chrome会在原生界面提示并允许重试，Firefox则直接抛出异常。应对方案：
  1. 捕获异常后，通过DOMException的name字段（如Firefox抛出的NotAllowedError）结合业务上下文判断场景
  2. 统一提示用户“所选密钥无法用于此认证，请选择其他密钥或重试”，同时提供重试入口，抹平浏览器体验差异。

二、异常区分的可行方法 #

WebAuthn规范虽未明确规定前端需提示的异常类型，但可通过以下方式精准区分：

1. 异常类型识别：利用DOMException的name字段判断：
   • AbortError：通常对应用户主动取消操作，静默处理
   • NotAllowedError：包含多种场景，需结合上下文判断（比如调用get()时出现，可能是密钥不在允许列表或用户拒绝）
   • InvalidStateError：多为参数格式错误或设备状态异常，需通知用户
2. 业务上下文辅助判断：比如调用get()前已明确用户的允许密钥列表，若抛出NotAllowedError，大概率是用户选了不在列表里的密钥，可针对性提示。

三、关于是否支持WebAuthn/Passkeys #

浏览器差异确实存在，但这类问题可通过统一的异常捕获和提示逻辑抹平。WebAuthn作为主流无密码认证方案，安全性和用户体验远优于传统密码，建议优先支持。可通过以下方式降低适配成本：

• 覆盖Chrome、Firefox、Safari等主流浏览器的异常场景测试
• 针对模糊的异常类型，采用通用友好提示（比如“认证失败，请重试”），同时保留重试入口

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