这是 Beta 探索课程，内容结构、实验步骤和示例可能会继续调整。
认证系统的四大目标与取舍
四个目标
产品出事之后，我不再把认证当成「登录功能」来写，而是把它当成一套要长期演进的系统。设计前，我先明确了它要满足的四个目标：
| 目标 | 含义 | 反面教材 |
|---|---|---|
| 安全 | 密码不泄露、Token 难伪造、会话可撤销 | 数据库泄露后，攻击者直接拿到明文密码 |
| 体验 | 用户不频繁重登、正常操作不被过度打扰 | 每次打开 App 都要重新输入密码 |
| 可控 | 管理员能冻结账号、强制下线、追踪登录历史 | 账号被盗后，用户找不到异常设备，无法撤销 |
| 可扩展 | 能接移动端、第三方登录、SSO、MFA | 新增一个端就要重写一套登录逻辑 |
这四个目标天然互相打架，没有银弹，只有取舍。
目标之间的冲突
先看最常见的几组矛盾：
安全 ↔ 体验
- 会话时间越长，用户越省事，但凭证泄露后的风险窗口越大。
- 验证越严格（每次 MFA），安全越高，但登录转化率可能下降。
可控 ↔ 体验
- 要求所有设备强制下线、频繁重新认证，管理员更可控，但用户很烦。
- 允许用户「登录后一直有效」，体验顺滑，但一旦账号被盗很难及时止损。
可扩展 ↔ 安全
- 为了支持多端多系统，Token 要能跨服务传递（如 JWT），但无状态的 JWT 撤销困难。
- 为了可撤销，保留服务端会话，又要付出每次请求查询的存储和延迟成本。
取舍的原则
踩过坑之后，我总结出一条主线：把摩擦放在风险最高的地方，而不是均匀地打扰所有人。
具体来说：
- 常用设备、低风险操作：顺滑放行。
- 新设备、异地、高风险操作：加强验证。
- 凭证泄露风险窗口：用短有效期 + 可撤销机制控制。
- 身份变更（改密、改邮箱）：必须先重新确认本人。
这就是后面会反复出现的风险驱动设计：先问「这一步出错会造成多大损失」，再决定「这里要付出多少安全成本」。
本课程的学习路线
沿着这条主线，课程会按下面的顺序展开：
- 认证系统概述：边界与目标（本页）。
- 认证基础：账号密码登录，把「证明身份」的第一步做扎实。
- Token 认证：登录成功后，如何在后续请求中表达身份。
- 会话管理：登录态如何存储、续期、撤销，多设备如何处理。
- 单点登录 SSO：多个业务系统如何共享同一身份。
- OAuth 第三方登录：如何安全地接入 GitHub、微信等外部身份。
- 多因素认证 MFA：高风险场景如何做第二层确认。
- 完整系统：把前面所有能力整合成生产级架构。
- 回顾与总结：沉淀设计原则与关键决策。
下一章，我们从最基础的账号密码登录开始。
发现内容有问题？
告诉我们哪里需要改进。