notallowederror主因是环境不满足webauthn安全要求：必须https/localhost、用户手势触发、非iframe上下文；challenge须用加密随机字节生成且不可预测；签名验证需严格对齐二进制结构与算法。
WebAuthn注册时 navigator.credentials.create() 报错 “NotAllowedError”
这通常不是代码写错了，而是浏览器拒绝了调用——根本原因是当前上下文不满足 WebAuthn 的安全要求。必须确保：页面通过 HTTPS 提供（localhost 除外）；调用发生在用户手势触发的事件中（比如 click、submit），不能在页面加载后自动执行；且不能在 iframe 中调用（除非显式设置了 sandbox="allow-scripts allow-top-navigation-by-user-activation"）。常见坑是把注册逻辑放在 useEffect(() => { ... }, []) 里（React）或 DOMContentLoaded 回调中，这类“无交互启动”必然失败。
生成 challenge 时为什么必须用加密安全随机字节，不能用 Math.random()
challenge 是防重放攻击的核心凭证，长度不足或可预测会导致攻击者伪造认证请求。服务端必须用 cryptrandom（Node.js）、secrets（Python）或 random_bytes（PHP）生成至少 32 字节的二进制数据，再 Base64URL 编码传给前端。前端收到后要原样传回，不能二次编码或截断。错误示例：Buffer.from(Math.random().toString()).toString('base64url') —— 这既不随机也不定长，服务端验证时会直接拒绝。
认证阶段 navigator.credentials.get() 返回的 response.signature 验证失败
签名验证失败多数源于三类问题：
• 服务端拼接签名原始数据（authenticator data + clientDataJSON hash）时顺序或格式错误，漏掉 rpIdHash 或多加了空格；
• 客户端传来的 response.clientDataJSON 是字符串，但服务端误当 JSON 对象解析，导致 hash 结果不一致；
• 使用了错误的公钥算法（如用 ECDSA P-256 公钥去验 P-384 签名），而 WebAuthn 设备可能返回多种算法，需按 response.response.attestationObject 中的 fmt 和 authData 解析出正确算法与密钥。
Chrome / Safari 对 userVerification 的行为差异
设置 userVerification: "required" 在 Chrome 中会强制弹出指纹/Windows Hello 确认；但在 Safari（macOS/iOS）中，即使设为 required，只要设备支持无感验证（如 Touch ID 已解锁状态），它就可能跳过提示直接通过。这意味着：依赖 userVerification 做强身份确认的业务逻辑，在 Safari 下实际强度可能低于预期。更稳妥的做法是结合 attestation: "direct"（仅限注册）+ 后端设备指纹（如 AAGUID）做设备级风控，而不是单靠前端策略。
WebAuthn 表面是 API 调用，实质是客户端、传输层、服务端三方对二进制结构和密码学流程的严格对齐。最容易被忽略的是：服务端解析 authData 里的标志位（如 up、uv）是否与前端传入的 authenticatorSelection 一致——这里差一个 bit，整个验证链就断了。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
