3. 鉴权拦截核心概念：Token、Session、API Key、OAuth2.0、JWT 的基本原理与对比

在构建后端鉴权拦截层时，选择正确的鉴权机制直接决定了系统的安全性、扩展性与性能。本章将深入剖析五种主流鉴权方案的核心原理，并通过对比分析帮助你在 Redis 缓存场景下做出最优决策。

3.1 五种鉴权机制的核心原理

3.1.1 Session 鉴权（服务端有状态）

Session 是最传统的 Web 鉴权方式。用户登录成功后，服务端生成一个 Session ID 并存储在内存或 Redis 中，同时将 Session ID 通过 Cookie 返回给客户端。后续请求携带 Cookie，服务端根据 Session ID 查找对应的用户信息。

  • 存储位置：服务端（内存 / Redis / 数据库）
  • 客户端凭证：Cookie（通常包含 Session ID）
  • 核心特点：服务端持有完整用户状态，可主动销毁会话
  • 性能瓶颈：高并发下需频繁查询存储层，Redis 可大幅缓解此问题

3.1.2 Token 鉴权（服务端无状态）

Token 是一种自包含的凭证。用户登录后，服务端签发一个加密的 Token 字符串返回给客户端，客户端在后续请求的 Authorization 头中携带该 Token。服务端通过验证 Token 的签名和有效期来确认用户身份，无需查询存储层。

  • 存储位置：客户端（Token 本身）
  • 客户端凭证：HTTP Header Authorization: Bearer <token>
  • 核心特点：服务端无状态，天然适合分布式与微服务架构
  • 性能优势：验证过程仅需 CPU 计算，无 I/O 开销

3.1.3 JWT（JSON Web Token）

JWT 是 Token 的一种标准化实现。它由三部分组成：Header（头部）、Payload（载荷）、Signature（签名），通过 . 连接。Payload 中可以携带用户 ID、角色、过期时间等声明信息。

// JWT 结构示例
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.
eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.
SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
  • 自包含：用户信息直接编码在 Token 中，减少数据库查询
  • 防篡改：通过 HMAC 或 RSA 签名保证数据完整性
  • 无状态：服务端只需验证签名，无需维护会话存储
  • 注意：Payload 仅 Base64 编码，切勿存放敏感信息（如密码）

3.1.4 API Key 鉴权

API Key 是一种最简单的鉴权方式。服务端为每个调用方生成一个唯一的密钥字符串，调用方在请求中携带该 Key。服务端通过查询数据库或缓存来验证 Key 的有效性。

  • 适用场景：服务间通信、第三方 API 接入、开放平台
  • 安全级别：较低，通常需配合 IP 白名单或签名算法使用
  • 性能特点：需查询存储层验证 Key，Redis 缓存可显著提升验证速度

3.1.5 OAuth2.0 授权框架

OAuth2.0 并非一种具体的鉴权算法，而是一个授权框架。它定义了四种授权模式（授权码、隐式、密码凭证、客户端凭证），允许第三方应用在用户授权的前提下获取有限的资源访问权限。

  • 核心角色：资源所有者（用户）、客户端（应用）、授权服务器、资源服务器
  • 产出凭证：Access Token（访问令牌）和 Refresh Token（刷新令牌）
  • 与 JWT 的关系：OAuth2.0 常使用 JWT 作为 Access Token 的格式
  • 典型场景：登录、GitHub OAuth、企业 SSO
实战要点：在 Redis 缓存后端鉴权拦截中，JWT 是最常用的凭证格式。它既满足无状态要求，又能在 Payload 中携带用户角色和权限信息，配合 Redis 黑名单机制可实现即时吊销。

3.2 五种鉴权机制核心对比

对比维度 Session Token（通用） JWT API Key OAuth2.0
状态类型 有状态 无状态 无状态 有状态（需查询） 无状态（Token 本身）
存储位置 服务端 客户端 客户端 两端均存储 客户端
验证方式 查询存储层 签名验证 签名验证 查询存储层 签名验证 + 远程校验
扩展性 低（需共享存储） 高 高 中 高
安全等级 中 高 高 低 高
吊销能力 强（直接删除） 弱（需黑名单） 弱（需黑名单） 强（直接删除） 中（依赖授权服务器）
Redis 缓存价值 极高（会话存储） 低（验证无需缓存） 中（黑名单/刷新） 高（Key 查询） 中（Token 状态缓存）

