3. 常见鉴权协议选型对比：JWT、OAuth2.0、SAML、OpenID Connect
在多租户 SaaS 架构中，鉴权与授权协议的选择直接决定了系统的安全性、扩展性及用户体验。本章深入对比四种主流协议——JWT、OAuth2.0、SAML 与 OpenID Connect (OIDC)，从适用场景、核心优缺点及多租户适配性三个维度进行剖析，帮助架构师在拦截链路中做出精准选型。
核心认知： 鉴权（Authentication）解决“你是谁”的问题，授权（Authorization）解决“你能做什么”的问题。JWT 是一种令牌格式，OAuth2.0 是授权框架，SAML 与 OIDC 是联合身份协议。在实际链路中，它们常组合使用，而非互斥。
3.1 协议全景对比
下表从协议本质、传输格式、主要用途、多租户支持度及安全模型五个关键维度进行横向对比：
| 维度 | JWT | OAuth2.0 | SAML | OpenID Connect |
|---|---|---|---|---|
| 协议本质 | 令牌格式标准 | 授权框架 | 联合身份协议 | 身份认证层（基于 OAuth2.0） |
| 传输格式 | JSON（紧凑、自包含） | JSON / 令牌 | XML（基于断言） | JSON + JWT |
| 主要用途 | 声明传递、无状态会话 | 第三方授权、API 访问委托 | 企业级 SSO、跨域身份联合 | 现代应用 SSO、社交登录 |
| 多租户支持 | 通过自定义声明（claims）实现 | 通过 issuer + audience 隔离 | 通过实体 ID + 元数据配置 | 通过 issuer + client_id 隔离 |
| 安全模型 | 签名验证（HS256/RS256） | Bearer 令牌 + 刷新令牌 | XML 签名 + 加密断言 | ID Token + Access Token + 签名 |
3.2 协议详解与多租户适配
3.2.1 JWT（JSON Web Token）
JWT 是一种紧凑的、自包含的令牌格式，由 Header、Payload 和 Signature 三部分组成。在多租户 SaaS 中，JWT 常用于无状态鉴权，将租户标识（tenant_id）、用户角色（role）等声明直接编码在令牌中，减少数据库查询。
- 优点： 无状态、跨语言支持、易于在微服务间传递、支持自定义声明。
- 缺点： 令牌无法主动撤销（需黑名单或短有效期）、Payload 仅 Base64 编码（非加密）、令牌体积随声明增加而膨胀。
- 多租户场景： 在 Payload 中加入
tenant_id和permissions字段，网关层解析后路由到对应租户的数据源或服务实例。
// JWT Payload 示例（多租户场景）
{
"sub": "user_12345",
"tenant_id": "tenant_acme",
"role": "admin",
"permissions": ["read:orders", "write:orders"],
"iat": 1710000000,
"exp": 1710003600
}
避坑提示： 切勿在 JWT 中存储敏感数据（如密码、完整手机号）。Payload 仅经过 Base64 编码，未加密，任何持有令牌者均可解码读取。如需加密，应使用 JWE（JSON Web Encryption）。
3.2.2 OAuth2.0
OAuth2.0 是一个授权框架，定义了四种授权模式（授权码、隐式、密码凭证、客户端凭证）。在多租户 SaaS 中，授权码模式 + PKCE 是推荐方案，用于第三方应用委托访问用户资源。
- 优点： 标准化授权流程、支持多种客户端类型、令牌可刷新、广泛集成。
- 缺点： 协议复杂度高、未定义身份认证（仅授权）、需配合 HTTPS 保证安全。
- 多租户场景： 每个租户拥有独立的
client_id和issuer端点，授权服务器根据audience参数区分租户上下文。
3.2.3 SAML（Security Assertion Markup Language）
SAML 是一种基于 XML 的联合身份协议，主要用于企业级单点登录（SSO）。它通过身份提供商（IdP）与服务提供商（SP）之间的断言交换实现跨域认证。
- 优点： 成熟稳定、企业级安全（支持 XML 签名与加密）、强联合身份模型。
- 缺点： XML 解析开销大、协议复杂、移动端支持差、配置繁琐。
- 多租户场景： 每个租户对应一个 SP 实体 ID，IdP 通过
RelayState参数传递租户上下文，SP 根据断言中的Attribute映射租户角色。
3.2.4 OpenID Connect（OIDC）
OIDC 在 OAuth2.0 之上构建了身份认证层，通过 ID Token（JWT 格式）传递用户身份信息。它是现代 SaaS 应用 SSO 的首选方案，支持社交登录与企业联合。
- 优点： 标准化身份认证、ID Token 自包含用户信息、基于 OAuth2.0 生态、支持动态发现（Discovery URL）。
- 缺点： 依赖 OAuth2.0 基础设施、令牌管理复杂度较高、需处理 ID Token 的签名验证与过期。
- 多租户场景： 每个租户拥有独立的
issuer（如https://auth.saas.com/tenants/acme），OIDC 客户端通过client_id与tenant_id绑定，ID Token 中的tenant_id声明用于租户路由。
3.3 协议选型决策流程
下图展示了在多租户 SaaS 鉴权拦截链路中，根据业务需求选择核心协议的决策路径：
3.4 多租户场景下的组合策略
在实际 SaaS 架构中，单一协议往往无法满足所有需求。以下推荐三种经过验证的组合模式：
| 模式 | 协议组合 | 适用场景 | 多租户关键点 |
|---|---|---|---|
| 现代 SSO | OIDC + JWT | 面向消费者的 SaaS、社交登录 | ID Token 携带 tenant_id，Access Token 用于 API 调用 |
| 企业联合 | SAML + JWT | 企业客户 IdP 集成（如 Azure AD、Okta） | SAML 断言映射为 JWT，网关层统一令牌格式 |
| API 生态 | OAuth2.0 + JWT | 第三方开发者平台、开放 API | 每个 App 独立 client_id，JWT 声明租户上下文 |
架构建议： 在多租户鉴权拦截链路中，推荐将 JWT 作为内部令牌标准，所有外部协议（SAML、OIDC）最终在网关层转换为 JWT。这样下游微服务只需解析 JWT，无需感知上游协议差异，实现协议无关的鉴权拦截。
3.5 选型避坑清单
- 不要将 JWT 用于长会话： JWT 无状态特性导致无法主动撤销，建议有效期控制在 15-30 分钟，配合刷新令牌使用。
- 不要忽略 SAML 的 XML 安全： 务必验证签名、检查断言有效期、防范 XML 外部实体注入（XXE）。
- 不要混淆 OAuth2.0 与 OIDC： OAuth2.0 不提供身份认证，仅授权；OIDC 才是认证协议。使用 OAuth2.0 做登录是常见错误。
- 不要硬编码租户上下文： 在多租户场景中，令牌中的 tenant_id 应动态解析，避免在代码中写死租户标识。
- 不要忽略令牌存储安全： 前端使用 HttpOnly Cookie 存储令牌，后端使用安全内存或专用令牌服务，避免 XSS 泄露。