Security（01）：认证鉴权——OAuth2、JWT、Session、SSO、RBAC
更新时间：2026-09-02。本文是
security/Security 领域第 01 篇，在 Security 总纲下。认证和鉴权是系统安全的第一道门。认证解决"你是谁"，鉴权解决"你能做什么"。Session vs JWT 各有优劣，OAuth2 解决第三方授权，RBAC 做权限控制。
本文要回答的问题
- 认证和鉴权有什么区别？认证先做还是鉴权先做？
- Session 和 JWT 各适用什么场景？优缺点对比？
- OAuth2 的四种授权流程（授权码、简化、密码、客户端）？
- SSO 单点登录怎么实现？CAS 原理？
- RBAC 权限模型是什么？ACL vs RBAC vs ABAC？
一、基础概念
认证（Authentication） → 你是谁？确认用户身份。 鉴权（Authorization） → 你能做什么？确认用户权限。
流程：
请求 → 认证（你是谁？）→ 鉴权（你能做吗？）→ 允许/拒绝
顺序：先认证，后鉴权。不认证不知道是谁，就没法鉴权。三种角色：
- 资源所有者（Resource Owner） → 用户
- 客户端（Client） → 第三方应用
- 授权服务器（Authorization Server） → 发放令牌
- 资源服务器（Resource Server） → 保护资源
二、Session vs JWT
Session 模式
流程：
用户登录 → 服务器生成 Session ID → Cookie 给浏览器
请求带着 Cookie → 服务器查找 Session → 验证身份
存储：
Session 存在服务器内存或数据库/Redis
优点：
服务端可控，随时可以注销
适合传统 Web 应用
缺点：
需要存储，服务器扩容要 Session 同步
Cookie 不能跨域
CSRF 攻击风险JWT 模式
JWT = JSON Web Token
结构：
Header.Payload.Signature
三部分用 . 分隔
Header：算法类型（HS256/RS256）
Payload：用户信息（sub、exp、iss）
Signature：签名 = HMAC-SHA256( base64(Header) + "." + base64(Payload), secret )
流程：
用户登录 → 服务器签名生成 JWT → 返回给客户端
请求带 JWT 放在 Authorization 头 → 服务器验签 → 通过
优点：
不需要服务端存储，服务扩容方便
支持跨域，适合微服务/SPA
可以自己携带信息
缺点：
不能主动注销（除非用黑名单）
Token 长度比 Session ID 大
一旦泄露，无法提前撤销（除非加黑名单）对比表：
| 对比 | Session | JWT |
|---|---|---|
| 存储 | 服务端 | 客户端 |
| 扩容 | 需要同步 | 天生分布式 |
| CORS | Cookie 跨域问题 | 无问题 |
| CSRF | 有风险 | 无风险 |
| 主动注销 | 容易，删 Session | 难，需要黑名单 |
| 适合场景 | 传统 Web | SPA/微服务 |
三、OAuth2 授权流程
OAuth2 解决"第三方应用要访问用户在另一个服务上的数据"问题。
四种授权流程：
1. 授权码流程（Authorization Code）
适用：服务器端 Web 应用，安全性最高
流程：
1. 用户点击"用 GitHub 登录" → 重定向到 GitHub 授权页
2. 用户登录 GitHub → GitHub 给回调地址返回授权码
3. 应用服务器用授权码 + client_id/client_secret 换 token
4. GitHub 返回 access_token → 应用拿到 token 访问用户信息
优点：
授权码在前端跳转，token 在后端交换
token 不会暴露给前端，安全性高
最推荐
缺点：
需要后端参与，流程复杂2. 隐式流程（Implicit）
适用：纯前端 SPA，没有后端
流程：
1. 用户点击"用 GitHub 登录" → 重定向到 GitHub
2. 用户登录 → 直接返回 access_token 到前端回调
3. 前端拿到 token 存在本地
优点：
简单，不需要后端
缺点：
token 暴露给前端，不安全
不推荐在生产用3. 密码流程（Password Credentials）
适用：可信应用，用户直接给用户名密码
比如自己公司开发的客户端 app
流程：
用户输入用户名密码 → app 直接用用户名密码换 token
不需要重定向跳转
优点：
简单，用户体验好
缺点：
app 需要保存用户名密码，不安全
只适合可信内部应用4. 客户端流程（Client Credentials）
适用：机器对机器，服务之间调用
没有用户，服务自己要访问接口
流程：
服务 → client_id + client_secret 换 token
token 用于服务间认证
优点：
简单，适合服务间通信
场景：
微服务之间调用认证
后台定时任务调用 API总结： 90% 场景用 授权码流程（安全性高），服务间调用用 客户端流程。
四、SSO 单点登录
单点登录（Single Sign-On）：一次登录，多个系统都能访问。
CAS 原理（Central Authentication Service）：
三个系统：
CAS Server：认证中心，统一登录
App1：应用 1
App2：应用 2
流程（用户第一次访问 App1）：
1. 用户访问 App1 → App1 发现没登录 → 重定向到 CAS Server
2. CAS Server 发现没登录 → 用户输入用户名密码登录
3. CAS Server 生成 TGT（Ticket Granting Ticket）存在 Cookie
4. CAS Server 生成 ST（Service Ticket）→ 重定向回 App1
5. App1 拿 ST 去 CAS Server 验证 → 验证通过，得到用户信息 → 登录成功
用户访问 App2：
1. 用户访问 App2 → App2 发现没登录 → 重定向到 CAS Server
2. CAS Server 发现 Cookie 已有 TGT → 直接生成 ST → 重定向回 App2
3. App2 验证通过 → 登录成功，不需要再输入密码
结论：一次登录，多个系统都能用，就是这么简单。CAS 核心： TGT 存在 CAS 域名下 Cookie，所有应用重定向到 CAS 都能拿到 TGT，不需要重新登录。
五、权限模型：ACL vs RBAC vs ABAC
1. ACL（Access Control List，访问控制列表）
ACL 直接把权限绑定到用户：
文件系统 ACL 示例：
文件 /etc/passwd
user root: rw
user alice: r
group users: r
缺点：
用户多了，权限列表爆炸
不好管理2. RBAC（Role-Based Access Control，基于角色的访问控制）
RBAC：用户 → 角色 → 权限
用户 alice → 角色 admin → 权限：读所有、写所有
用户 bob → 角色 user → 权限：只能读自己
优点：
管理简单，增删用户只需要分配角色
大多数场景够用
场景：绝大多数企业系统，都用 RBAC3. ABAC（Attribute-Based Access Control，基于属性的访问控制）
ABAC 根据属性判断：
用户属性（部门、级别）
资源属性（类型、创建者）
环境属性（时间、IP）
规则示例：
市场部员工 → 只能工作日 9-18 点访问市场部文档
只有公司内网 IP 才能访问
优点：
灵活，能表达复杂规则
缺点：
规则复杂，性能差
调试困难选型建议：
| 需求 | 推荐 |
|---|---|
| 简单系统，权限固定 | RBAC |
| 复杂动态权限 | ABAC |
| 文件系统/操作系统 | ACL |
六、常见坑对照
| 错误 | 现象 | 对策 |
|---|---|---|
| JWT 存在 localStorage | XSS 容易偷走 | 存在 HttpOnly Cookie 中 |
| JWT 不设过期 | token 永远有效 | 必须设 exp，定期刷新 |
| OAuth2 隐式流程 | token 暴露给前端 | 尽量用授权码流程 |
| 没有 HTTPS | token 被中间人窃听 | 必须 HTTPS |
| RBAC 权限粒度过细 | 规则爆炸 | 先粗后细，不要一开始就做细粒度 |
相关与延伸
下一篇：加密算法——对称加密（AES）、非对称加密（RSA/ECC）、哈希、国密；网络安全 TLS 加密，见 网络安全——TLS/HTTPS 原理。
一句话总结
认证鉴权：认证确定你是谁，鉴权确定你能做什么，顺序先认证后鉴权；Session 存储在服务端，适合传统 Web；JWT 存储在客户端，适合微服务/SPA；OAuth2 四种流程：授权码（推荐，安全）、隐式（前端 SPA）、密码（可信应用）、客户端（服务间）；SSO 单点登录 CAS 流程：一次登录 CAS，所有系统免登录；权限模型：ACL（用户直接绑权限）、RBAC（角色授权，大多数场景用这个）、ABAC（属性规则，复杂权限）。