3.3 鉴权流程对比：Session vs JWT

为了更直观地理解有状态与无状态鉴权的差异，下图展示了 Session 和 JWT 两种典型流程的完整请求链路。

Session 鉴权流程 vs JWT 鉴权流程 Session 鉴权（有状态） 客户端 服务端 Redis 会话 ① 登录请求 ② 存储 Session ③ 返回 Session ID (Cookie) 客户端 服务端 Redis 会话 ④ 请求 + Cookie ⑤ 查询 Session JWT 鉴权（无状态） 客户端 服务端 ① 登录请求 ② 返回 JWT（自包含用户信息） 客户端 服务端 ③ 请求 + JWT ④ 本地签名验证（无 I/O） 核心差异总结 • Session：服务端存储状态 → 每次请求需查询 Redis → 可主动吊销 → 适合传统单体应用 • JWT：客户端存储状态 → 服务端仅验证签名 → 吊销需黑名单 → 适合分布式/微服务 • 性能差异：Session 鉴权延迟 ≈ 网络 RTT + Redis 查询；JWT 鉴权延迟 ≈ 本地签名计算 • 安全权衡：Session 吊销即时；JWT 在过期前无法撤销（除非维护 Redis 黑名单）

3.4 鉴权机制选型建议

在实际项目中，鉴权方案的选择需要结合系统架构、性能要求和安全等级综合考量。以下是一份基于实战经验的选型指南：

应用场景 推荐方案 理由
传统单体 Web 应用 Session + Redis 开发简单，服务端可主动管理会话，Redis 解决分布式 Session 问题
微服务 / 前后端分离 JWT 无状态，服务间无需共享存储，Payload 可携带用户角色
第三方 API 开放平台 API Key + Redis 轻量级，配合 Redis 缓存 Key 信息，支持快速校验和限流
第三方登录 / 授权 OAuth2.0 + JWT 标准化授权流程，JWT 作为 Access Token 格式，兼容性好
高安全要求（金融/政务） Session + Redis + 双因子 服务端完全控制会话生命周期，支持即时吊销和审计
性能优化提示：在 Redis 缓存后端鉴权拦截层中，JWT 的验证过程不依赖 Redis，但黑名单机制需要 Redis 支持。建议将 JWT 黑名单的 TTL 设置为 Token 的剩余有效期，避免 Redis 内存浪费。对于 Session 方案，务必使用 Redis 的 EXPIRE 命令设置会话超时时间，并配合 LRU 淘汰策略应对突发流量。

3.5 鉴权机制在 Redis 缓存层的映射关系

不同的鉴权机制在 Redis 缓存层有不同的数据结构和操作模式。理解这种映射关系有助于设计高效的缓存策略。

鉴权机制与 Redis 缓存映射关系 Session 鉴权 Redis 数据结构 String / Hash Key: session:{id} JWT 鉴权 Redis 数据结构 Set / String 黑名单: blacklist:{jti} API Key 鉴权 Redis 数据结构 String Key: apikey:{key} OAuth2.0 鉴权 Redis 数据结构 String / Hash 授权码 / Token 状态 Redis 缓存策略建议 • Session：使用 Hash 存储用户信息，EXPIRE 设置会话超时，配合 LRU 淘汰 • JWT：使用 Set 存储黑名单 JTI，TTL 设置为 Token 剩余有效期，减少内存占用 • API Key：使用 String 缓存 Key 元数据，配合 EXISTS 快速校验，设置合理 TTL
安全警告：无论选择哪种鉴权机制，都严禁在 JWT 的 Payload 或 Session 中存储明文密码、信用卡号等敏感信息。JWT 的 Payload 仅经过 Base64 编码，未加密，任何持有 Token 的人都可以解码查看。如需加密敏感声明，请使用 JWE（JSON Web Encryption）标准。
← 上一章 📖 返回目录 下一章 →