3. SSO 主流协议：CAS、SAML2.0 与 OIDC 深度解析
单点登录的实现依赖于标准化的协议来安全地传递身份断言与授权信息。当前生产环境中最主流的三种协议分别是 CAS (Central Authentication Service)、SAML 2.0 (Security Assertion Markup Language) 和 OIDC (OpenID Connect)。理解它们的流程、数据格式与适用场景，是设计高可用会话管理架构的基础。
3.1 CAS 协议流程解析
CAS 是耶鲁大学发起的老牌 SSO 协议，专为 Web 应用设计，核心思想是通过 Ticket（票据）在客户端、服务端与 CAS 服务器之间传递认证状态。
核心票据与角色
| 角色/组件 | 说明 |
|---|---|
| CAS Server | 集中认证服务器，负责验证用户身份并发放 Ticket。 |
| CAS Client | 受保护的应用，拦截未认证请求并重定向到 CAS Server。 |
| TGT (Ticket Granting Ticket) | 用户登录成功后，CAS Server 在客户端浏览器 Cookie 中写入的长期票据，用于免密换取 ST。 |
| ST (Service Ticket) | 针对特定服务的短期一次性票据，由 CAS Server 发放给应用验证用户身份。 |
CAS 协议经典流程（Proxy 模式简化版）
- 访问资源：用户请求受保护的 Client 应用，Client 检测到未认证，重定向到 CAS Server 的登录地址，并附带 Service 参数（回调地址）。
- 统一认证：用户在 CAS Server 输入凭证。验证成功后，Server 生成 TGT 写入浏览器 Cookie，并生成一个 ST，重定向回 Client 并附带 ST。
- 票据验证：Client 收到 ST 后，通过后台 HTTP 请求（
/serviceValidate）向 CAS Server 验证 ST 的有效性。验证通过后，Server 返回包含用户身份信息的 XML 响应。 - 建立本地会话：Client 根据返回的用户信息创建本地会话（如 Session），后续请求不再需要与 CAS Server 交互。
关键设计点：ST 是一次性的，且具有极短的有效期（通常 5 分钟），防止重放攻击。TGT 存储在 CAS Server 端，通过浏览器 Cookie 中的 TGC（Ticket Granting Cookie）关联。
3.2 SAML 2.0 协议解析
SAML 2.0 基于 XML 标准，是企业级跨域 SSO 的事实标准。它通过 断言（Assertion） 在身份提供者（IdP）和服务提供者（SP）之间传递身份与属性信息。
核心概念
| 概念 | 说明 |
|---|---|
| IdP (Identity Provider) | 负责用户认证并签发 SAML 断言。 |
| SP (Service Provider) | 依赖 IdP 进行认证的应用，消费断言。 |
| SAML Assertion | 包含认证、属性、授权决策的 XML 文档，由 IdP 签名。 |
| Binding | 定义如何传输 SAML 消息，常见有 HTTP Redirect、HTTP POST、Artifact。 |
SP 发起 SSO 流程（Redirect/POST 绑定）
- SP 生成 AuthnRequest：用户访问 SP 资源，SP 生成一个签名的 SAML 请求，通过浏览器重定向（Redirect）或自动提交表单（POST）发送给 IdP。
- IdP 认证用户：IdP 解析请求，验证签名，提示用户登录（或使用已有会话）。
- IdP 生成断言：认证成功后，IdP 生成包含用户身份、属性、会话信息的 SAML 断言，并使用 IdP 私钥签名。
- IdP 发送响应：IdP 将 SAML 响应（包含断言）通过浏览器 POST 回 SP 的 Assertion Consumer Service (ACS) URL。
- SP 验证并建立会话：SP 验证断言签名、时间戳、受众限制等，提取用户信息，建立本地会话。
性能与安全考量：SAML 断言体积较大（XML 格式），且 IdP 与 SP 之间需要预配置信任证书。在异步任务编排场景中，解析和验证 XML 签名可能成为性能瓶颈，建议使用缓存策略缓存已验证的断言元数据。
3.3 OIDC 协议解析
OIDC (OpenID Connect) 是基于 OAuth 2.0 的身份认证层，专为现代 Web、移动端和 API 设计。它使用 JWT (JSON Web Token) 作为身份令牌（ID Token），格式轻量、易于解析和验证。
核心概念
| 概念 | 说明 |
|---|---|
| OP (OpenID Provider) | 类似 IdP，负责认证并签发 ID Token 和 Access Token。 |
| RP (Relying Party) | 类似 SP，依赖 OP 进行认证的应用。 |
| ID Token | JWT 格式，包含用户身份信息（sub、name、email 等），由 OP 签名。 |
| UserInfo Endpoint | OP 提供的 API，RP 可使用 Access Token 获取更详细的用户声明。 |
授权码流程（最推荐的生产流程）
- RP 发起认证请求：用户访问 RP，RP 构造授权请求 URL，包含
response_type=code、client_id、redirect_uri、scope=openid，重定向到 OP。 - OP 认证用户：OP 验证用户身份，用户同意授权（首次或必要时）。
- OP 返回授权码：OP 重定向回 RP 的
redirect_uri，并附带一个一次性授权码（code）。 - RP 换取 Token：RP 通过后端安全通道（HTTP POST）向 OP 的 Token Endpoint 发送
code、client_secret等。OP 验证后返回 ID Token 和 Access Token。 - RP 验证 ID Token：RP 使用 OP 的公钥（通过 JWKS Endpoint 获取）验证 ID Token 的签名、iss、aud、exp 等字段，提取用户身份。
- （可选）获取 UserInfo：RP 使用 Access Token 调用 UserInfo Endpoint 获取额外声明。
异步任务编排优势：OIDC 的 ID Token 是自包含的 JWT，无需像 SAML 那样进行额外的后台断言查询。在异步架构中，服务可以直接解析 JWT 获取用户身份，非常适合微服务网关和异步事件驱动的会话管理。
3.4 三大协议对比总结
| 维度 | CAS | SAML 2.0 | OIDC |
|---|---|---|---|
| 传输格式 | XML (Ticket 验证响应) | XML (SAML Assertion) | JSON (JWT) |
| 令牌类型 | ST (Service Ticket) | SAML Assertion | ID Token (JWT) + Access Token |
| 签名方式 | 后台 Server 验证 | XML Signature | JWS (JSON Web Signature) |
| 适用场景 | 传统 Java Web 应用 | 企业级、跨域、SaaS | 移动端、SPA、微服务、API |
| 协议复杂度 | 低 | 高 | 中 |
| 异步友好度 | 中（需后台验证 ST） | 低（XML 解析重） | 高（JWT 自包含） |
| 标准化组织 | Apereo | OASIS | OpenID Foundation |
3.5 协议选型建议
- 遗留系统集成：如果现有系统大量使用 Java Servlet 容器且需要快速集成，CAS 协议成熟稳定，但需注意其 Ticket 验证的同步开销。
- 企业级跨域联邦：需要与合作伙伴或内部多个 IdP 建立信任关系时，SAML 2.0 是必选项，尽管其 XML 处理复杂，但生态完善。
- 现代云原生架构：对于微服务、移动端、单页应用，OIDC 是首选。其 JWT 格式天然适合异步任务编排，服务间可以直接通过解析 Token 完成身份传递，无需同步调用认证中心。