SSO 单点登录完全指南：CAS、OIDC 与 SAML 协议详解

什么是 SSO？

单点登录（Single Sign-On, SSO） 是一种身份验证机制，允许用户使用一组凭证（如用户名和密码）登录一次，即可访问多个相互信任的应用程序或系统。它消除了重复登录的繁琐，同时集中了用户身份管理，在企业、云服务和教育机构中广泛使用。

SSO 的核心价值：

• 用户体验提升：一次登录，处处通行。
• 安全性增强：减少密码疲劳，便于实施强密码策略和多因素认证。
• 管理简化：统一用户身份生命周期，降低运维成本。

常见的 SSO 实现协议包括 CAS、OIDC 和 SAML，本教程将带你理解它们的原理、区别以及如何选择。

三大主流 SSO 协议总览

接下来，我们逐一深入拆解这三种协议的工作流程和实现要点。

CAS 协议：经典的集中式认证

CAS 角色与核心概念

CAS 架构包含三个主体：

1. 浏览器（用户）：发起访问。
2. CAS 客户端（应用）：需要保护的应用，支持 CAS 协议。
3. CAS 服务端（认证中心）：集权认证服务器，负责签发和验证票据。

核心对象：

• TGT (Ticket Granting Ticket)：用户登录成功后，CAS 服务端生成的全局会话凭证，存储在浏览器 Cookie（称为 TGC）。
• ST (Service Ticket)：用于访问特定应用的一次性票据，由 CAS 服务端签发，应用用其向 CAS 服务端验证用户身份。

CAS 认证流程（简化版）

1. 未登录访问应用
   用户访问 app.example.com，客户端检测到无本地会话，将浏览器重定向到 CAS 服务端，携带 service 参数（应用回调地址）。
2. CAS 认证
   CAS 服务端检查是否存在有效的 TGC（即用户是否已全局登录）。
   • 若未登录：展示登录页面，用户提交凭证，CAS 验证并生成 TGT，下发 TGC Cookie。
   • 若已登录：直接跳过认证。
3. 签发 ST 并回调
   CAS 服务端生成一次性 ST，并通过浏览器重定向传回应用：app.example.com?ticket=ST-xxx。
4. 应用验证 ST
   应用收到 ST 后，后端向 CAS 服务端发起验证请求（如 /serviceValidate），获取用户身份信息，建立局部会话。
5. 后续访问
   用户在各应用间通过局部会话维持登录态，无需再次与 CAS 交互，直到退出。

示例请求（CAS 3.0 协议）：

# 1. 重定向到 CAS 登录
GET https://cas.example.com/cas/login?service=https://app.example.com/callback

# 2. 验证 ST
GET https://cas.example.com/cas/serviceValidate?service=https://app.example.com/callback&ticket=ST-1-XXXXX

CAS 协议的特点

• 优点：协议轻量，易于理解和部署；仅需 HTTP 重定向，对应用侵入小。
• 缺点：主要面向 Web 场景，对移动/SPA 支持需额外适配；本身不配置标准化的单点登出（需扩展）。
• 典型实现：Apereo CAS（开源 Java 实现）。

SAML 2.0：企业级联邦身份认证

SAML 的核心角色与流程

SAML 定义了三个角色：

• 用户代理（浏览器）：通常作为中间人。
• 服务提供商（SP, Service Provider）：需要用户登录的应用。
• 身份提供商（IdP, Identity Provider）：认证用户并签发断言。

关键概念：

• SAML 断言（Assertion）：包含用户身份信息和属性的 XML 安全声明。
• 绑定（Binding）：断言如何在 SP 和 IdP 之间传输，常见的有 HTTP Redirect 绑定和 HTTP POST 绑定。

SAML 认证流程（SP 发起）

1. 用户访问 SP
   SP 生成 SAML 认证请求（AuthnRequest），并对请求进行签名，将其通过浏览器重定向（HTTP Redirect）发送给 IdP。
2. IdP 认证用户
   如果用户尚未在 IdP 登录，IdP 显示登录表单；如果已有会话，则直接生成断言。
3. IdP 返回 SAML 响应
   IdP 构建包含 SAML 断言的响应，对其进行数字签名，并通过浏览器 POST 提交到 SP 的 断言消费者服务（ACS） URL。
4. SP 验证断言
   SP 验证响应签名、断言有效期、受众等，从中提取用户身份（如 NameID）和属性，建立本地会话。
5. 用户获得访问权限

简化消息流示例：

AuthnRequest（SP→IdP）:
<samlp:AuthnRequest ... AssertionConsumerServiceURL="https://sp.example.com/acs">
  <saml:Issuer>sp-entity-id</saml:Issuer>
</samlp:AuthnRequest>

SAML Response（IdP→SP，Base64 编码后通过 POST 表单提交）:
<samlp:Response ...>
  <saml:Assertion>
    <saml:Subject><saml:NameID>user@example.com</saml:NameID></saml:Subject>
    <saml:AttributeStatement>...</saml:AttributeStatement>
  </saml:Assertion>
</samlp:Response>

SAML 协议的特点

• 优点：安全模型完善（签名、加密、条件约束），支持跨域联合身份，被大量企业应用（如 Salesforce、Office 365）原生支持。
• 缺点：XML 解析开销大，移动端支持较差，配置较复杂（需交换元数据）。
• 实现：Shibboleth、SimpleSAMLphp、Keycloak（多协议支持）。

