3. 鉴权拦截核心概念：认证与授权、JWT 与 OAuth 2.0 基础
在多租户 SaaS 架构中，鉴权拦截是保障租户隔离与数据安全的第一道防线。本章将厘清认证与授权的本质区别，并深入剖析 JWT 与 OAuth 2.0 这两个核心协议，为后续构建 CI/CD 流水线中的鉴权拦截链路打下坚实基础。
3.1 认证（Authentication）与授权（Authorization）的区别
这两个术语常被混用，但在安全架构中职责截然不同。认证解决“你是谁”的问题，授权解决“你能做什么”的问题。
| 维度 | 认证（Authentication） | 授权（Authorization） |
|---|---|---|
| 核心问题 | 你是谁？ | 你能做什么？ |
| 验证对象 | 用户身份凭证（密码、MFA、生物特征） | 已认证用户的权限策略（角色、租户范围） |
| 执行时机 | 先于授权，通常发生在会话建立时 | 在认证通过后，每次资源访问时检查 |
| 常见协议 | LDAP、SAML、OIDC（身份层） | OAuth 2.0（授权框架）、RBAC、ABAC |
| 失败结果 | 401 Unauthorized（实际应为 Unauthenticated） | 403 Forbidden |
| 多租户场景 | 验证用户属于哪个租户（Tenant ID） | 验证用户对租户内资源的操作权限 |
实践提示：在 SaaS 网关层，认证失败应返回 401，授权失败返回 403。许多团队误将 401 用于权限不足，导致客户端重试逻辑混乱。CI/CD 流水线中应配置明确的 HTTP 状态码断言。
3.2 JWT（JSON Web Token）基础
JWT 是一种紧凑的、URL 安全的令牌格式，用于在各方之间以 JSON 对象形式安全传输声明（Claims）。它自包含用户身份和元数据，无需服务端会话存储，非常适合分布式 SaaS 架构。
3.2.1 JWT 结构
一个 JWT 由三部分组成，以点号（.）分隔：
Base64URL(Header).Base64URL(Payload).Signature- Header（头部）： 包含令牌类型（typ: JWT）和签名算法（alg: HS256 或 RS256）。
- Payload（载荷）： 包含声明（Claims），如用户 ID、租户 ID（tenant_id）、角色（role）、过期时间（exp）。
- Signature（签名）： 对前两部分进行签名，防止篡改。
3.2.2 多租户 JWT 载荷示例
{
"sub": "user_abc123",
"tenant_id": "tenant_acme_corp",
"role": "admin",
"permissions": ["read:orders", "write:orders"],
"iat": 1718000000,
"exp": 1718003600,
"iss": "https://auth.saas-platform.com"
}
关键字段说明：
tenant_id：租户隔离的核心标识，所有下游服务依赖此字段进行数据路由。role：用于 RBAC 授权决策。exp：令牌过期时间，CI/CD 流水线中应配置短有效期（如 15 分钟）并启用自动刷新。
3.2.3 JWT 签名算法选择
| 算法 | 类型 | 密钥管理 | 适用场景 |
|---|---|---|---|
| HS256 | 对称 | 单一共享密钥 | 内部微服务间通信，密钥不泄露 |
| RS256 | 非对称 | 私钥签名，公钥验证 | 跨服务、跨租户、第三方集成 |
| ES256 | 非对称（椭圆曲线） | 私钥签名，公钥验证 | 移动端、IoT 设备，令牌体积更小 |
安全警告：切勿在 JWT Payload 中存储密码或敏感数据。Payload 仅经过 Base64URL 编码，并未加密。如需加密载荷，应使用 JWE（JSON Web Encryption）。
3.3 OAuth 2.0 基础
OAuth 2.0 是一个授权框架，允许第三方应用获取对用户资源的有限访问权限，而无需暴露用户密码。它通过颁发访问令牌（Access Token）来实现授权，是 SaaS 多租户场景中委托授权的标准协议。
3.3.1 核心角色
- 资源所有者（Resource Owner）： 用户，拥有数据。
- 客户端（Client）： 第三方应用，请求访问资源。
- 授权服务器（Authorization Server）： 颁发令牌，负责认证和授权。
- 资源服务器（Resource Server）： 托管受保护资源，验证令牌。
3.3.2 常见授权模式（Grant Types）
| 授权模式 | 适用场景 | 安全性 | 多租户适配性 |
|---|---|---|---|
| 授权码（Authorization Code） | Web 应用、有后端的 SPA | 高（支持 PKCE） | 高，可携带 tenant_id 参数 |
| 客户端凭证（Client Credentials） | 微服务间通信、后台任务 | 中（依赖客户端密钥） | 高，常用于服务到服务鉴权 |
| 隐式模式（Implicit） | 纯前端应用（已不推荐） | 低 | 低，令牌暴露风险高 |
| 资源所有者密码（Password） | 遗留系统、高度信任的客户端 | 低 | 低，不推荐用于 SaaS |
CI/CD 流水线建议：在自动化测试中，使用“客户端凭证”模式获取 Access Token 来模拟服务间调用。在集成测试中，使用“授权码 + PKCE”模式模拟用户登录流程，验证完整的鉴权拦截链路。
3.4 JWT 与 OAuth 2.0 的关系
JWT 和 OAuth 2.0 并非互斥，而是互补关系：
- OAuth 2.0 是授权框架， 定义了令牌的获取、刷新和撤销流程。
- JWT 是令牌格式， 常作为 OAuth 2.0 中 Access Token 的实现载体。
- OAuth 2.0 授权服务器颁发的 Access Token 可以是 JWT 格式，也可以是不透明字符串。
- 在多租户 SaaS 中，JWT 的
tenant_id声明与 OAuth 2.0 的scope结合，实现精细的租户级授权。
3.5 本章小结
- 认证与授权 是鉴权链路的两大支柱，前者验证身份，后者控制权限。
- JWT 作为自包含令牌，通过
tenant_id和role等声明，天然适配多租户场景。 - OAuth 2.0 提供标准化的授权流程，授权码模式是 SaaS 应用的首选。
- 在 CI/CD 流水线中，应针对 JWT 的签名验证、过期检查和 OAuth 2.0 的令牌交换流程编写自动化测试，确保鉴权拦截链路在每次部署后依然可靠。