3. 主流SSO协议对比
在单点登录工程落地中，协议选型直接决定架构复杂度、安全边界与生态兼容性。当前工业界最成熟的四种协议——CAS、SAML2.0、OAuth2.0 与 OpenID Connect (OIDC)——分别诞生于不同历史时期，解决的核心问题各有侧重。本节从协议本质、消息流、令牌格式、适用场景四个维度进行横向对比。
3.1 协议定位与核心差异
| 维度 | CAS | SAML2.0 | OAuth2.0 | OpenID Connect |
|---|---|---|---|---|
| 诞生时间 | 2004 (耶鲁大学) | 2005 (OASIS) | 2012 (IETF RFC 6749) | 2014 (OpenID Foundation) |
| 核心目标 | Web SSO | 跨域身份联邦 | 授权委托 | 认证 + 授权 |
| 令牌格式 | Ticket (ST/TGT) | XML Assertion (SAML Response) | Access Token (不透明/JWT) | ID Token (JWT) + Access Token |
| 传输绑定 | HTTP Redirect / POST | HTTP POST / Redirect / SOAP | HTTP JSON (RESTful) | HTTP JSON (RESTful) |
| 是否包含用户信息 | 否 (需额外接口) | 是 (Attribute Statement) | 否 (仅授权) | 是 (ID Token Claims) |
| 移动端/API友好度 | 低 (依赖Cookie) | 低 (XML解析重) | 高 (Bearer Token) | 高 (JWT轻量) |
选型第一原则： 如果只需要企业内部Web应用SSO，CAS是最轻量的选择；如果需要跨企业/跨域身份联邦，SAML2.0仍是事实标准；如果构建的是现代微服务/移动端体系，OIDC + OAuth2.0是唯一推荐组合。
3.2 协议消息流对比
四种协议的核心交互均围绕 用户代理 → 服务提供者(SP) → 身份提供者(IdP) 三角模型展开，但消息载体与跳转次数差异显著。
关键观察： CAS和SAML2.0依赖浏览器端重定向传递令牌，适合传统Web；OAuth2.0和OIDC原生支持客户端直接与授权服务器交互，更适合API网关和移动端架构。
3.3 令牌结构与安全特性
| 协议 | 令牌类型 | 是否签名 | 是否加密 | 用户身份嵌入 | 防重放机制 |
|---|---|---|---|---|---|
| CAS | Service Ticket (ST) | 否 (服务端校验) | 否 | 否 | 一次性使用 + 短TTL |
| SAML2.0 | SAML Assertion | 必选 (XML Signature) | 可选 (XML Encryption) | 是 (AttributeStatement) | Assertion ID + NotBefore/NotOnOrAfter |
| OAuth2.0 | Access Token | 可选 (JWT格式时) | 否 | 否 | Bearer Token + TLS + 短TTL |
| OIDC | ID Token (JWT) | 必选 (JWS) | 可选 (JWE) | 是 (sub + claims) | jti + iat + nonce |
安全红线： 生产环境中，OAuth2.0的Access Token必须通过TLS传输，且建议使用JWT格式并验证签名；SAML2.0必须启用XML签名校验，禁止关闭签名仅用加密；CAS的ST必须一次性使用，且TTL不应超过60秒。
3.4 各协议适用场景对比表
| 场景 | 推荐协议 | 理由 |
|---|---|---|
| 企业内部Web应用SSO (Java/.NET生态) | CAS | 部署简单，与Spring Security/Shiro集成成熟，无额外依赖 |
| 跨企业/跨组织身份联邦 (教育、政府、供应链) | SAML2.0 | 标准化程度最高，支持复杂属性交换，企业IdP (ADFS/Okta) 原生支持 |
| 第三方应用授权 (登录、GitHub登录) | OAuth2.0 | 授权委托模型，不暴露用户凭证，支持细粒度scope |
| 现代移动App + 微服务后端SSO | OpenID Connect | JWT轻量、支持原生App PKCE、ID Token直接携带用户信息 |
| 单页应用 (SPA) 无后端SSO | OIDC + Authorization Code + PKCE | 避免隐式流安全风险，Refresh Token轮换机制 |
| IoT/设备间认证 (无浏览器场景) | OAuth2.0 Device Grant | 设备码流，用户通过另一设备完成认证 |
| 遗留系统SSO改造 (不支持HTTP重定向) | SAML2.0 SOAP Binding | 支持后台SOAP消息交换，无需用户代理参与 |
3.5 协议选型决策树
在实际工程落地中，可按照以下决策路径快速锁定协议：
- 是否有浏览器参与？
- 是 → 进入第2步
- 否 → 使用 OAuth2.0 Device Grant 或 SAML2.0 SOAP
- 是否需要跨企业/跨域身份联邦？
- 是 → SAML2.0 (企业级) 或 OIDC (互联网级)
- 否 → 进入第3步
- 是否仅需认证，无需授权？
- 是 → CAS (纯Web) 或 OIDC (现代架构)
- 否 → 进入第4步
- 客户端类型？
- Web服务端渲染 → CAS 或 SAML2.0
- SPA / 移动App / 微服务 → OIDC + OAuth2.0
- 第三方授权 → OAuth2.0
3.6 工程落地建议
推荐组合： 在2024年的工程实践中，OpenID Connect + OAuth2.0 已成为事实上的首选组合。它同时覆盖认证与授权，JWT令牌天然适合微服务网关校验，且主流身份平台 (Keycloak、Auth0、Azure AD、Okta) 均以OIDC为首选协议。CAS和SAML2.0仅在遗留系统集成或特定合规场景下保留。
迁移路径： 如果现有系统使用CAS，可考虑在CAS 6.x版本中启用OIDC支持层，逐步将新应用接入OIDC，最终实现CAS到OIDC的平滑过渡，避免一次性全量迁移风险。