1. 认证基础：什么是身份认证？为什么需要认证？常见的认证方式
大家好，我是你们这趟实战课的老朋友。今天咱们先不急着敲代码，把地基打牢。身份认证这事儿，说白了就是回答三个问题：「你是谁？」「你凭什么证明？」「我怎么信你？」
我见过不少团队，上来就搞权限模型，结果认证环节漏了个口子，整个系统跟没锁门一样。所以第一章，咱们把认证的根儿捋清楚。
1.1 什么是身份认证？
身份认证，英文叫 Authentication。它的核心动作就一个：验证「声称的身份」是否属实。
你想想看，你登录银行 App，输入用户名和密码。系统不会直接信你，它得拿你输入的东西去数据库里比对。比对通过，才确认「嗯，你就是张三」。这个过程，就是认证。
一句话定义：身份认证是系统对用户所声称的数字身份进行真实性校验的过程。
它跟「授权」是两码事。认证只解决「你是不是你」，不解决「你能干什么」。我经常在项目复盘时发现，有人把认证和权限混在一起写，结果改个密码逻辑，权限也跟着崩了。记住，认证是认证，授权是授权，后面我们会专门讲怎么解耦。
1.2 为什么需要认证？
这个问题看似简单，但真往深了想，其实涉及三个层面。
- 防冒用：没有认证，任何人都可以冒充别人。我在金融项目里遇到过，一个内部工具没做认证，实习生用同事的账号误删了生产库的索引。嗯，那场面……
- 可追溯：认证是审计的基础。谁在什么时间做了什么操作，全靠认证留下的身份锚点。没有认证，日志就是一堆匿名垃圾。
- 权限前置条件：你连来的人是谁都不知道，怎么决定他能不能访问某个接口？认证是权限判断的「前置输入」。我曾经见过一个系统，权限模块自己维护了一份「用户身份缓存」，跟认证模块的数据经常不一致，导致权限乱跳。这就是典型的没把认证当独立层。
我的习惯：在设计任何系统时，先把认证层画出来，再画权限层。认证层只做一件事：输出一个可信的「用户身份令牌」。其他模块只认这个令牌，不自己查用户表。
1.3 常见的认证方式
认证方式五花八门，但万变不离其宗。我习惯把它们分成三大类，咱们一个一个看。
1.3.1 密码认证
这是最古老、也最普及的方式。你提供一个「你知道的东西」（密码），系统验证它。
- 优点：实现简单，用户习惯成熟。
- 缺点：容易被钓鱼、撞库、暴力破解。我见过太多人把密码设成 123456 或者 company@2024。
- 最佳实践：密码必须哈希存储（比如 bcrypt），绝对不能明文存。传输必须走 HTTPS。另外，加个验证码能挡掉大部分自动化攻击。
避坑指南：我曾经接手过一个遗留系统，密码用 MD5 哈希，连盐都没加。攻击者拿到数据库后，彩虹表一跑，80% 的密码直接还原。记住，MD5/SHA-1 不适合做密码哈希，要用专门的慢哈希算法。
1.3.2 生物特征认证
指纹、人脸、虹膜、声纹。这些属于「你是什么」的范畴。
- 优点：方便，不用记。你掏出手机扫个脸就解锁了。
- 缺点：生物特征是「不可撤销的密码」。你的指纹泄露了，你能换指纹吗？不能。所以生物特征通常只作为本地解锁的辅助手段，不直接作为网络传输的凭证。
- 我的建议：生物特征适合做「第二因素」或「本地设备解锁」，不适合做远程认证的唯一凭证。我在做移动端 SDK 时，都是把生物特征作为触发本地密钥释放的开关，而不是把指纹模板传到服务器。
1.3.3 OTP（一次性密码）
OTP 属于「你拥有的东西」。短信验证码、TOTP（基于时间的一次性密码）、HOTP（基于计数器的一次性密码）都算。
- 优点：即使密码泄露，攻击者没有 OTP 也进不来。能有效防御撞库和钓鱼（前提是用户不主动提供 OTP）。
- 缺点：短信 OTP 有被拦截的风险（SS7 攻击、SIM 卡克隆）。TOTP 相对安全，但用户需要额外装个 Authenticator App。
- 实现要点：TOTP 基于 RFC 6238，核心是共享密钥 + 当前时间窗口。我习惯在服务端生成密钥时，给每个用户绑定一个唯一的 seed，并限制 OTP 的有效期在 30 秒内。
三种方式对比：
| 维度 | 密码 | 生物特征 | OTP |
|---|---|---|---|
| 认证因子 | 你知道的 | 你是什么 | 你拥有的 |
| 可撤销性 | 高（改密码即可） | 低（不可更改） | 高（重新绑定设备） |
| 防钓鱼能力 | 低 | 中 | 高（配合 TOTP） |
| 用户体验 | 中（需要记忆） | 高（无感） | 中（需要额外操作） |
| 典型场景 | Web 登录 | 手机解锁、支付 | 双因素认证、转账确认 |
1.4 认证体系的核心逻辑图
下面这张图，是我自己画的一个认证体系框架。它把「认证方式」「认证因子」「认证结果」串在了一起。你以后设计任何认证模块，都可以拿这个图来对一下，看看缺了哪块。
1.5 多因素认证（MFA）
刚才我们聊了三种认证方式，它们各自有短板。密码怕泄露，生物特征怕不可撤销，OTP 怕拦截。那怎么办？组合起来用。
多因素认证（MFA）要求用户提供至少两种不同类别的认证因子。比如：
- 密码 + 短信 OTP（知识因子 + 持有因子）
- 密码 + 指纹（知识因子 + 固有因子）
- 硬件密钥 + PIN 码（持有因子 + 知识因子）
我个人的经验是：MFA 不是简单的「多一步验证」，而是「不同维度的验证」。如果两个因素都属于同一类（比如密码 + 密保问题，都是知识因子），那其实不算真正的 MFA，因为一旦知识因子层面被攻破，两个一起完蛋。
实战建议：在 Web 系统中，我通常推荐「密码 + TOTP」作为标准 MFA 方案。TOTP 不依赖短信通道，安全性高，而且 Google Authenticator 或 Authy 都是免费的。实现时注意：给用户一个 recovery code（恢复码），防止手机丢失后无法登录。
1.6 认证的常见误区
最后，我列几个自己踩过的坑，或者帮别人擦过的屁股。你记一下，以后能省不少事。
| 误区 | 问题 | 正确做法 |
|---|---|---|
| 密码明文存储 | 数据库泄露 = 所有账号裸奔 | 使用 bcrypt/scrypt/Argon2 哈希 |
| OTP 有效期过长 | 给了攻击者充足的时间窗口 | 短信 OTP 5 分钟内失效，TOTP 30 秒 |
| 生物特征作为网络传输凭证 | 特征值一旦泄露，无法更换 | 生物特征只做本地设备解锁，不上传原始数据 |
| MFA 只加一步，不区分因子类别 | 两个知识因子等于没加 | 必须组合不同类别的因子 |
| 认证日志不记录失败原因 | 排查攻击时无从下手 | 记录「用户不存在」「密码错误」「OTP 过期」等具体原因 |
再啰嗦一句：认证是安全的第一道门。这道门没做好，后面权限设计得再花哨，也是白搭。我见过太多「权限模型很完美，但认证被绕过」的案例了。所以，花时间把认证搞扎实，绝对值。
好，第一章就到这里。内容不多，但都是基础中的基础。你先把这些概念刻在脑子里，后面我们聊 Session、Token、OAuth 2.0 的时候，你会发现今天讲的这些东西一直在被引用。