用户管理与多因素认证：把安全再加固一层

用户管理与多因素认证：把安全再加固一层

认证体系建立后，还需要日常的用户管理（查看、禁用、更新用户）以及针对高安全需求场景的多因素认证（MFA）。本节介绍这两部分，帮助你完整掌控用户生命周期与账号安全。

用户：不只是登录凭证

在 Supabase 中，一个用户远不止「邮箱 + 密码」。完整的用户对象通常包含：

• 唯一标识：用户 id（UUID），全系统通用。
• 登录凭证相关：邮箱/手机号、加密后的密码、关联的第三方身份。
• 元信息：昵称、头像、自定义属性等。
• 状态：是否已验证邮箱、是否被禁用、是否启用了 MFA。
• 时间戳：注册时间、最近登录时间。

由于用户数据就在数据库的用户表中，你可以用 SQL 或管理接口完成各类管理操作，业务表也能通过外键引用用户 id，把「数据归属」与「用户」牢牢绑定。

用户元信息：业务自定义字段

认证系统自带的用户表存放标准字段，而业务往往需要更多自定义信息（如用户的偏好设置、会员等级、个人简介）。常见两种做法：

1. 扩展用户表：在一张与用户 id 一一对应的「用户详情表」中存放业务字段，通过外键关联用户 id。这是推荐做法，保持认证表的纯净。
2. 使用用户元数据：Auth 允许在用户对象上附加一块元数据（user metadata），适合少量、灵活的属性。

经验法则：结构化、需要查询与索引的业务字段，放进独立的详情表；零散、动态、不需查询的属性，可放元数据。

用户管理操作

日常用户管理主要包括：

• 查询用户列表：按邮箱、注册时间、状态等筛选，用于后台管理。
• 更新用户信息：修改资料、调整状态。
• 禁用与解禁：对违规或可疑账号临时禁用，封禁其登录。
• 删除用户：永久移除（需谨慎，通常配合数据级联策略，见第 2 章外键的级联）。
• 重置密码 / 发起验证：辅助用户解决登录问题。

这些操作可通过控制台、管理接口或 SQL 完成。无论哪种途径，对用户数据的写操作都应受控、可审计，避免误操作影响真实用户。

账号关联：多个身份归一

一个用户可能先用邮箱注册，后来又绑定了 GitHub、Google。Supabase 支持把多个登录身份关联到同一个用户，让用户无论用哪种方式登录，都进入同一个账号、看到同一份数据。

设计账号关联时要考虑业务策略：

• 是否允许同一邮箱被不同身份自动合并？
• 多个身份的元信息以哪个为准？
• 解绑某个身份后，如何保证用户仍有至少一种登录方式？

多因素认证（MFA）：多一道防线

密码可能泄露、邮箱可能被盗，单一因素总有风险。多因素认证（MFA，Multi-Factor Authentication） 要求用户在登录时提供不止一种证明，大幅提升账号安全性。常见因素分三类：

• 知识因素：你知道的（密码）。
• 拥有因素：你拥有的（手机、认证器）。
• 固有因素：你本身的（指纹等生物特征）。

Supabase 支持基于时间的一次性密码（TOTP）这类拥有因素——用户用认证器 App 生成动态验证码，登录时除了密码还要输入验证码。

启用 MFA 后的登录流程：
1. 用户输入密码（第一因素）
2. 系统校验通过后，要求输入动态验证码（第二因素）
3. 验证码正确，才最终签发令牌
​

• 适用场景：对账号安全要求高的应用，如涉及资金、敏感数据、管理后台。
• 权衡：MFA 提升安全性但增加登录步骤，影响体验。常见做法是「可选启用」或「仅对高权限用户强制」。

登录安全辅助手段

除了 MFA，Supabase Auth 还提供若干辅助安全机制：

• 速率限制：限制同一 IP、同一账号的登录尝试频率，防暴力破解。
• 邮箱验证：注册后须点击验证链接，确保邮箱真实有效。
• 会话管理：查看与撤销用户的所有会话，应对异常登录。
• 密码强度策略：要求密码满足最小长度与复杂度。

这些机制层层叠加，构成纵深防御。

用户数据隐私与合规

管理用户数据时务必考虑隐私与合规：

• 最小收集：只收集业务必需的信息。
• 明确同意：收集与使用前获得用户知情同意。
• 安全存储：敏感字段加密，访问受控。
• 可删除：支持用户注销账号及删除其数据，符合隐私法规要求。

用户身份数据是最敏感的一类，处理不当会带来法律与声誉风险。设计认证体系时就把隐私合规纳入考量，而非事后补救。

小结

用户管理覆盖用户从注册到注销的完整生命周期，业务自定义信息建议放在与用户 id 关联的详情表；MFA 与速率限制、邮箱验证等手段共同加固账号安全。把认证、用户管理与多因素认证结合，你就构建了一套既灵活又安全、足以支撑真实业务的身份体系。

至此，第 4 章完成了对身份认证的完整讲解。第 5 章将在此基础上引入行级安全策略（RLS），学习如何利用已建立的用户身份，在数据库行级别精确控制数据访问。