2. 鉴权基础理论：认证与授权的区别、常见鉴权模式对比

在构建 OpenAPI 鉴权拦截器之前，必须厘清两个最基础的概念：认证（Authentication）与授权（Authorization）。两者常被混淆，但职责截然不同。同时，理解主流鉴权模式（Basic Auth、Bearer Token、OAuth2、JWT）的底层原理与适用场景，是后续设计拦截规则、选择验证策略的前提。

2.1 认证 vs 授权：核心区别

维度 认证（Authentication） 授权（Authorization）
核心问题 你是谁？ 你能做什么？
目的 验证身份真实性 授予资源访问权限
凭证 用户名/密码、API Key、证书 Token、角色、权限策略
执行顺序 先于授权 认证通过后执行
传递方式 通常通过请求头或表单 通常通过 Token 或 Session
典型失败 401 Unauthorized 403 Forbidden
工程提示：在 OpenAPI 拦截器中，认证阶段通常由网关或过滤器完成，授权阶段则依赖 Token 中的 scope 或角色信息。拦截器应优先检查认证状态，再执行授权校验，避免未认证请求进入授权逻辑。

2.2 常见鉴权模式对比

四种主流鉴权模式在 API 安全领域各有定位。下表从安全性、复杂度、适用场景三个维度进行横向对比：

模式 凭证形式 安全性 实现复杂度 典型场景
Basic Auth Base64(username:password) 低（明文传输，需配合 HTTPS） 极低 内部调试、简单监控接口
Bearer Token 不透明 Token 字符串 中（依赖 Token 存储与传输安全） 低 服务端生成、客户端携带的通用模式
OAuth2 Access Token + Refresh Token 高（支持授权码、客户端凭证等流程） 高 第三方授权、开放平台、微服务间授权
JWT 自包含 JSON 结构 Token 中高（签名防篡改，但 Payload 非加密） 中 无状态认证、分布式系统、移动端 API
避坑提醒：Basic Auth 在非 HTTPS 环境下极易被中间人截获；JWT 虽自带签名，但 Payload 仅 Base64 编码，切勿存放敏感信息（如密码、完整手机号）。OAuth2 流程复杂，建议使用成熟框架（如 Spring Security、OAuth2 Proxy）实现，避免自行造轮子。

2.3 四种模式的核心流程

以下 SVG 图展示了四种鉴权模式在 API 请求中的核心交互流程，帮助理解每种模式在客户端与服务端之间的凭证传递方式：

四种鉴权模式核心流程对比 Basic Auth 客户端 → 服务端： Authorization: Basic base64(user:pass) 服务端验证：解码后比对用户名密码 Bearer Token 客户端 → 服务端： Authorization: Bearer <token> 服务端验证：查询 Token 有效性 OAuth2 客户端 → 授权服务器： 授权码 / 客户端凭证 授权服务器 → 客户端：Access Token 客户端 → 资源服务器：Bearer Token JWT 客户端 → 服务端： Authorization: Bearer <jwt> 服务端验证：签名 + 过期时间 无需查询数据库，自包含用户信息 说明：Basic Auth 和 Bearer Token 是传输凭证的方式；OAuth2 是授权框架；JWT 是 Token 的格式标准。四者可以组合使用（如 OAuth2 颁发 JWT）。

2.4 JWT 结构详解

JWT（JSON Web Token）是当前微服务架构中最常用的无状态 Token 格式。一个 JWT 由三部分组成，以点号（.）分隔：

// JWT 示例
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.
eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.
SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
部分 内容 示例（解码后）
Header 签名算法、Token 类型 {"alg":"HS256","typ":"JWT"}
Payload 声明（Claims）：用户信息、过期时间等 {"sub":"1234567890","name":"John Doe","iat":1516239022}
Signature 对 Header + Payload 的签名，防止篡改 由密钥和指定算法生成
关键认知：JWT 的 Payload 仅 Base64 编码，并非加密。任何持有 Token 的人都可以解码查看内容。因此，敏感信息（如密码、信用卡号）严禁放入 JWT Payload。签名仅保证内容未被篡改，不保证内容不可见。

2.5 OAuth2 四种授权模式

OAuth2 定义了四种授权模式，适用于不同的客户端类型和安全需求：

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

以下 SVG 图展示 OAuth2 授权码模式的完整交互流程，这是最常用且最安全的模式：

OAuth2 授权码模式（Authorization Code）流程 用户（资源所有者） 客户端（App） 授权服务器 资源服务器 ① 访问 ② 重定向（含回调URL） ③ 用户授权 ④ 授权码 ⑤ 授权码 + Client Secret ⑥ Access Token ⑦ 携带 Access Token 请求资源 ⑧ 返回受保护资源 说明：授权码模式的核心优势在于 Access Token 只经过后端服务器，不暴露给前端浏览器或第三方。 客户端需持有 Client Secret 才能交换 Token，有效防止 Token 泄露。

2.6 鉴权模式选型建议

  • 内部调试 / 开发环境：Basic Auth 足够简单，但务必配合 HTTPS。
  • 第一方移动端 / SPA：推荐 OAuth2 授权码模式 + PKCE，或使用 JWT 自包含用户信息。
  • 服务间通信（B2B）：OAuth2 客户端凭证模式，或使用 JWT 进行无状态认证。
  • 开放平台 / 第三方集成：OAuth2 授权码模式是行业标准，支持 scope 细粒度授权。
  • 无状态分布式系统：JWT 是最佳选择，避免集中式 Session 存储，但需注意 Token 吊销问题。
工程落地提示：在 OpenAPI 鉴权拦截器设计中，建议统一使用 Bearer Token 作为传输方式，底层 Token 格式可以是 JWT 或 OAuth2 颁发的 opaque token。拦截器只需验证 Token 的有效性和 scope，无需关心 Token 的生成方式，保持拦截逻辑与鉴权策略解耦。
← 上一章 📖 返回目录 下一章 →