认证、授权与会话的边界

从一个周末开始

我的产品上线三个月，用户开始多起来了。

最开始一切都很简单：用户注册、登录、退出，我把账号密码存进一张表，登录成功就给一个 Cookie。那段时间我甚至觉得「认证」没什么好学的——不就是查一下数据库，密码对不对嘛。

直到有一天，用户群里有人喊：

我的账号怎么在别人手机上登录了？

我查了日志，发现那个账号连续一周都在凌晨从几个不同的省份登录，改了我的支付密码，还退了货。用户损失了钱，我也慌了。

那一刻我才意识到：认证不是一个接口，而是一套身份系统。 登录只是这套系统里最不起眼的一步。

三个经常被混在一起的概念

要设计好认证系统，先把三个概念分开：

很多事故都来自边界混淆：

• 登录成功，不代表拥有所有权限（认证 ≠ 授权）。
• Token 还没过期，不代表当前操作风险低（凭证有效 ≠ 会话可信）。
• 用户「已登录」，不代表一定是本人（Cookie 可能被窃取）。

一次登录背后发生了什么

我用一张图把「登录」拆开看。下面是一次最简单的密码登录需要经过的步骤：

认证系统的本质

把上面的流程再抽象一层，认证系统的本质是信任的生命周期管理：

1. 建立信任：通过凭证证明「你是谁」（密码、MFA）。
2. 延续信任：通过会话让后续请求记住你（Token、刷新、续期）。
3. 提升信任：通过风控和二次验证提高可信度（自适应 MFA）。
4. 收回信任：通过撤销让凭证失效（登出、冻结、强制下线）。
5. 追踪信任：通过审计日志还原发生了什么（登录、刷新、撤销记录）。

后面的课程，我会沿着这条主线一点点搭建：先做好账号密码这一步，再设计 Token 和会话，然后扩展到多系统单点登录和第三方 OAuth，最后补齐 MFA、风控和审计。

下一节我们看看，这套系统到底要满足哪些目标，以及这些目标之间怎么取舍。

上一章节

认证系统概述

下一章节

认证系统的四大目标与取舍