有状态的服务无法水平扩展。从 Session 到 JWT 到 OAuth2，Token 方案的演进背后是无状态化的设计哲学。

一、有状态 vs 无状态

  • 1.1 有状态——服务器保存客户端信息，无法随意扩容
  • 1.2 无状态——每个请求独立，可以随意扩容
  • 1.3 为什么微服务要求无状态——弹性伸缩的前提

二、Session 时代的终结

  • 2.1 Tomcat Session 的机制——JSESSIONID Cookie
  • 2.2 分布式 Session 方案——Redis 集中存储
  • 2.3 Spring Session——透明化 Session 共享
  • 2.4 Session 方案的缺点——服务端存储、Cookie 跨域

三、JWT 方案

  • 3.1 JWT 的结构——Header.Payload.Signature
  • 3.2 自包含——Token 本身携带用户信息
  • 3.3 验签过程——HMAC 或 RSA
  • 3.4 优点——无状态、跨域、适合分布式
  • 3.5 缺点——无法主动失效、Token 体积大

四、双 Token 刷新机制

  • 4.1 Access Token——短有效期（15 分钟）
  • 4.2 Refresh Token——长有效期（7 天）
  • 4.3 刷新流程——Access Token 过期 → 用 Refresh Token 换新的
  • 4.4 Refresh Token 的安全性——存储在 HttpOnly Cookie

五、OAuth2.0 授权码流程

  • 5.1 OAuth2 的四种授权模式
  • 5.2 授权码模式——最安全的流程
  • 5.3 Spring Security OAuth2 的集成

六、RBAC 权限模型

  • 6.1 用户 → 角色 → 权限
  • 6.2 接口级权限——@PreAuthorize("hasRole('ADMIN')")
  • 6.3 数据级权限——行级数据隔离
  • 6.4 权限模型的演进——RBAC → ABAC

七、总结

  • 无状态是微服务的基石
  • JWT + 双 Token 是当下最主流的实践