认证授权方案设计
# 认证与授权方案设计
核心命题：从单体登录到微服务鉴权——如何设计一套安全、可扩展、对业务无侵入的认证授权体系？
# 01. 案例引入
一个真实事故：Token泄露导致越权访问、SSO票据过期全站崩、权限改造导致业务停摆。
# 02. 问题拆解
- 认证（你是谁）vs 授权（你能干什么）
- 有状态（Session）vs 无状态（JWT）的本质取舍
- 单点登录（SSO）的票据传递与注销传播
- OAuth2 授权码/密码/客户端模式的选择边界
# 03. 业界方案
| 方案 | 代表 | 优点 | 缺点 |
|---|---|---|---|
| Session + Cookie | 传统Web | 简单、服务端可控 | 不跨域、不适用App |
| JWT（无状态） | — | 去中心、天然跨服务 | 无法主动失效、体积大 |
| OAuth2 + OIDC | Keycloak/Auth0 | 标准化、第三方登录 | 理解成本高 |
| SSO（CAS） | 耶鲁CAS | 一次登录全站通 | 单点、性能瓶颈 |
| RBAC/ABAC | Shiro/Spring Security | 灵活权限模型 | 复杂场景配置爆炸 |
# 04. 设计原则
- 认证与授权分离（AuthN ≠ AuthZ）
- 令牌短生命周期 + 刷新机制
- 最小权限原则（默认deny，显式allow）
- 集中鉴权 + 本地缓存（降低网关压力）
# 05. 方案落地
- JWT结构设计（Header/Payload/Signature）+ 刷新Token双令牌机制
- OAuth2 授权码流程 + PKCE 扩展
- 网关统一鉴权 + 微服务本地鉴权二级体系
- 权限模型：RBAC → 演进 → ABAC
# 06. 踩坑反例
- JWT放太多信息 → Header膨胀 > 8KB
- 无状态Token不设黑名单 → 登出后仍可用
- OAuth2 redirect_uri 校验不严 → 授权码劫持
- 权限校验只做URL不做数据级 → 越权漏洞
# 07. 演进路线
- V1: 单体 Session → V2: JWT + 网关鉴权 → V3: OAuth2/OIDC + 服务网格
下一篇：14. API 网关设计方案
上次更新: 2026/06/28, 17:55:19