OIDC：现代身份验证标准

OIDC 是什么？

OpenID Connect 是构建在 OAuth 2.0 之上的身份层，将 OAuth 2.0 的授权能力扩展为身份验证。它使用 JSON Web Token (JWT) 作为身份令牌，自然适合现代 Web、移动和 API 场景。

核心参与者：

• 终端用户：拥有身份的人。
• 客户端（RP, Relying Party）：需要验证用户身份的应用。
• OpenID 提供者（OP, OpenID Provider）：认证用户并签发 ID Token 的服务器。

OIDC 关键令牌

• ID Token：证明用户身份认证的 JWT，包含用户标识（sub）、签发者、过期时间等声明。
• Access Token：OAuth 2.0 访问令牌，用于调用 API，可选在 OIDC 中一并获取。
• UserInfo Endpoint：通过 Access Token 获取更多用户属性的标准化端点。

OIDC 认证流程（授权码模式，Web 应用推荐）

1. 用户访问 RP，RP 重定向到 OP 的 authorize 端点，携带 response_type=code、scope=openid、redirect_uri 等参数。
2. OP 认证用户（如显示登录界面），获取用户同意授权。
3. OP 返回授权码（通过浏览器重定向到 RP 的回调地址）。
4. RP 使用授权码向 OP 的 token 端点发起后端请求，请求中包含 grant_type=authorization_code 和客户端密钥。
5. OP 验证后，返回 ID Token 和 Access Token。
6. RP 验证 ID Token 签名和声明，建立登录会话，并可选择用 Access Token 调用 UserInfo 端点获取更多用户资料。

请求示例：

# 1. 认证请求
GET /authorize?
  response_type=code
  &client_id=myapp
  &redirect_uri=https://app.example.com/callback
  &scope=openid%20profile%20email
  &state=random_string

# 2. Token 请求（后端）
POST /token
Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code
&code=authorization_code_value
&redirect_uri=https://app.example.com/callback
&client_id=myapp
&client_secret=secret

返回的 ID Token 示例载荷：

{
  "iss": "https://op.example.com",
  "sub": "248289761001",
  "aud": "myapp",
  "exp": 1311281970,
  "iat": 1311280970,
  "email": "user@example.com"
}

OIDC 协议的特点

• 优点：基于 REST/JSON，轻量且开发者友好；支持多种认证流程（授权码、隐式、混合），适应 SPA、移动端、服务器端 Web；无缝集成 OAuth 2.0 授权，易于构建同时鉴权和授权场景。
• 缺点：需要 HTTPS 保护；相对 SAML，企业级身份联合特性较弱（需扩展联邦）。
• 实现：Keycloak、Auth0、Azure AD、Okta。

三大协议对比与选型建议

技术维度对比

场景化选型指南

• 传统企业内部 Web 系统，已有 CAS 基础：继续使用 CAS，或迁移至 Keycloak 同时支持 CAS 和 OIDC。
• 跨企业联合身份（B2B SaaS）：SAML 2.0 是默认选择，几乎所有大型 IAM 产品都原生支持。
• 新建现代应用（Web、移动、API）：首选 OIDC，因为它开发效率高，生态丰富，且能同时解决认证和授权。
• 教育或科研机构：Apereo CAS 有大量部署，可结合 Shibboleth 连接 SAML 联邦。
• 需要快速集成社交登录（Google、GitHub）：它们都基于 OIDC。

实现 SSO 的通用步骤

无论选择哪种协议，集成 SSO 通常要完成以下工作：

1. 规划身份提供方：自建（如 Keycloak、CAS）还是云服务（Auth0、Okta、Azure AD）。
2. 注册应用：在身份提供方管理后台注册每个客户端，获取 client_id、secret、回调 URL 等。
3. 安装集成库：应用端添加对应协议的 SDK 或依赖（如 mod_auth_cas、Spring Security SAML、oidc-client）。
4. 配置认证流程：在应用代码或中间件中配置协议端点、证书、声明映射。
5. 处理会话与注销：实现局部登录状态维护，配合全局登出使各应用同步登出。
6. 测试与部署：确保跨浏览器、跨域、HTTPS 等均正常工作。

常见问题与排错思路

• 回调地址不匹配：必须与身份提供方注册的完全一致（包括路径、端口和协议）。
• 时间不同步：SAML 断言和 JWT 有时间窗口，确保服务器 NTP 同步。
• 证书信任：SAML 需要配置用于验证签名的公钥证书；OIDC 需获取 OP 的 JWKS 端点公钥。
• 跨域 Cookie：现代浏览器对第三方 Cookie 限制会影响基于重定向的 SSO，需考虑 SameSite 策略。
• 登出同步：单点登出（SLO）实现较复杂，可采用前端渠道（如 Opener iframe）或后端通道通知。

结尾

SSO 早已成为现代身份管理中不可或缺的组件。CAS 简单直接，适合特定场景；SAML 为企业联合提供了坚实的安全框架；OIDC 则是云原生时代的首选。理解它们的设计哲学和适用边界，能帮助你在架构中选择最合适的方案，构建既安全又流畅的用户登录体验。

若要动手实践，推荐从 Keycloak 或开源 CAS 入手，它们同时支持多种协议，能让你在同一平台上快速对比实验。

本文由“免费在线教程”团队撰写，专注高质量技术教程。欢迎分享与指正。