2. 身份认证演进

要理解WebAuthn与SPC（Secure Payment Confirmation）为什么会出现，不能只从技术规格入手，而要先看清一条主线：身份认证的演进，本质上是在“证明我是我”这件事上，不断把可被窃取、可被重放的秘密，替换为不可转移、不可复制的凭证。密码、OTP、生物识别、FIDO2与WebAuthn，正是这条主线上的四个阶段，而支付场景则是最苛刻的检验场。

一、核心原理：认证因子的三次“所有权转移”

认证因子通常分为三类：你知道什么（密码、PIN）、你拥有什么（手机、硬件密钥）、你是什么（指纹、人脸）。传统方案的痛点，往往来自“共享秘密”这一模式本身。

• 密码：服务器保存口令哈希，用户提交口令比对。问题在于口令可被钓鱼、撞库、复用，且服务器端一旦泄露，攻击者可离线爆破。
• OTP：在密码之外增加一次性验证码，缓解了静态口令泄露，但验证码仍可被实时转发给钓鱼站点，形成“中间人代理”攻击。
• 生物识别：指纹、人脸提升了本地体验，但若生物特征被上传到服务器比对，就变成了新的“共享秘密”，一旦泄露不可更改。
• FIDO2/WebAuthn：把私钥留在设备安全芯片中，服务器只保存公钥。认证时设备用私钥签名，服务器验签。私钥永不离开设备，也不在网络中传输。

这条演进逻辑可以概括为：从“共享秘密”走向“非对称密钥”，从“可复制凭证”走向“绑定设备的不可导出凭证”。WebAuthn是W3C标准，定义了浏览器与认证器之间的API；FIDO2是FIDO联盟的协议集合，包含WebAuthn与CTAP。二者共同让“无密码”和“强认证”在Web上可落地。

二、方法流程：一次WebAuthn注册与认证发生了什么

以支付场景为例，用户首次绑定设备时执行注册（attestation），后续支付时执行认证（assertion）。核心流程如下：

1. 服务器生成随机挑战（challenge）和依赖方信息（rpId），下发给浏览器。
2. 浏览器调用 navigator.credentials.create()，由认证器生成密钥对。
3. 认证器返回公钥、凭证ID和签名，服务器保存公钥与凭证ID，完成绑定。
4. 支付时服务器下发新challenge，浏览器调用 navigator.credentials.get()。
5. 认证器用私钥对challenge签名，服务器用保存的公钥验签，并校验来源与挑战。

// 注册阶段（简化示意）
const credential = await navigator.credentials.create({
  publicKey: {
    challenge: serverChallenge,
    rp: { id: "pay.example.com", name: "Example Pay" },
    user: { id: userId, name: "user@example.com", displayName: "User" },
    pubKeyCredParams: [{ type: "public-key", alg: -7 }],
    authenticatorSelection: { userVerification: "required" }
  }
});

// 认证阶段（简化示意）
const assertion = await navigator.credentials.get({
  publicKey: {
    challenge: serverChallenge,
    allowCredentials: [{ id: credentialId, type: "public-key" }],
    userVerification: "required"
  }
});

三、案例/场景：支付场景为什么比普通登录更苛刻

普通登录允许一定的失败容忍度，而支付强认证同时面对四类硬约束：

这正是SPC（Secure Payment Confirmation）的出发点：它基于WebAuthn扩展，在认证签名中嵌入交易信息，使“用户确实授权了这笔支付”成为可验证的密码学事实，而不仅是页面上的一个按钮点击。对风控而言，这意味着争议处理、责任划分和合规审计都有了更强的证据链。

四、误区/复盘：常见认知偏差与落地教训

• 误区二：认为生物识别等于FIDO2。生物识别只是本地解锁认证器的一种方式，私钥仍在安全芯片中，生物特征不上传。
• 误区三：忽略rpId与来源绑定。配置错误会导致钓鱼站点无法被有效阻断，或合法子域无法使用。
• 误区四：不做降级与恢复设计。设备丢失、换机、跨平台是真实痛点，必须有安全的恢复与多认证器策略。

复盘来看，认证演进不是简单替换，而是安全模型、用户体验与合规责任三者的再平衡。密码和OTP不会一夜消失，但支付强认证的方向已经明确：用非对称密钥绑定设备与交易，用WebAuthn标准化接口，用SPC把“授权”变成可验证的签名。理解这条演进逻辑，是后续实战中做对架构选型与风控策略的前提。