Highlight
Apple 将 Face ID 和 Touch ID 作为 WebAuthn 平台认证器开放给 Safari 网站，让用户在完成一次传统登录后，用设备私钥和生物识别完成后续登录。
核心内容
很多高安全网站会要求用户隔一段时间重新登录。银行、支付、后台管理系统都常见。传统流程通常是用户名、密码、短信验证码连着来。iOS 的 AutoFill 已经减少了一些输入，但用户仍要判断字段、等待验证码、切换注意力。
这场 Session 用一个名叫 Shiny 的演示网站说明 Safari 的新路径：用户先用原有凭据登录一次，网站随后询问是否开启 Face ID 或 Touch ID。开启后，下次重新登录时，Safari 弹出确认界面，用户完成生物识别，网站拿到 Web Authentication API（WebAuthn）返回的凭据，再在服务器端验证。
WebAuthn 的关键变化是认证材料不再是可被复用的密码。网站是 relying party（依赖方），浏览器创建 PublicKeyCredential（公钥凭据），私钥由 authenticator（认证器）管理。Apple 的平台认证器把 Face ID 或 Touch ID 与 Secure Enclave 结合起来：用户拥有这台设备，同时通过生物识别验证身份。
这也解释了它为什么适合做“后续登录”的快速通道。凭据只能在创建它的网站使用，私钥不能从认证器导出，钓鱼站点无法拿到可复用秘密。网站仍然需要保留密码、验证码或其他恢复方式，因为私钥绑定在设备上，用户丢设备时不能被锁死。
详细内容
先做能力检测
（06:49）接入从三个 promise-based API 入口开始。第一个入口是 PublicKeyCredential.isUserVerifyingPlatformAuthenticatorAvailable。它返回布尔值，告诉页面当前设备能否使用具备用户验证能力的平台认证器。
// Feature detection
const isAvailable = await PublicKeyCredential.isUserVerifyingPlatformAuthenticatorAvailable();
if (isAvailable) {
// Continue to enrollment or sign in
// ...
}关键点：
PublicKeyCredential是 WebAuthn 中代表公钥凭据的浏览器 API。isUserVerifyingPlatformAuthenticatorAvailable()检测的是平台内置认证器，例如带 Face ID 或 Touch ID 的设备。isAvailable为真时，页面才进入注册或登录提示。- Session 明确建议使用 feature detection，不要用 user-agent 字符串判断。
注册时创建 PublicKeyCredential
（07:56）用户应该先用传统方式登录。网站确认用户身份后，再展示开启 Face ID 或 Touch ID 的通知。用户同意后，页面调用 navigator.credentials.create，让 Safari 处理确认 UI，并返回一个 PublicKeyCredential。
// Enrollment
const options = {
publicKey: {
rp: { name: "example.com" },
user: {
name: "[email protected]",
id: userIdBuffer,
displayName: "John Appleseed"
},
pubKeyCredParams: [ { type: "public-key", alg: -7 } ],
challenge: challengeBuffer,
authenticatorSelection: { authenticatorAttachment: "platform" },
attestation: "direct"
}
};
const publicKeyCredential = await navigator.credentials.create(options);关键点：
rp告诉浏览器当前网站是谁，WebAuthn 把这个网站称为 relying party。user放入用户信息，服务器需要能把返回的凭据关联到这个账号。pubKeyCredParams声明网站希望使用的公钥凭据类型和加密算法。challenge是服务器生成的挑战值，用来防止重放。authenticatorAttachment: "platform"是这段代码的核心，要求使用平台认证器。attestation: "direct"是 Shiny 演示站点的安全选择。Transcript 说明 attestation 是可选能力，适合需要证明设备属性的场景。
（10:00）前端拿到的是注册响应，真正的信任建立在后端。服务器要保存 credential ID 和 public key data。它还要验证 client data、authenticator data；如果启用了 attestation，还要验证 attestation statement。
登录时取得 assertion
（11:24）注册完成后，网站可以把 Touch ID 或 Face ID 作为快速登录入口。Session 建议在注册时设置一个 server-side、secure、HttpOnly cookie，标记这个账号在这台设备上已经开启该能力。登录页看到这个标记后，就能展示快速路径。
// Sign in
const options = {
publicKey: {
challenge: challengeBuffer,
allowCredentials: [{
type: "public-key",
id: credentialIdBuffer,
transports: ["internal"]
}]
}
};
const publicKeyCredential = await navigator.credentials.get(options);关键点：
- 登录仍然从服务器发出的
challenge开始。 allowCredentials指定本次准备使用的 credential ID，Safari 可以给用户更直接的界面。transports: ["internal"]对应平台内置认证器。navigator.credentials.get(options)触发 Safari 的确认界面，并返回新的PublicKeyCredential。- 和注册一样，这个调用应该发生在用户主动触发的事件里。
（12:38）登录响应里的核心内容是 signature（签名）。服务器需要确认 user ID 属于站点用户、credential ID 关联到该用户、元数据有效，然后验证签名。验证通过后，才建立登录会话。
处理 attestation 与恢复路径
（05:39）Attestation 用来让网站确认设备具备它声明的安全属性。Transcript 同时提醒，糟糕的 attestation 设计会变成跨站追踪向量。Apple 的 Anonymous Attestation 会为每个 credential 生成唯一证书，避免网站用同一个 attestation certificate 串联用户账号。
（14:02）最重要的产品规则是：Face ID 和 Touch ID 应该是替代登录方式，不能是唯一登录方式。私钥绑定设备，设备丢失后，用户必须还能通过其他机制恢复账号。已经支持安全密钥的网站，还要考虑平台认证器和外置安全密钥的体验差异。
核心启发
-
给高频重新登录流程加一个 Face ID 快速通道
做什么：在用户用密码和验证码完成一次登录后，提示他为当前设备开启 Face ID 或 Touch ID。
为什么值得做：Session 的 Shiny 演示表明，后续登录可以从密码加短信验证码缩短为一次 Safari 确认和一次生物识别。
怎么开始：先接入
isUserVerifyingPlatformAuthenticatorAvailable()，只在支持平台认证器的设备上展示开启入口。 -
把 WebAuthn 注册结果纳入账号安全后台
做什么：保存 credential ID 和 public key data，让用户在账号安全页查看并移除已启用的设备。
为什么值得做：Transcript 要求服务器在注册时保存这些数据，后续登录也依赖 credential ID 与用户的关联关系。
怎么开始：从注册回调开始补齐服务端校验清单：client data、authenticator data、可选 attestation statement、credential ID、public key data。
-
为 WebAuthn 登录设计独立的恢复路径
做什么：把 Face ID 或 Touch ID 放在快速登录位置，同时保留密码、验证码或其他恢复入口。
为什么值得做：Apple 明确提醒私钥绑定在设备上，丢设备时不能把用户永久锁在账号外。
怎么开始：在启用 WebAuthn 前检查账号恢复流程，确保用户能在新设备上重新完成传统登录和注册。
-
只在需要证明设备属性时启用 attestation
做什么：普通网站默认不请求 attestation，高合规场景再评估是否需要设备制造商证明。
为什么值得做：Transcript 把 attestation 定位为可选安全能力，并说明它如果设计不当会产生隐私风险。
怎么开始：先按无 attestation 的注册响应完成上线；确有合规要求时，再验证 attestation statement，并关注 Apple Anonymous Attestation。
-
用安全 cookie 做设备级提示，不把它当成身份凭据
做什么：注册成功后设置 server-side、secure、HttpOnly cookie，只用来提示这个设备有快速登录入口。
为什么值得做：Session 建议用这种 cookie 获得更长久的设备标记，但真正的登录仍来自 WebAuthn 签名验证。
怎么开始：把 cookie 只接到登录页展示逻辑；服务器仍按 user ID、credential ID、元数据和签名完成认证。
关联 Session
- One-tap account security upgrades — 继续讲账号安全升级，覆盖 Sign in with Apple、强密码和 iCloud Keychain 密码管理器。
- Get the most out of Sign in with Apple — 讲登录请求、凭据状态、服务器通知和现有账号迁移。
- AutoFill everywhere — 补齐传统登录表单中的账号、密码和验证码自动填充体验。
- What’s new for web developers — 查看同年 Safari 与 WebKit 平台 API 的整体更新。
评论
GitHub Issues · utterances