Token：解决 Cookie+Session 痛点的新一代「身份凭证」
一、为什么会出现 Token？
1. Cookie + Session 的天生痛点
- 服务器压力大Session 存在服务器内存 / Redis，用户越多占用越大。
- 分布式集群麻烦必须做 Session 共享（Redis 同步、IP 绑定等）。
- 跨域 / 跨端不友好Cookie 受同源策略限制，APP、小程序、第三方跨域场景难用。
- 安全风险自动携带 Cookie，易受 CSRF 攻击。
2. Token 要解决的核心问题
- 服务器无状态：不存用户会话信息
- 天然支持分布式 / 跨域
- 更安全、更灵活
- 适合：Web、APP、小程序、微服务、第三方授权
二、Token 基本概念
1. 什么是 Token
- Token = 令牌 / 凭证
- 是服务器生成的一串加密字符串，代表用户身份和权限。
- 客户端自己保存，每次请求主动带上，服务器验证后即可识别身份。
2. 核心特点
- 无状态（Stateless）服务器不存任何 Session，信息全部存在 Token 里。
- 跨端友好不依赖 Cookie，可放在 Header、Param 等任意位置。
- 自包含Token 里可直接存用户 ID、权限、过期时间等。
- 可加密签名防止篡改、伪造。
三、Token 完整登录流程（经典）
- 用户登录客户端提交：用户名 + 密码
- 服务器验证验证通过后，生成 Token（包含用户信息 + 签名）
- 返回 Token服务器把 Token 发给客户端
- 客户端保存存在：
- localStorage / sessionStorage
- Cookie（手动设置，不依赖自动携带）
- APP 本地存储
- 后续请求客户端主动在请求头带上：
plaintext
Authorization: Bearer <token> - 服务器验证解析 Token → 验签名 → 查过期 → 拿到用户信息不需要查 Session/Redis（基础 JWT 场景）
四、Token 主流实现：JWT
1. JWT = JSON Web Token
目前最标准、最常用的 Token 格式。
2. JWT 结构（三段式，用.分隔）
plaintext
Header.Payload.Signature① Header（头）
- 声明：算法 + 类型
- 示例：
json
{ "alg": "HS256", "typ": "JWT" }
② Payload（负载）
- 存放实际数据（用户信息、过期时间等）
- 官方标准字段（推荐）：
iss签发者sub用户 IDexp过期时间iat签发时间
- 注意：Payload 只是 Base64 编码，不是加密，不要存密码等敏感信息。
③ Signature（签名）
- 保证 Token不被篡改
- 公式：
plaintext
Signature = HMACSHA256( Base64(Header) + "." + Base64(Payload), 服务器密钥 ) - 只要密钥不泄露，别人就无法伪造 Token。
五、Token 与 Cookie/Session 核心对比（面试必背）
表格
| 维度 | Cookie + Session | Token（JWT） |
|---|---|---|
| 存储位置 | Session 存服务器 | 信息存在客户端自身 |
| 状态 | 有状态 | 无状态 |
| 分布式支持 | 需要共享方案（Redis 等） | 天然支持 |
| 跨域 / 跨端 | 弱，受同源策略限制 | 强，支持 Web/APP/ 小程序 / 微服务 |
| 性能 | 服务器查表，量大有压力 | 直接验签，无 IO，性能更好 |
| CSRF 风险 | 高（自动带 Cookie） | 低（需主动携带，可控制） |
| 安全性 | 依赖 Cookie 配置 | 签名防篡改，可加密 |
| 失效控制 | 服务器可直接删 Session | 无法主动作废，只能等过期（可用黑名单） |
六、Token 的优点
- 无状态，减轻服务器存储压力
- 天然支持水平扩展，适合微服务、集群
- 跨域跨端友好，不依赖 Cookie
- 防 CSRF（不自动发送，可控制来源）
- 可自包含权限，适合第三方授权（OAuth2）
七、Token 的缺点与解决方案
1. 无法主动作废（最大痛点）
- Token 一旦签发，只能等到期。
- 解决方案：
- Redis 黑名单：作废的 Token 存入 Redis，请求时先校验
- 短有效期 + 刷新 Token（Refresh Token）
2. 长度比 SessionId 大
- 每次请求携带数据稍多，可忽略。
3. Payload 可被解码
- 不要存密码、手机号明文等敏感信息。
八、Token 携带方式（实战）
- 推荐：请求头 Authorization
plaintext
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9... - 放在 URL 参数（不推荐）
- 放在 POST 参数
- 放在自定义 Header（如
token: xxx）
九、双 Token 方案（企业级常用）
为了解决安全和体验平衡：
- Access Token
- 有效期短（5~30 分钟）
- 用于正常接口请求
- Refresh Token
- 有效期长（几天～几周）
- 仅用于刷新 Access Token
- 泄露风险相对可控
流程：
- 登录 → 返回 AT + RT
- AT 过期 → 用 RT 换新 AT
- RT 过期 → 重新登录
十、安全最佳实践
- 必须用 HTTPS防止 Token 被抓包窃取。
- 签名密钥严格保密密钥泄露 = 所有人可伪造 Token。
- 设置合理过期时间避免长期有效。
- 敏感信息不放入 Payload只放用户 ID、角色，不放密码。
- 开启 Redis 黑名单支持强制下线、改密后作废旧 Token。
- 避免存在 localStorage 被 XSS 窃取可存在HttpOnly Cookie里（仍用 JWT 逻辑，只是借用存储）。
十一、高频面试题极简答案
Token 解决了 Session 什么问题？无状态、天然分布式、跨端友好、降低服务器压力、防 CSRF。
JWT 由哪三部分组成？Header、Payload、Signature。
JWT 能存密码吗？不能，Payload 只是 Base64 编码，可解码。
Token 怎么防止篡改？通过签名（Signature），服务端验签即可判断是否被修改。
Token 如何实现主动退出？使用 Redis 黑名单，将 Token 加入黑名单即作废。
Token 比 Session 更安全吗？在防 CSRF、防劫持可控性上更安全；但 XSS 风险需要自己防护。
十二、全文总结
- Cookie+Session：有状态、服务器存储、集群麻烦、适合传统 Web。
- Token（JWT）：无状态、自包含、天然分布式、跨端神器。
- 核心思想：把 “身份凭证” 交给客户端自己保管，服务器只负责验签不负责存储。
- 现代架构：前后端分离、APP、小程序、微服务 →首选 Token。