Session 认证和 Token 认证有什么区别？分布式环境下怎么选？
- 标签：Spring Security、认证授权、后端
🏛 业务架构师
Session 与 Token 认证的区别及分布式选型：
区别（五个维度）：
| 维度 | Session | Token（JWT） |
|---|---|---|
| 状态 | 服务端存（内存/Redis），客户端只拿 Session ID | 客户端持有全部信息，服务端（近）无状态 |
| 扩展性 | 需共享存储（Session 粘滞或 Redis 集中） | 验签本地完成，天然水平扩展 |
| 注销/踢人 | 容易（删服务端会话即失效） | 难（需黑名单/短时效机制） |
| 跨系统/跨域 | Cookie 策略受限（CSRF 也相关） | Header 传递，跨服务友好 |
| 移动端/小程序 | Cookie 支持别扭 | 原生友好 |
分布式环境怎么选，我的决策框架：
- 单体/小系统、传统 Web 后台：Session + Spring Session Redis（会话集中存储）——简单成熟，注销即时，管理后台这类强管控场景反而更合适；
- 微服务/多端（App/小程序/开放 API）：JWT 双令牌（短 Access+可撤销 Refresh）——网关统一验签，服务无状态化，扩容不依赖会话存储；这是 2026 年的主流选择；
- 混合实践：对外 API 走 JWT、内部管理端走集中 Session——按端分层，各取所长。
避坑提醒：
- 分布式 Session 别用"IP 粘滞"（负载不均、故障切换丢会话），用 Spring Session 统一 Redis；
- JWT 别只做无状态就万事大吉——注销、改权、封号的即时性必须提前设计（黑名单/版本号）；
- 无论哪种，HTTPS 是前提，Token 别放 localStorage（XSS），Cookie 记得 HttpOnly+Secure+SameSite。
一句话：Session 是"状态在服务端"的旧契约，Token 是"状态在客户端"的新契约——分布式与多端化的业务现实让 Token 成为默认，但强管控场景 Session 依然能打，按端选型而非站队信仰。
🏗 系统架构师
Session 认证：服务端存会话状态（内存/Redis），客户端只持 SessionId（Cookie）——状态在服务端。Token 认证（JWT）：状态编码进令牌（签名保证可信），服务端无存储——状态在客户端。
核心差异（架构账本）：
| 维度 | Session | JWT |
|---|---|---|
| 扩展性 | 需会话共享（粘性路由或 Redis 集中存储） | 无状态，任意实例本地验签 |
| 作废 | 移除服务端会话即刻生效 | 难（黑名单/短令牌，见专题） |
| 跨服务/跨域 | Cookie 域限制、跨服务要会话共享 | 令牌透传，天然跨服务 |
| 移动端/小程序 | Cookie 语义弱 | Header 携带自然 |
| 体积/性能 | 每请求查会话存储（Redis 一次） | 验签 CPU（本地），无网络查 |
| CSRF | Cookie 自动携带 → 需防 CSRF | Header 手动携带 → 天然免疫 |
分布式环境怎么选（决策树）：
- 单体/传统 Web 应用：Session + Spring Session Redis（会话外置到 Redis，实例无状态化）——简单、可即时作废，管理后台类应用首选；
- 微服务/API 优先/前后端分离/移动端：JWT（OAuth2/OIDC 体系）——无状态水平扩展、网关统一验签、跨服务令牌传递；接受"作废延迟窗口"用短 Access + Refresh 吊销补；
- 混合形态：外部面向客户端用 OIDC/JWT，内部服务间调用用服务身份（mTLS/client credentials）+ 用户上下文透传（JWT 原样转发或内部声明换发）；
- 即时封禁刚需（风控踢人）：Session 或 JWT+黑名单/版本号——安全要求倒逼有状态。
架构师忠告："JWT 更先进"是常见误解——两者是状态放哪的权衡：作废能力 vs 扩展简洁性。按业务对"踢人即时性"的要求选，而不是按潮流。
💻 全栈开发专家
Session 认证：登录后服务端存会话（内存/Redis），浏览器持 sessionId（Cookie）——状态在服务端。 Token 认证（JWT）：签名令牌自包含身份——状态在客户端（服务端只验签）。
| 维度 | Session | JWT |
|---|---|---|
| 状态 | 服务端存（水平扩要 Redis 共享） | 无状态，验签即可 |
| 扩容 | Session 粘滞/集中存储 | 天然友好 |
| 吊销 | 立即（删 session） | 难（黑名单/短有效期） |
| CSRF | 需防护（Cookie 自动携带） | Header 携带天然免疫（若放 Cookie 同样要防） |
| 跨域/多端 | Cookie 跨域麻烦 | Header 传 token 顺手 |
| 移动端/小程序 | Cookie 支持差 | 标准 |
| 性能 | 每请求查 session 存储 | 验签（RSA 微秒级，无 IO） |
分布式环境怎么选（实战决策线）：
- 单体/传统 Web（同域、浏览器为主）：Session + Spring Session Redis（
@EnableRedisHttpSession）——吊销能力强、实现简单，别为了时髦上 JWT； - 前后端分离 + 多端（App/小程序/Web）：JWT（access+refresh）——标准答案；
- 微服务：网关统一认证（验 JWT 转发用户头）或 OAuth2/OIDC 中心化；内部服务间可用 token relay；
- 需要强吊销（金融、后台）：JWT 短有效期 + refresh 管理 + 版本号方案（见注销题）。
Spring 落地：Session：spring-session-data-redis；JWT：Spring Authorization Server 签发 + 资源服务器 oauth2ResourceServer().jwt()。一个常见反模式：把 JWT 塞 Cookie 又开 CSRF 免疫——等于集两家之短，别这么干。