生物识别正在成为Web登录的主流方式，Web Authentication（简称WebAuthn）规范让网站可以调用设备上的指纹、面容或PIN完成身份核验。在这种架构里，服务端并不保存密码，而是存储用户注册时认证器生成的公钥凭据。对于中小型项目，部署一个独立的PostgreSQL或MySQL实例成本偏高，而SQLite以单文件形式嵌入进程，既能满足并发读取，又方便备份与迁移。本文围绕如何把SQLite与Web Authentication结合起来，搭建一套可落地的生物认证登录系统展开。
Web Authentication的核心流程与凭据模型
WebAuthn定义了两个关键操作：注册（registration）和认证（authentication）。注册时，浏览器向认证器请求生成一对非对称密钥，私钥留在设备内，公钥和凭证ID（credential ID）返回给网站。认证时，服务端发出随机挑战（challenge），浏览器用私钥对挑战签名，服务端用之前存储的公钥验证签名是否有效。整个过程密码不会离开用户设备，中间人即便截获流量也无法重放。
在服务端视角下，每个用户可能绑定多个认证器，比如手机指纹和笔记本面容。因此凭据模型应当是「用户一对多凭据」。SQLite虽然没有原生的数组类型，但可以通过独立的凭据表，用用户ID做外键关联来解决。除了公钥，还需要保存凭证ID（用于告诉浏览器用哪个认证器）、签名计数器（防止克隆）以及认证器附加信息（如AAGUID）。
挑战码必须每次请求动态生成，且具备时效性。通常可以把挑战码明文暂存在SQLite的会话表中，设置过期时间字段，认证完成后立即删除。这样即便进程重启，未完成的挑战也不会残留导致安全问题。理解这套模型，是设计SQLite表结构的前提。
SQLite表结构设计与代码实现
我们需要三张表：用户表、凭据表、挑战表。用户表保存基础身份；凭据表保存WebAuthn注册信息；挑战表保存临时随机值。下面给出建表语句，注意凭据表中的公钥使用BLOB类型存储，因为WebAuthn返回的公钥是二进制DER格式，直接以字节保存最稳妥。
以下SQL在SQLite中执行，使用了外键约束确保数据一致性。凭据表的counter字段是INTEGER，用于记录认证器返回的签名计数，每次登录后更新为最新值，若发现新计数小于旧计数则判定认证器可能被克隆。
CREATE TABLE users ( id INTEGER PRIMARY KEY AUTOINCREMENT, username TEXT UNIQUE NOT NULL ); CREATE TABLE credentials ( id INTEGER PRIMARY KEY AUTOINCREMENT, user_id INTEGER NOT NULL, credential_id BLOB UNIQUE NOT NULL, public_key BLOB NOT NULL, counter INTEGER NOT NULL DEFAULT 0, aaguid TEXT, created_at TEXT DEFAULT CURRENT_TIMESTAMP, FOREIGN KEY (user_id) REFERENCES users(id) ); CREATE TABLE challenges ( id INTEGER PRIMARY KEY AUTOINCREMENT, user_id INTEGER, challenge BLOB NOT NULL, expire_at TEXT NOT NULL, FOREIGN KEY (user_id) REFERENCES users(id) );
在Node.js环境中，可以使用better-sqlite3驱动操作上述结构。注册时先把挑战写入challenges表，前端完成注册后将凭证ID和公钥插入credentials表。下面是一段简化的注册存储逻辑，展示了如何把ArrayBuffer转换为Node的Buffer再存入SQLite。
const db = require('better-sqlite3')('app.db');
const crypto = require('crypto');
function saveCredential(userId, credentialId, publicKey, counter, aaguid) {
const stmt = db.prepare(
'INSERT INTO credentials (user_id, credential_id, public_key, counter, aaguid) VALUES (?, ?, ?, ?, ?)'
);
stmt.run(
userId,
Buffer.from(credentialId),
Buffer.from(publicKey),
counter,
aaguid
);
}
function createChallenge(userId) {
const challenge = crypto.randomBytes(32);
const expire = new Date(Date.now() + 5 * 60 * 1000).toISOString();
db.prepare('INSERT INTO challenges (user_id, challenge, expire_at) VALUES (?, ?, ?)')
.run(userId, challenge, expire);
return challenge;
}
这种设计的优势在于单文件、零配置，特别适合边缘节点或演示项目。如果未来用户量增长，只需把驱动替换为远程数据库，表结构基本可复用。同时BLOB存储避免了Base64编码带来的空间浪费和转义麻烦。
认证校验逻辑与安全防护要点
用户登录时，服务端先查challenges表取出有效挑战，连同允许的凭证ID列表发给前端。浏览器唤起认证器，用户 biometric 验证后返回签名和认证数据。服务端根据凭证ID从credentials表取出公钥和旧计数器，使用@simplewebauthn/server之类的库验证签名，并检查计数器是否递增。
验证通过后，必须立即删除对应的challenges记录，并更新credentials表中的counter。这一步很关键，否则同一个挑战可能被重复使用。SQLite的事务特性可以保证「更新计数器」和「删除挑战」要么同时成功要么同时失败，避免出现竞态条件。
const transaction = db.transaction((userId, newCounter, credId) => {
db.prepare('DELETE FROM challenges WHERE user_id = ?').run(userId);
db.prepare('UPDATE credentials SET counter = ? WHERE credential_id = ?')
.run(newCounter, Buffer.from(credId));
});
transaction(1, 12, credentialId);
除了上述流程，还要注意SQLite文件本身的权限。数据库文件应禁止Web用户直接下载，建议放在项目根目录之外的路径，例如/var/lib/app/auth.db。另外，虽然SQLite能应付每秒数千次读取，但高并发写入场景仍建议加WAL模式提升性能，只需执行PRAGMA journal_mode=WAL;即可。通过合理的表设计和事务控制，SQLite完全能够支撑一套安全、轻量的Web Authentication生物认证系统。
SQLiteWeb_Authenticationbiometric_authentication修改时间：2026-08-14 06:33:15