S07-A01 · 安全框架选型：Spring Security vs Shiro

适用读者：要决定"认证授权放哪、用哪个框架"的人。
前置：S07-B04。
版本基线：Spring Security 6.x / Shiro 2.x。
覆盖旧文：353(63) 475(38) 355(28) = 129 点。
覆盖扩展：E-S07-018（认证/授权/会话边界）。
上一篇：S07-J05 · 接口幂等：六种方案与选型
下一篇：S07-A02 · WebFlux vs MVC。

1. 一句话结论

认证（你是谁）与授权（你能干什么）应该由框架统一处理，而不是每个 Controller 里手写 token 校验。选型的核心是"团队与生态"，不是"功能多少"。

2. 先分清三件事（E-S07-018）

概念	问题	实现位置
认证（Authentication）	你是谁	登录接口 + 过滤器链
授权（Authorization）	你能做什么	方法注解/URL 规则
会话（Session）	你怎么保持登录态	Session / JWT / Token

常见误区：把"JWT 校验"当成"认证完成"——JWT 只是载体，认证是"验证签名 + 检查过期 + 加载用户"。

3. 两个框架对比

维度	Spring Security	Shiro
生态	Spring 官方，与 Boot 深度集成	独立，配置简单
学习曲线	陡（过滤器链概念多）	平缓
功能	OAuth2/OIDC、方法级安全、CSRF、会话管理	认证/授权/会话/加密
扩展	极强（自定义 Filter/Provider）	较强
适合	Spring 技术栈、需要 OAuth2/SSO	老项目、简单权限模型

判据：

技术栈是 Spring Boot？
├── 是 → Spring Security（除非只需极简权限）
└── 否 → Shiro
需要 OAuth2/SSO/OIDC？→ Spring Security

4. 架构层面：放网关还是放服务

方案	优点	缺点
网关统一认证	服务无需重复实现	网关成为单点；细粒度授权仍需服务
服务内认证	独立、无单点	重复实现、配置分散
混合（推荐）	网关做认证 + 服务做细粒度授权	需要约定上下文传递（Header/Token）

判据："授权规则会随业务频繁变化吗？" 会 → 放服务；不会且很粗 → 可放网关。

5. JWT 的四个注意点（A-355）

注意	说明
不可撤销	签发后无法主动失效（需黑名单/短过期）
体积	放在 Header 里，太大影响每个请求
敏感信息	payload 是 base64，不是加密
刷新机制	短 access token + 长 refresh token

6. 五个误区

误区	真相
"JWT 就是认证"	只是凭证载体
"Shiro 过时了"	简单场景仍好用
"认证放网关就不用管授权"	细粒度授权仍在服务
"Token 里可以放敏感信息"	payload 可被解码
"登录态越长越好"	泄露窗口更大

7. 自检（架构师版）

认证、授权、会话三者的边界？
Spring Security 与 Shiro 各自的优势场景？
认证放网关的代价是什么？
JWT 为什么"不可撤销"？怎么缓解？
为什么授权规则频繁变化的系统不该把授权放网关？

8. 下一篇

S07-A02 · WebFlux vs MVC：响应式到底适合谁

安全讲完，最后一篇架构文：响应式带来的收益与代价，以及什么业务值得上。

本篇属于系列《S07 · Spring 框架》。旧文来源：A-353/475/355；扩展点 E-S07-018。