理解 Token —— 从 Session 到 JWT

在用户认证和授权的世界里，Token 是一个绕不开的关键词。无论是传统的 Web 应用，还是当下流行的前后端分离、微服务架构，都需要一个安全、可靠的机制来识别用户身份。而 Token 正是这个核心。

本文将从基础概念讲起，逐步介绍业界常见的几种 Token 方案，并结合实践谈谈它们的优缺点。

---

1. 什么是 Token

Token，本质上就是一串“凭证字符串”。
用户登录成功后，服务器生成并返回一个 Token，之后用户在请求接口时带上这个 Token，服务器通过验证它来判断用户身份，而无需每次都重复输入用户名密码。

可以把它理解为：

• 在电影院，你买了票（账号+密码登录）
• 检票员给你一个手环（Token）
• 之后你凭手环就能在影院里自由进出，而不用再出示购票信息

---

2. 常见的 Token 方案

2.1 Session + Cookie

这是最传统的 Web 鉴权方案：

• 用户登录后，服务器生成 sessionId 并存储在数据库/Redis 中
• 同时把 sessionId 写入浏览器 Cookie
• 用户请求时自动带上 Cookie，服务器查表确认身份

优点

• 简单、易用
• httpOnly Cookie 防止 XSS 攻击

缺点

• 需要在服务端存储 Session
• 分布式集群下需要共享 Session（一般依赖 Redis）

典型场景：传统 Web 应用、后台管理系统

---

2.2 UUID Token + Redis

在移动互联网时代，前后端分离成为常态，Cookie 不再是唯一的选择。于是出现了用 UUID 作为 Token：

• 登录成功后，服务端生成一个 UUID 作为 Token
• 存入 Redis，映射关系如 token -> userId
• 客户端请求时带上这个 Token，服务端查询 Redis 验证

优点

• 灵活，可以随时撤销 Token（删除 Redis）
• TTL（过期时间）控制方便

缺点

• 每次验证都要访问 Redis，依赖缓存性能

典型场景：移动 App、支付系统、高安全要求的业务

---

2.3 JWT（JSON Web Token）

JWT 是一种无状态 Token，内部结构分为三段：

Header.Payload.Signature

• Header：描述签名算法
• Payload：存储用户数据（如 userId、过期时间 exp）
• Signature：用秘钥签名，防止篡改

特点是：服务端不用存储任何数据，只需校验签名即可。

优点

• 无状态，天然适合分布式、微服务架构
• 可携带少量用户信息（避免频繁查询数据库）

缺点

• 一旦签发无法主动撤销，只能等过期
• 如果泄漏，在过期前会一直有效

典型场景：API 网关、微服务内部鉴权、OAuth2.0

---

2.4 混合方案（JWT + Redis）

业界许多公司采用的实则是混合方案：

• 短期 Token：JWT，有效期较短（例如 15 分钟）
• 长期 Token：Refresh Token（UUID），存 Redis，有效期 7~30 天
• 当 JWT 过期时，客户端用 Refresh Token 换新 JWT
• 如果用户登出或管理员禁用账户，删除 Redis 的 Refresh Token，即可彻底失效

典型场景：OAuth2、OpenID Connect、现代 SaaS 平台

---

3. 如何设置过期时间

无论哪种 Token，都需要思考过期时间：

• JWT：在 Payload 里设置 exp 字段，自动过期
• UUID Token：在 Redis 中设置 TTL，到期自动清理

实践中常见做法：

• 短期 Token（几分钟 ~ 几小时）：减少泄漏风险
• 长期 Token（几天 ~ 几周）：提升用户体验，用于换新

---

4. 业界的主流选择

总结一下目前常见的几种方案：

方案	存储	优点	缺点	典型场景
Session + Cookie	数据库/Redis	简单、安全	集群下要共享 Session	传统 Web、管理后台
UUID Token + Redis	Redis	可控、可撤销	依赖缓存性能	移动 App、支付业务
JWT	无存储	无状态、分布式友善	无法主动失效	微服务、API 鉴权
JWT + Redis	JWT + Redis	兼顾无状态与可控性	实现复杂度高	OAuth2、SaaS 平台

---

5. 总结

• Token = 身份凭证，是现代认证体系的核心

• Session → UUID Token → JWT → 混合方案，是业界常见的演进路线

• JWT 用得许多，但几乎都会配合 Redis 做增强，以解决主动失效的问题

• 实际选择方案时，要根据业务场景：

  • 传统 Web → Session + Cookie
  • App / 高安全业务 → UUID + Redis
  • 微服务 / API → JWT + Refresh Token

JWT 的无状态优势很强，但在真正的生产环境里，往往需要结合 Redis 来保证安全和可控性。