WebAuthn通过非对称加密实现无密码登录，注册时生成密钥对并将公钥存于服务器，登录时由设备私钥签名挑战完成认证，私钥永不传输，有效防范钓鱼、凭证填充等攻击，提升安全性与用户体验。
用Web Authentication API实现无密码登录，本质上就是用一种更安全、更便捷的方式来证明“你是你”，而不再依赖那些容易被破解、遗忘的传统密码。它利用了设备内置的安全硬件（比如指纹识别器、面部识别、TPM芯片，或者外接的安全密钥），通过加密学手段，让你的设备为你生成并管理一对密钥——私钥留在设备里绝不外出，公钥则交给服务器。登录时，你的设备用私钥签名一个由服务器发来的“挑战”，服务器用存储的公钥验证签名，整个过程你的私钥从未暴露，也就不存在被窃取或钓鱼的风险。这不光提升了安全性，还大大简化了登录流程，体验上简直是质的飞跃。
解决方案
要实现WebAuthn的无密码登录，我们需要在客户端（浏览器）和服务器端进行协同工作。这并非一蹴而就，它涉及到两个核心阶段：注册（Attestation）和认证（Assertion）。
在注册阶段，当用户决定启用无密码登录时，服务器会生成一个随机的“挑战”（challenge），并将其发送给客户端。客户端的JavaScript代码会调用
navigator.credentials.create()
方法，并传入这个挑战以及一些关于用户和依赖方（即你的网站）的信息。此时，浏览器会调起设备的认证器（比如指纹、面部识别或要求插入安全密钥），用户完成验证后，认证器会生成一对新的加密密钥：私钥安全地存储在设备内部，而公钥、一个凭证ID（credential ID）以及一些元数据则会被返回给浏览器。浏览器再将这些信息发送回服务器。服务器收到后，会验证这些信息的合法性（这个过程称为“Attestation验证”），确认无误后，便会将公钥和凭证ID等信息存储起来，与用户的账户关联。
// 客户端注册示例 (简化版)async function registerWebAuthn() { try { // 1. 从服务器获取挑战和用户相关信息 const response = await fetch('/api/webauthn/register/options'); const options = await response.json(); // 2. 转换为ArrayBuffer（WebAuthn API需要） options.challenge = base64UrlToBuffer(options.challenge); options.user.id = base64UrlToBuffer(options.user.id); // ... 其他ArrayBuffer转换 // 3. 调用WebAuthn API创建凭证 const credential = await navigator.credentials.create({ publicKey: options }); // 4. 将创建的凭证发送回服务器进行验证和存储 const attestationResponse = { id: credential.id, rawId: bufferToBase64Url(credential.rawId), response: { clientDataJSON: bufferToBase64Url(credential.response.clientDataJSON), attestationObject: bufferToBase64Url(credential.response.attestationObject), }, type: credential.type, }; await fetch('/api/webauthn/register/verify', { method: 'POST', headers: { 'Content-Type': 'application/json' }, body: JSON.stringify(attestationResponse) }); alert('无密码登录已成功注册！'); } catch (error) { console.error('注册失败:', error); alert('注册失败，请重试。'); }}
到了认证阶段，当用户尝试登录时，服务器同样会生成一个新的挑战。客户端调用
navigator.credentials.get()
方法，传入这个挑战以及之前注册时获得的凭证ID（如果用户有多个凭证，可以不指定，让浏览器去发现）。浏览器再次调起设备的认证器进行用户验证。验证成功后，认证器会使用之前存储的私钥对挑战进行签名，并将签名结果（一个“断言”Assertion）返回给浏览器。浏览器再将这个断言发送回服务器。服务器收到断言后，会使用之前存储的公钥来验证这个签名。如果签名有效，且挑战、来源等信息都匹配，那么服务器就认为用户已经成功认证，可以登录了。
// 客户端登录示例 (简化版)async function loginWebAuthn() { try { // 1. 从服务器获取挑战 const response = await fetch('/api/webauthn/login/options'); const options = await response.json(); // 2. 转换为ArrayBuffer options.challenge = base64UrlToBuffer(options.challenge); options.allowCredentials.forEach(cred => { cred.id = base64UrlToBuffer(cred.id); }); // 3. 调用WebAuthn API获取凭证 const credential = await navigator.credentials.get({ publicKey: options }); // 4. 将获取的凭证发送回服务器进行验证 const assertionResponse = { id: credential.id, rawId: bufferToBase64Url(credential.rawId), response: { clientDataJSON: bufferToBase64Url(credential.response.clientDataJSON), authenticatorData: bufferToBase64Url(credential.response.authenticatorData), signature: bufferToBase64Url(credential.response.signature), userHandle: credential.response.userHandle ? bufferToBase64Url(credential.response.userHandle) : null, }, type: credential.type, }; const verifyResponse = await fetch('/api/webauthn/login/verify', { method: 'POST', headers: { 'Content-Type': 'application/json' }, body: JSON.stringify(assertionResponse) }); if (verifyResponse.ok) { alert('登录成功！'); // 跳转到用户主页 } else { throw new Error('服务器验证失败'); } } catch (error) { console.error('登录失败:', error); alert('登录失败，请重试。'); }}
base64UrlToBuffer
和
bufferToBase64Url
是辅助函数，用于在Base64Url编码的字符串和ArrayBuffer之间转换，因为WebAuthn API和JSON传输通常需要这种转换。在实际项目中，你可能会使用一些现成的库来处理这些细节，比如Node.js端的
@simplewebauthn/server
或Python的
fido2
库。
服务器端的工作，除了生成挑战、存储公钥，最关键的是对客户端发来的Attestation和Assertion进行严格的验证。这包括检查挑战是否匹配、来源（origin）是否正确、签名是否有效、以及处理各种标志位（如用户验证状态、凭证计数器等）以防止重放攻击。这部分逻辑虽然复杂，但有标准规范可循，并且有许多开源库可以帮助我们实现。
WebAuthn相较于传统密码，究竟安全在哪里？
这个问题，其实触及了WebAuthn的根本价值。它不仅仅是“方便”那么简单，其安全性的提升是革命性的。我个人觉得，WebAuthn最核心的优势在于它从根本上解决了传统密码体系的几个顽疾。
首先，它对网络钓鱼（Phishing）有天然的免疫力。传统密码的问题在于，你的秘密（密码）需要被你输入到某个地方。钓鱼网站就是利用这一点，诱骗你在一个假冒的网站上输入密码。一旦你输入了，密码就被窃取了。但WebAuthn不同，你的私钥从未离开过你的设备，也从未被发送到任何服务器。认证过程是设备与服务器之间通过加密挑战-响应机制完成的。即使你访问了一个钓鱼网站，它也无法获取你的私钥，也无法伪造出有效的签名。你的浏览器和认证器会检查网站的域名（Origin），如果与注册时的域名不符，认证就不会成功。
其次，它有效抵御了凭证填充（Credential Stuffing）和暴力破解攻击。很多人习惯在不同网站使用相同或相似的密码。一旦某个网站的数据库被攻破，泄露的密码就会被攻击者用来尝试登录其他网站，这就是凭证填充。WebAuthn为每个网站生成唯一的密钥对，即使一个网站的公钥被泄露，也无法用于登录其他网站。而且，私钥是硬件保护的，无法被暴力破解。
再者，它利用了硬件级别的安全。大多数WebAuthn认证器都利用了设备上的安全芯片（如TPM、Secure Enclave），这些硬件被设计成极难被物理篡改或提取内部密钥。这比软件层面的加密要强大得多，因为即使操作系统被恶意软件攻破，私钥仍然可能安全地保存在硬件中。
最后，它消除了密码存储和传输的风险。服务器不再需要存储用户密码的哈希值，只需存储公钥。公钥是公开的，即使被泄露也无法用于逆向推导出私钥。这大大降低了服务器端数据泄露的风险。从我的角度看，这种从“共享秘密”到“非对称加密”的范式转变，才是WebAuthn带来安全革命的精髓所在。
WebAuthn的注册与登录流程，具体是怎样运作的？
要理解WebAuthn的运作，我们可以把整个过程想象成一场精心设计的“身份验证舞步”，其中服务器、浏览器和认证器（你的设备）各司其职，步步为营。
注册（Attestation）流程：
用户意图： 用户在你的网站上点击“启用无密码登录”或“注册”按钮。服务器发起挑战： 你的服务器收到请求，生成一个高度随机的
challenge
（挑战值），以及一些关于你的网站（依赖方RP）和用户的信息（如用户ID、用户名）。这些信息会打包成一个
PublicKeyCredentialCreationOptions
对象，发送给客户端浏览器。这个挑战值是临时的，用过即废，防止重放攻击。浏览器与认证器交互： 客户端的JavaScript收到这些选项后，会调用
navigator.credentials.create(options)
。浏览器接下来会接管，它会根据
options
中的要求，与用户设备上的认证器（可能是指纹传感器、面部识别模块，或者一个外接的YubiKey等）进行沟通。用户验证与密钥生成： 认证器会提示用户进行验证，比如让你按指纹、扫脸，或者输入PIN码。一旦用户成功验证，认证器内部会生成一对全新的加密密钥：一个私钥和一个公钥。私钥被安全地存储在认证器内部，永不离开。同时，认证器还会生成一个
credential ID
（凭证ID）来唯一标识这对密钥。返回Attestation对象： 认证器将公钥、凭证ID以及一个
attestationObject
（包含认证器对这些信息的“证明”，证明它是真实合法的认证器生成的）打包，返回给浏览器。浏览器转发： 浏览器将收到的
PublicKeyCredential
对象（其中包含了公钥、凭证ID和attestationObject）发送回你的服务器。服务器验证与存储： 服务器收到这些数据后，会进行一系列严格的验证：检查
challenge
是否与之前发出的匹配。验证
origin
（网站来源）是否正确。解析并验证
attestationObject
，确认公钥的来源和合法性。确认无误后，服务器会将这个公钥和凭证ID与用户的账户关联并安全存储起来。
登录（Assertion）流程：
用户意图： 用户访问你的网站，点击“无密码登录”按钮。服务器发起挑战： 你的服务器再次生成一个新的随机
challenge
，并将其发送给客户端。这次它会打包成
PublicKeyCredentialRequestOptions
对象，其中可能包含一个
allowCredentials
列表，告诉浏览器用户可能有哪些凭证ID可用（如果服务器知道）。浏览器与认证器交互： 客户端JavaScript调用
navigator.credentials.get(options)
。浏览器再次接管，它会根据
options
中的要求，以及
allowCredentials
列表（如果提供），去查找或提示用户选择一个认证器。用户验证与签名： 认证器会提示用户进行验证（指纹、面部或PIN）。验证成功后，认证器会使用内部存储的私钥，对服务器发来的
challenge
进行加密签名。返回Assertion对象： 认证器将签名结果（一个
signature
）、
authenticatorData
（包含一些认证器状态信息）以及
clientDataJSON
（包含挑战、来源等）打包成一个
Assertion
对象，返回给浏览器。浏览器转发： 浏览器将收到的
PublicKeyCredential
对象（其中包含了签名等信息）发送回你的服务器。服务器验证： 服务器收到这些数据后，再次进行严格验证：检查
challenge
是否与之前发出的匹配。验证
origin
是否正确。使用之前注册时存储的公钥，来验证
signature
是否有效。这是最关键的一步，只有私钥才能生成这个有效的签名。检查
authenticatorData
中的标志位，比如用户是否真的在场（User Presence）或用户是否被验证（User Verification）。验证凭证计数器（
signCount
）是否递增，以防止重放攻击。所有验证通过后，服务器就确认用户身份，完成登录。
整个过程中，私钥从未离开用户的设备，服务器也只存储公钥，这种设计从根本上提升了安全性。
在实际应用WebAuthn时，会遇到哪些挑战，又该如何应对？
虽然WebAuthn前景光明，但在实际落地过程中，我们确实会遇到一些挑战，这很正常，任何新技术都有其磨合期。
一个很现实的问题是兼容性与用户教育。并非所有用户的设备和浏览器都完美支持WebAuthn的所有功能，尤其是老旧设备。比如，有些设备可能只支持平台认证器（如指纹），不支持跨平台认证器（如USB安全密钥）。我们不能指望用户一下子就理解“认证器”、“私钥公钥”这些概念。应对策略： 提供优雅的降级方案是关键。WebAuthn不应该是一个强制性的唯一登录方式，而应该作为一种增强选项。如果用户的设备不支持，或者他们选择不使用，那么传统的邮箱/密码登录、短信验证码等备用方案仍然需要存在。同时，在用户界面上，我们需要用简单易懂的语言解释WebAuthn的优势，并提供清晰的引导，例如“使用指纹/面部识别安全登录”而不是“注册FIDO2凭证”。
其次是账户恢复机制。如果用户丢失了所有注册了WebAuthn的设备，或者安全密钥损坏/丢失，他们该如何找回账户？这是很多开发者会忽略但又极其重要的一点。无密码登录固然方便，但如果失去了恢复能力，用户体验会很糟糕。应对策略： 建立多重恢复方案。
多设备注册： 鼓励用户在多个设备（如手机和电脑）上注册WebAuthn凭证，或者注册多个安全密钥。这样即使丢失一个，还有备用。备用验证方式： 仍然保留传统的账户恢复流程，比如通过绑定的邮箱或手机号进行验证。但这通常需要更严格的验证流程，以防止滥用。恢复码： 可以考虑在注册WebAuthn时，生成一组一次性使用的恢复码，让用户妥善保管，以备不时之需。
再来是服务器端实现的复杂性。WebAuthn的协议细节相当复杂，涉及大量的加密学操作、数据编码解码、挑战验证、Attestation验证、Assertion验证等。自己从头实现一套符合规范的服务器端逻辑，工作量大且容易出错。应对策略： 利用成熟的开源库或SDK。社区中已经有很多优秀的WebAuthn服务器端库，例如Node.js的
@simplewebauthn/server
、Python的
fido2
、Java的
WebAuthn4J
等。这些库封装了大部分复杂的协议细节，大大降低了开发难度，并且经过了社区的检验，可靠性更高。
最后，用户体验的一致性问题。不同的认证器（Windows Hello、macOS Touch ID、Android指纹、YubiKey等）在交互流程和界面上可能存在差异，这可能导致用户在不同设备上体验不一致。应对策略： 在前端设计时，尽量提供统一的引导和说明。例如，当调用
navigator.credentials.create()
或
get()
时，可以在UI上显示一个友好的提示，告知用户接下来可能会看到设备的原生认证界面，并解释可能的操作（如“请按指纹”、“请插入安全密钥并轻触”）。这有助于减少用户的困惑。
总的来说，WebAuthn的实施是一个系统工程，需要客户端、服务器端和用户教育的协同。虽然有挑战，但它带来的安全和便捷性提升是值得我们投入精力的。
以上就是如何用Web Authentication API实现无密码登录？的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/1521899.html
微信扫一扫 
支付宝扫一扫 
