JWT

JWT（JSON Web Token）的出现主要是为了解决现代分布式系统中的 身份验证 和 安全信息交换 问题，以下是它要解决的核心痛点：

---

1. 解决Session的扩展性问题

• 传统Session问题：
  在单体应用中，用户登录后服务端会存储Session（如内存/Redis），浏览器通过Cookie保存Session ID。但在分布式系统中：
  • 需要Session共享（依赖Redis等中间件）
  • 跨域时Cookie处理复杂
  • 服务器需维护Session状态（违背REST无状态原则）
• JWT的解决方案：
  将用户状态直接编码到Token中，客户端存储Token，服务端无需保存会话状态，天然支持分布式架构。

---

2. 替代简单的Token方案

• 传统Token问题：
  早期简单的Token（如随机字符串）需要服务端查询数据库验证有效性，增加I/O开销。
• JWT的解决方案：
  通过签名自包含验证信息，服务端只需验证签名和过期时间，无需查库（除非需要额外吊销机制）。

---

3. 跨域/跨服务认证

• 传统问题：
  Cookie在跨域时受限（需CORS配合），而微服务架构中服务间调用的身份传递复杂。
• JWT的解决方案：
  通过标准化的JSON格式和签名，实现：
  • 跨域认证（前端可将JWT放在HTTP Header中）
  • 服务间安全传递身份信息（如网关验证JWT后转发给下游服务）

---

4. 防范CSRF攻击

• Session+Cookie的隐患：
  Cookie会自动携带，容易遭受CSRF攻击（即使有防御措施如SameSite属性）。
• JWT的解决方案：
  默认要求客户端主动将JWT放入Authorization Header，避免了浏览器自动携带凭证的风险。

---

5. 标准化信息交换格式

• 传统问题：
  自定义Token格式五花八门，各系统间难以互通。
• JWT的解决方案：
  通过RFC 7519标准化：
  • 统一的结构（Header.Payload.Signature）
  • 支持多种签名算法（HS256, RS256等）
  • 明确的声明（Claims）规范

---

6. 移动端/API友好性

• 传统问题：
  Cookie在移动端（尤其原生App）中难以处理，且RESTful API强调无状态。
• JWT的解决方案：
  纯Token机制，适合：
  • 移动端存储（AsyncStorage/SecureStorage）
  • 无状态API设计

---

对比总结表

问题场景	传统方案	JWT的解决方案
分布式系统会话管理	Session共享中间件	自包含Token，无需服务端存储
高频验证性能问题	每次查数据库	签名验证，无I/O依赖
跨域/跨服务身份传递	复杂代理或重复认证	Token直接携带身份声明
防御CSRF攻击	需SameSite/Token同步	默认不依赖Cookie
多平台支持	移动端Cookie处理困难	统一Header传输机制

---

实际案例

1. 单点登录（SSO）：
   JWT允许用户在一个系统登录后，携带Token访问其他关联系统（如Auth0的实现）。

2. 服务间调用：
   微服务A生成JWT传递给微服务B，B无需回调A即可验证请求合法性。

3. 第三方API授权：
   OAuth 2.0中常用JWT作为Access Token（如Google API）。

---

需要注意的"非目标"

JWT 并非 为了解决：

• 数据加密（Payload默认只Base64编码，敏感信息需额外加密）
• 即时吊销（需借助黑名单或短有效期等补充方案）

---

通过以上设计，JWT成为现代分布式架构中身份验证和信息交换的通用解决方案。