2. SSO核心原理

2.1 认证中心（Authentication Center）—— SSO的“大脑”

认证中心是SSO体系中最核心的基础设施，所有子系统的登录验证、会话管理、票据签发与校验都依赖它。它本质上是一个独立的认证服务，负责回答三个问题：“你是谁？”（身份验证）、“你能访问什么？”（授权判定）、“你登录过没有？”（会话状态）。

认证中心在SSO架构中的位置如下图所示：

2.2 全局会话与局部会话

SSO通过两级会话机制实现“一次登录，到处通行”：全局会话（Global Session） 和 局部会话（Local Session）。理解两者的关系是掌握SSO原理的关键。

两级会话的交互流程如下：

2.3 票据（Ticket）机制

票据是SSO体系中传递认证信息的核心载体，本质上是认证中心签发的一段加密数据。不同的票据承担不同的职责，构成完整的信任链。

2.3.1 票据类型与职责

2.3.2 票据交换流程（CAS协议为例）

1. 用户访问应用A → 应用A检测到无局部会话，重定向到认证中心。
2. 认证中心验证身份 → 用户提交凭证，认证中心验证通过后创建全局会话，签发TGT（存入Cookie），并生成ST。
3. ST传递给应用A → 认证中心将ST附加在重定向URL中，用户浏览器携带ST回到应用A。
4. 应用A校验ST → 应用A通过后台通道（Back Channel）向认证中心验证ST的有效性，验证通过后创建局部会话。
5. 用户访问应用B → 应用B检测到无局部会话，重定向到认证中心。认证中心检测到TGT（全局会话存在），直接签发新的ST，无需用户再次登录。

// 票据校验的典型后端调用（伪代码）
// 应用系统向认证中心验证ST
POST /cas/serviceValidate
Params: 
  service = https://app.example.com/
  ticket  = ST-12345-abcdef

// 认证中心返回XML/JSON格式的校验结果
Response (成功):
{
  "serviceResponse": {
    "authenticationSuccess": {
      "user": "zhangsan",
      "attributes": {
        "email": "zhangsan@example.com",
        "roles": ["admin", "user"]
      }
    }
  }
}

Response (失败):
{
  "serviceResponse": {
    "authenticationFailure": {
      "code": "INVALID_TICKET",
      "description": "票据 ST-12345-abcdef 无效或已过期"
    }
  }
}

2.4 SSO的信任传递模型

SSO的核心挑战在于：如何让多个互不信任的应用系统，信任同一个认证中心签发的票据？ 信任传递模型解决了这个问题，它定义了信任的建立、传递和验证机制。

2.4.1 信任模型分类

2.4.2 直接信任模型（最常用）

在企业SSO场景中，直接信任模型是最主流的方案。所有应用系统在启动时向认证中心注册，获取共享密钥或公钥证书。认证中心签发的票据使用该密钥加密或签名，应用系统通过验证签名来确认票据的真实性。

2.4.3 信任传递的关键原则

• 信任不传递原则： 应用系统只信任认证中心，不信任其他应用系统。应用A不能为应用B签发票据，防止横向越权。
• 最小信任原则： 每个应用系统只拥有验证票据所需的最小密钥信息，不持有认证中心的根密钥。
• 票据防篡改： 票据必须包含数字签名或MAC（消息认证码），确保传输过程中不被篡改。
• 时间窗口约束： 票据的有效期必须严格控制，ST通常只有几分钟，TGT不超过数小时，降低泄露风险。

2.5 本章小结