SSO（Single Sign On-单点登录）方案笔记

目录

• SSO的定义
  • SSO中的角色
• 和OAuth协议的区别？
• 多应用间的登录流程

---

SSO 其实是一套高度依赖中央授权服务器（IdP）的登录方案。

SSO的定义

SSO是一种身份验证机制，用户只需要使用一套凭据（比如用户名和密码）登录一次，就可以访问多个相互信任的应用程序或系统，而无需在每个应用中重新登录。

下文分析SSO如何达成这个目标。

SSO中的角色

graph TD U[用户] --> UA[用户代理/浏览器] UA --> SP1[服务提供者 A] UA --> SP2[服务提供者 B] UA --> SP3[服务提供者 C] SP1 --> IdP[身份提供者] SP2 --> IdP SP3 --> IdP IdP --> DS[目录服务] UA -.->|存储Cookie（全局通用）| IdP UA -.->|存储Cookie| SP1 UA -.->|存储Cookie| SP2 UA -.->|存储Cookie| SP3

• 用户（User）
  身份：需要访问应用程序的最终用户
  职责：
  - 提供身份凭证（用户名/密码等）
  - 发起认证请求
  - 管理个人会话
  特点：用户只需记住一套凭证，与IdP进行一次交互

• 服务提供者（Service Provider, SP）
  身份：具体的应用程序或服务（如CRM系统、邮箱、内部网站等）
  职责：
  - 保护资源，要求认证后才能访问；
  - 识别未认证的用户并将其重定向到IdP；
  - 验证从IdP收到的认证断言/令牌；
  - 管理本地应用会话；
  特点：SP本身不验证用户密码，完全信任IdP的认证结果；

  1. 在 SSO 架构中，所有应用（Service Providers, SPs）都放弃了自主验证用户身份的权限，转而无条件地信任 IdP 做出的认证决定。
  2. 如何保障信任关系：每个 SP 都预先在 IdP 那里“注册”了自己，双方约定好了加密密钥、证书和通信协议。没有这个预先建立的信任，SSO 无法工作。

• 身份提供者（Identity Provider, IdP）
  IdP 是整个SSO系统中唯一知道用户是谁、密码是什么、用户是否已登录的组件。它是所有身份信息的“唯一真相来源”。

  身份：中央认证服务器，SSO体系的核心
  职责：

  • 存储和管理用户身份信息；
  • 验证用户提交的凭证；
  • 创建和管理全局会话；
  • 生成安全的认证令牌/断言；
  • 响应SP的认证验证请求；

  特点：所有SP都信任IdP，IdP是"唯一真相来源"

• 用户代理（User Agent）
  身份：通常是Web浏览器，也可以是移动App等客户端

  职责：

  • 在用户、SP和IdP之间传递请求和响应；
  • 存储和管理Cookie（IdP的全局会话Cookie和各SP的本地会话Cookie）；
  • 处理HTTP重定向；

  特点：是实现SSO流程的一个工具载体。

• 目录服务（Directory Service）- 该角色可选
  身份：用户信息的存储后端（可选但常见）
  职责：

  • 存储用户身份数据（如Active Directory、LDAP、数据库）
  • 为IdP提供用户凭证验证服务

  特点：在实际企业部署中，IdP通常与目录服务集成

---

和OAuth协议的区别？

SSO和OAuth经常被一起提及，也常常被混淆，但它们解决的是两个完全不同的问题，只能说稍微有点相关性，但还是需要认真辨别出区别。

简单来说：

• SSO（单点登录）：是一个身份验证方案。
  它解决的是“你是谁？”的问题，让你用一套密码可以登录多个系统。

• OAuth 2.0：是一个授权方案。
  它解决的是“这个应用能否访问我的特定数据？”的问题，让你在不分享密码的情况下，授权第三方应用访问你的资源。

---

多应用间的登录流程

sequenceDiagram participant U as 用户浏览器 participant A as 应用A (SP) participant I as 认证中心 (IdP) participant B as 应用B (SP) Note over U, B: 第一阶段：用户首次访问应用A U->>A: 1. 访问应用A A->>U: 2. 发现未登录，重定向到IdP<br>（携带回调地址） U->>I: 3. 访问IdP登录页 Note right of U: 此时浏览器与IdP建立会话 I->>U: 4. 返回登录页面 U->>I: 5. 提交用户名/密码 I->>I: 6. 验证凭证，创建全局会话 I->>U: 7. 重定向回应用A<br>（携带令牌/Ticket） U->>A: 8. 带着令牌访问应用A A->>I: 9. 应用A与IdP后台通信，验证令牌 I->>A: 10. 返回用户信息（验证成功） A->>U: 11. 创建本地会话，返回受保护资源 Note over U, B: 第二阶段：用户访问应用B U->>B: 12. 访问应用B B->>U: 13. 发现未登录，重定向到IdP<br>（携带回调地址） U->>I: 14. 访问IdP（浏览器自动携带IdP会话Cookie） Note right of U: 关键步骤：<br>浏览器与IdP的会话仍然有效 I->>I: 15. 发现已有全局会话（用户已登录） I->>U: 16. 立即重定向回应用B<br>（携带新的令牌/Ticket） U->>B: 17. 带着新令牌访问应用B B->>I: 18. 应用B与IdP后台通信，验证新令牌 I->>B: 19. 返回用户信息（验证成功） B->>U: 20. 创建本地会话，返回受保护资源

完整的“创建全局会话”包含两个相互关联的动作：

1. 服务器端（IdP侧）： 在IdP的服务器上（例如在内存、Redis或数据库中）创建一个会话记录。

2. 客户端（浏览器侧）： 在用户的浏览器中，设置一个属于IdP域名的Cookie，其值通常就是这个服务器端会话记录的ID。