3、常见鉴权协议：JWT、OAuth2.0、Session-Cookie、API Key 的原理与适用场景
在微服务与云原生架构中，鉴权拦截是网关与业务服务的核心防线。不同的鉴权协议在无状态性、安全性、扩展性上差异显著。本章从原理出发，对比四种主流协议的适用场景，为后续的拦截器移植适配奠定基础。
3.1 协议全景对比
下表从核心机制、存储位置、典型场景三个维度快速建立认知框架：
| 协议 | 核心机制 | 凭证存储位置 | 典型场景 |
|---|---|---|---|
| JWT | 自包含令牌，签名验证 | 客户端（无服务端状态） | 分布式 API、单点登录（SSO） |
| OAuth2.0 | 授权委托，令牌交换 | 授权服务器 + 客户端 | 第三方应用授权、开放平台 |
| Session-Cookie | 服务端会话，Cookie 传递 ID | 服务端内存/Redis | 传统 Web 应用、单体架构 |
| API Key | 静态密钥，明文传输 | 客户端 + 服务端白名单 | 内部服务间通信、公开 API 限流 |
移植适配提示： 在网关层做鉴权拦截时，JWT 和 OAuth2.0 的 Token 校验逻辑通常可抽象为通用 Filter；Session-Cookie 依赖共享存储（如 Redis），需确保网关与业务服务访问同一会话存储；API Key 则需维护密钥分发与轮换机制。
3.2 JWT（JSON Web Token）
JWT 是一种自包含的令牌格式，由 Header、Payload、Signature 三部分组成，通过 Base64URL 编码后以点号连接。服务端无需存储会话，仅凭签名即可验证令牌真实性。
// JWT 结构示例
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.
eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.
SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c- 无状态性： 令牌包含用户身份与声明，服务端无需查库或会话存储，天然适合水平扩展。
- 签名验证： 使用 HMAC 或 RSA/ECDSA 算法，防止令牌被篡改。
- 适用场景： 微服务间认证、移动端 API、单点登录（SSO）。
- 注意事项： 令牌无法主动失效（需配合黑名单或短有效期）；Payload 仅 Base64 编码，不可存放敏感信息。
3.3 OAuth2.0
OAuth2.0 是一个授权框架，核心思想是将“资源所有者”的授权委托给“客户端应用”，通过授权服务器颁发访问令牌（Access Token）。它定义了四种授权模式：授权码模式、隐式模式、密码模式、客户端凭证模式。
- 授权码模式（推荐）： 客户端先获取授权码，再换取令牌，适用于有后端的 Web 应用。
- 客户端凭证模式： 客户端直接使用自身凭证获取令牌，适用于服务间通信。
- 令牌类型： Access Token（短期） + Refresh Token（长期），支持令牌刷新。
- 适用场景： 第三方登录（/Google）、开放 API 平台、微服务网关统一授权。
- 注意事项： 协议流程复杂，需授权服务器支持；令牌泄露风险需通过短有效期 + 刷新机制缓解。
3.4 Session-Cookie
Session-Cookie 是传统的服务端会话管理方式。用户登录后，服务端创建 Session 并存储会话数据（内存或 Redis），同时将 Session ID 通过 Set-Cookie 返回给客户端。后续请求携带 Cookie，服务端根据 Session ID 查找会话。
- 有状态性： 服务端必须维护会话存储，水平扩展时需共享 Session（如 Redis 集中存储）。
- 安全性： Cookie 可设置 HttpOnly、Secure、SameSite 属性，防止 XSS 和 CSRF 攻击。
- 适用场景： 传统 MVC 应用、企业内部管理系统、对实时性要求不高的 Web 应用。
- 注意事项： 分布式环境下需解决 Session 共享问题；移动端对 Cookie 支持不友好，通常需额外适配。
移植适配风险： 在网关层做 Session-Cookie 鉴权时，必须确保网关与所有业务服务访问同一 Redis 或 Session 存储。若迁移至无状态架构，建议逐步替换为 JWT 或 OAuth2.0。
3.5 API Key
API Key 是最简单的鉴权方式：服务端为每个客户端分配一个唯一密钥，客户端在请求头或查询参数中携带该密钥，服务端验证密钥是否在白名单中。
// API Key 请求示例
GET /api/v1/resource HTTP/1.1
Host: example.com
X-API-Key: sk_live_4eC39HqLyjWDarjtT1zdp7dc- 简单直接： 无需复杂协议，适合快速集成。
- 安全性较低： 密钥明文传输，易泄露；无过期机制，需定期轮换。
- 适用场景： 内部服务间通信（配合 IP 白名单）、公开 API 的限流与统计、开发测试环境。
- 注意事项： 避免在 URL 查询参数中传递 API Key（日志可能泄露）；建议配合 HTTPS 和请求签名使用。
3.6 协议选型决策树
在实际项目中，选择哪种协议取决于架构形态与安全需求。以下决策树可辅助判断：
- 是否需要第三方授权？ → 是 → OAuth2.0
- 是否要求无状态、水平扩展？ → 是 → JWT
- 是否为传统单体 Web 应用？ → 是 → Session-Cookie
- 是否为内部服务或简单 API？ → 是 → API Key
实践建议： 在微服务网关层，通常采用“JWT + OAuth2.0”组合：OAuth2.0 负责授权码流程与令牌颁发，JWT 作为令牌格式在服务间传递。API Key 仅用于内部监控或调试接口，Session-Cookie 逐步迁移至无状态方案。