3. 鉴权模式概览：API Key、Bearer Token (JWT)、OAuth2.0、Basic Auth 原理对比

在构建 OpenAPI 网关或中间件时，选择正确的鉴权模式是保障系统安全的第一道防线。不同的鉴权机制在安全性、易用性、可扩展性和适用场景上存在显著差异。本章将从原理层面对四种主流模式进行深度对比，帮助你在架构选型时做出精准决策。

3.1 四种鉴权模式核心原理

3.2 四种模式详细对比

3.3 深入理解各模式原理

3.3.1 API Key：最简单的静态令牌

API Key 是一种预共享的静态字符串，服务端在创建时将其与特定客户端绑定。每次请求时，客户端将 Key 放入请求头（如 X-API-Key）或查询参数中。服务端通过查找预存列表进行匹配验证。

3.3.2 Bearer Token (JWT)：自包含的令牌

JWT 由三部分组成：Header（算法声明）、Payload（用户信息、过期时间等声明）、Signature（防篡改签名）。服务端通过验证签名确认令牌有效性，无需查询数据库。

// JWT 结构示例
// Header
{
  "alg": "HS256",
  "typ": "JWT"
}
// Payload
{
  "sub": "user_12345",
  "name": "张三",
  "iat": 1718000000,
  "exp": 1718003600,
  "role": "admin"
}
// Signature
HMACSHA256(
  base64UrlEncode(header) + "." +
  base64UrlEncode(payload),
  secret_key
)

3.3.3 OAuth2.0：授权框架的四种模式

OAuth2.0 不是一个单一的鉴权协议，而是一个授权框架。它定义了四种授权模式，每种模式适用于不同的客户端类型。

• 授权码模式（Authorization Code）：最安全，适用于有后端的 Web 应用。流程包含授权码交换步骤，避免令牌直接暴露在浏览器中。
• 隐式模式（Implicit）：适用于纯前端应用（已逐渐被 PKCE 取代），直接返回 Access Token。
• 密码模式（Resource Owner Password Credentials）：用户直接提供用户名密码给客户端，仅适用于高度信任的第一方应用。
• 客户端凭证模式（Client Credentials）：适用于服务到服务的通信，无需用户参与。

3.3.4 Basic Auth：最原始的 HTTP 认证

Basic Auth 将用户名和密码以 username:password 格式拼接后，进行 Base64 编码，放入 Authorization 请求头中。由于 Base64 是可逆编码，本质上等同于明文传输。

// Basic Auth 请求头示例
// 原始凭证: admin:secret123
// Base64 编码: YWRtaW46c2VjcmV0MTIz
Authorization: Basic YWRtaW46c2VjcmV0MTIz

3.4 中间件选型决策指南

3.5 安全风险与防范措施

• 令牌泄露：所有模式都面临令牌被截获的风险。必须使用 HTTPS，并设置合理的过期时间。
• 重放攻击：JWT 和 API Key 可能被重放。建议引入 jti（JWT ID）或 nonce 机制，配合服务端缓存实现一次性使用。
• CSRF 攻击：Bearer Token 存储在 Cookie 中时易受 CSRF 攻击。建议将 Token 放在请求头中，或使用 SameSite Cookie 属性。
• 令牌撤销：JWT 一旦签发，在过期前无法撤销（除非维护黑名单）。OAuth2.0 的授权服务器可以主动撤销令牌，更适合需要动态权限管理的场景。