这是 Beta 探索课程，内容结构、实验步骤和示例可能会继续调整。
认证、授权与会话的边界
从一个周末开始
我的产品上线三个月，用户开始多起来了。
最开始一切都很简单：用户注册、登录、退出，我把账号密码存进一张表，登录成功就给一个 Cookie。那段时间我甚至觉得「认证」没什么好学的——不就是查一下数据库，密码对不对嘛。
直到有一天，用户群里有人喊：
我的账号怎么在别人手机上登录了？
我查了日志，发现那个账号连续一周都在凌晨从几个不同的省份登录，改了我的支付密码，还退了货。用户损失了钱，我也慌了。
那一刻我才意识到：认证不是一个接口，而是一套身份系统。 登录只是这套系统里最不起眼的一步。
三个经常被混在一起的概念
要设计好认证系统，先把三个概念分开：
| 概念 | 回答的问题 | 对应的东西 |
|---|---|---|
| 认证 Authentication | 你是谁？ | 账号密码、短信验证码、MFA |
| 授权 Authorization | 你能做什么？ | 能否访问订单、是否是管理员 |
| 会话 Session | 系统如何记住你已登录？ | Cookie、Session、Token |
很多事故都来自边界混淆：
- 登录成功，不代表拥有所有权限（认证 ≠ 授权）。
- Token 还没过期，不代表当前操作风险低（凭证有效 ≠ 会话可信）。
- 用户「已登录」，不代表一定是本人（Cookie 可能被窃取）。
一次登录背后发生了什么
我用一张图把「登录」拆开看。下面是一次最简单的密码登录需要经过的步骤：
一次最简单的密码登录
用户在登录页输入账号密码
按账号查找用户
步骤 1 · 动作查不到就统一提示「账号或密码错误」用慢哈希验证密码
步骤 2 · 动作bcrypt / scrypt / Argon2，绝不存明文检查账号状态
步骤 3 · 判断是否冻结、是否未验证、是否需重置密码评估本次登录风险
步骤 4 · 判断新设备 / 异地 / 失败次数过多创建会话并签发凭证
步骤 5 · 结果Cookie / Token，决定后续请求如何证明身份登录成功，但信任管理才刚刚开始
认证系统的本质
把上面的流程再抽象一层，认证系统的本质是信任的生命周期管理：
- 建立信任：通过凭证证明「你是谁」（密码、MFA）。
- 延续信任：通过会话让后续请求记住你（Token、刷新、续期）。
- 提升信任：通过风控和二次验证提高可信度（自适应 MFA）。
- 收回信任：通过撤销让凭证失效（登出、冻结、强制下线）。
- 追踪信任：通过审计日志还原发生了什么（登录、刷新、撤销记录）。
后面的课程，我会沿着这条主线一点点搭建：先做好账号密码这一步，再设计 Token 和会话，然后扩展到多系统单点登录和第三方 OAuth，最后补齐 MFA、风控和审计。
下一节我们看看，这套系统到底要满足哪些目标，以及这些目标之间怎么取舍。