目录
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的认证结果；
- 在 SSO 架构中，所有应用（Service Providers, SPs）都放弃了自主验证用户身份的权限，转而无条件地信任 IdP 做出的认证决定。
- 如何保障信任关系：每个 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. 创建本地会话，返回受保护资源
完整的"创建全局会话"包含两个相互关联的动作：
-
服务器端（IdP侧）： 在IdP的服务器上（例如在内存、Redis或数据库中）创建一个会话记录。
-
客户端（浏览器侧）： 在用户的浏览器中，设置一个属于IdP域名的Cookie，其值通常就是这个服务器端会话记录的ID。