vault backup: 2026-07-13 11:11:37
This commit is contained in:
+75
-52
@@ -7,84 +7,107 @@ create time: 2026-07-13 10:03
|
||||
|
||||
## 概述
|
||||
|
||||
SSO（Single Sign-On，单点登录）是一种身份认证方案：用户只需登录一次，即可访问所有相互信任的应用系统。核心目标是**统一身份源、降低登录摩擦、集中安全管控**。
|
||||
想象你在一家公司上班：OA 系统一套账号、Git 一套账号、监控平台一套账号、Wiki 又一套账号。每套都要单独注册、单独登录、单独改密码。密码多了记不住就用同一个，一个泄露全军覆没。
|
||||
|
||||
> [!info] 什么时候需要 SSO？
|
||||
> 当你的组织内有 3 个以上的应用需要用户登录时，就该认真考虑 SSO 了。否则每多一个系统就多一套账号密码，用户体验和安全管控都是灾难。
|
||||
**SSO（Single Sign-On，单点登录）** 就是解决这个问题的：**登录一次，到处通行**。就像你办了一张公司门禁卡，刷卡进大楼之后，食堂、健身房、图书馆都认这张卡，不用每个地方再登记一次。
|
||||
|
||||
## 核心原理
|
||||
## 核心角色
|
||||
|
||||
SSO 的本质是一个**认证委托**模型：
|
||||
在理解 SSO 流程之前，先认识三个核心角色：
|
||||
|
||||
| 角色 | 全称 | 一句话解释 | 生活类比 |
|
||||
|------|------|-----------|----------|
|
||||
| **User** | End User | 使用系统的你 | 进门的人 |
|
||||
| **SP** | Service Provider（服务提供方） | 你实际要访问的业务系统 | 食堂、健身房 |
|
||||
| **IdP** | Identity Provider（身份提供商） | 统一认证中心，负责验证「你是谁」 | 前台门禁系统 |
|
||||
|
||||
> [!tip] SP 和 IdP 的关系
|
||||
> IdP 知道「你是谁」，SP 知道「你能干什么」。SP 不自己验身份，而是**委托** IdP 来做——就像食堂不查你的身份证，它只认门禁卡。
|
||||
|
||||
## 核心流程
|
||||
|
||||
SSO 的本质是「认证委托」—— SP 把「验证身份」这件事交给 IdP：
|
||||
|
||||
```mermaid
|
||||
sequenceDiagram
|
||||
participant U as 用户
|
||||
participant App as 业务应用
|
||||
participant IdP as 身份提供商 (IdP)
|
||||
participant U as 用户 (浏览器)
|
||||
participant App as 业务应用 (SP)
|
||||
participant IdP as 认证中心 (IdP)
|
||||
|
||||
U->>App: 1. 访问受保护资源
|
||||
App->>IdP: 2. 重定向到登录页
|
||||
U->>IdP: 3. 输入凭证
|
||||
IdP-->>U: 4. 颁发 SSO Token / Session
|
||||
IdP->>App: 5. 回调 + 认证凭证
|
||||
App->>IdP: 6. 验证凭证有效性
|
||||
IdP-->>App: 7. 返回用户身份信息
|
||||
App-->>U: 8. 授予访问权限
|
||||
U->>App: 1. 访问受保护的页面
|
||||
App->>U: 2. 「你还没登录，去认证中心吧」<br/>浏览器地址栏变成 IdP 的网址
|
||||
U->>IdP: 3. 在 IdP 页面输入账号密码
|
||||
IdP-->>U: 4. 验证通过，给用户一个「凭证」
|
||||
IdP->>App: 5. 把用户带回 SP，同时带上「凭证」
|
||||
App->>IdP: 6. SP 后端拿着凭证去 IdP 校验真伪
|
||||
IdP-->>App: 7. 「凭证是真的，用户是张三」
|
||||
App-->>U: 8. 登录成功，放行访问
|
||||
```
|
||||
|
||||
三个核心角色：
|
||||
> [!info] 浏览器重定向是什么意思？
|
||||
> 步骤 2 和 5 涉及「浏览器重定向」—— 你的浏览器地址栏会从 `app.example.com` 跳到 `idp.example.com`，登录完再跳回来。这不是后台偷偷发生的，你能看到地址栏在变。
|
||||
|
||||
| 角色 | 全称 | 职责 |
|
||||
|------|------|------|
|
||||
| **User** | End User | 发起请求的终端用户 |
|
||||
| **SP** | Service Provider（服务提供方） | 业务应用，依赖 IdP 做认证 |
|
||||
| **IdP** | Identity Provider（身份提供商） | 统一认证中心，管理用户身份 |
|
||||
## SSO 的两种实现思路
|
||||
|
||||
> [!tip] SP vs IdP
|
||||
> 简单记忆：IdP 知道「你是谁」，SP 知道「你能干什么」。SP 把「你是谁」这件事委托给了 IdP。
|
||||
### 思路一：共享 Cookie（简单但受限）
|
||||
|
||||
## 主流协议概览
|
||||
所有应用都在同一个主域下（如 `oa.company.com`、`git.company.com`），IdP 在 `.company.com` 这个顶级域上写一个 Cookie，所有子域都能读到。
|
||||
|
||||
| 协议 | 时代 | 传输方式 | 典型场景 |
|
||||
|------|------|----------|----------|
|
||||
| CAS | 2000+ | 浏览器重定向 + Ticket | 企业内部门户、高校系统 |
|
||||
| SAML 2.0 | 2005+ | XML + 浏览器重定向 | 企业级 SSO、SaaS 集成 |
|
||||
| OAuth 2.0 | 2012+ | HTTPS API | 第三方授权、API 访问控制 |
|
||||
| OIDC | 2014+ | HTTPS API (JWT) | 现代 Web / 移动端 / SPA |
|
||||
```mermaid
|
||||
graph LR
|
||||
A[用户登录 idp.company.com] -->|写入 .company.com Cookie| B[oa.company.com 读取同一 Cookie]
|
||||
A --> C[git.company.com 读取同一 Cookie]
|
||||
A --> D[wiki.company.com 读取同一 Cookie]
|
||||
```
|
||||
|
||||
详细文档见各子笔记：
|
||||
- ✅ 实现简单，不需要复杂的协议
|
||||
- ❌ 所有应用必须在同一个主域下，跨域就不行了
|
||||
- ❌ 安全性低，一个子域被攻破可能波及全部
|
||||
|
||||
- [[sso/sso-oauth2|OAuth 2.0 授权码模式]]
|
||||
- [[sso/sso-oidc|OpenID Connect (OIDC)]]
|
||||
- [[sso/sso-saml|SAML 2.0]]
|
||||
- [[sso/sso-cas|CAS 协议]]
|
||||
- [[sso/sso-comparison|协议对比与选型指南]]
|
||||
### 思路二：分布式 Token（主流方案）
|
||||
|
||||
## 关键概念
|
||||
IdP 登录成功后颁发一个签名的 **Token**（令牌），各个 SP 独立验证这个 Token 的真伪，不需要和 IdP 实时通信。
|
||||
|
||||
### Session 与 Token 的区别
|
||||
- ✅ 跨域、跨平台、跨组织无障碍
|
||||
- ✅ SP 之间互不依赖
|
||||
- ✅ 支持移动端、SPA 等各种客户端
|
||||
- ❌ 实现稍复杂，需要用到标准协议（OIDC/SAML 等）
|
||||
|
||||
> **这是当前主流方案**，后面介绍的四种协议（CAS、SAML、OAuth 2.0、OIDC）都是基于这种思路。
|
||||
|
||||
## 关键概念速查
|
||||
|
||||
### Session vs Token
|
||||
|
||||
| 维度 | Session-Cookie | Token (JWT) |
|
||||
|------|---------------|-------------|
|
||||
| 存储位置 | 服务端 | 客户端 |
|
||||
| 扩展性 | 需要共享 Session Store | 天然无状态 |
|
||||
| 跨域 | Cookie 受同源策略限制 | Header 传递，无跨域问题 |
|
||||
| 撤销 | 删除 Session 即可 | 需要黑名单或短过期时间 |
|
||||
| **存在哪** | 服务端（需要内存/数据库存储） | 客户端（浏览器/手机自己存） |
|
||||
| **怎么验证** | 每次请求带上 Cookie，服务端查表 | Token 自带签名，服务端本地验签即可 |
|
||||
| **跨域能力** | Cookie 受浏览器同源策略限制，只能同域 | 放在 HTTP Header 里传，没有域限制 |
|
||||
| **扩展性** | 多个 SP 需要共享 Session Store | 天然无状态，SP 各自验证即可 |
|
||||
| **怎么注销** | 删掉服务端 Session 就行 | Token 发出去就收不回，靠短过期时间 |
|
||||
|
||||
### SSO 的两种实现思路
|
||||
### 什么是 CSRF 攻击？
|
||||
|
||||
**1. 共享 Session（Cookie Domain 共享）**
|
||||
**CSRF（Cross-Site Request Forgery，跨站请求伪造）**：攻击者诱导你的浏览器向目标网站发请求，浏览器自动带上 Cookie，目标网站以为是你本人操作。
|
||||
|
||||
IdP 登录后写入一个顶级域的 Cookie，所有 SP 通过访问 IdP 的验证端点来确认登录状态。实现简单但受限于同主域。
|
||||
> 类比：有人拿你签过名的空白支票去取钱，银行看到你的签名就放行了。`state` 参数的作用就是在支票上写明「这张支票是给谁用的」，防止被冒领。
|
||||
|
||||
**2. 分布式 Token（标准协议方式）**
|
||||
### 什么是重放攻击？
|
||||
|
||||
IdP 颁发 Token，SP 独立验证。跨域、跨平台无障碍，是当前主流方案。
|
||||
攻击者截获了一个有效的请求（比如登录凭证），然后**原样再发一次**，欺骗服务器以为是新的合法请求。
|
||||
|
||||
> [!warning] 安全要点
|
||||
> - 始终使用 HTTPS，Token 一旦泄露等同于身份被盗
|
||||
> - Token 有效期不宜过长，Access Token 建议 5-30 分钟
|
||||
> - 使用 `state` 参数防 CSRF，`nonce` 参数防重放攻击
|
||||
> 类比：你用过的电影票被别人捡到，拿去再刷一次入场。`nonce`（Number used ONCE）参数的作用就是给每张票打上唯一编号，用过就作废。
|
||||
|
||||
## 推荐阅读顺序
|
||||
|
||||
如果你是第一次接触 SSO，建议按以下顺序阅读：
|
||||
|
||||
1. **本文** — 建立整体认知
|
||||
2. [[sso/sso-oauth2|OAuth 2.0 授权码模式]] — 理解「授权」和「认证」的区别
|
||||
3. [[sso/sso-oidc|OpenID Connect (OIDC)]] — 在 OAuth 2.0 基础上补齐「认证」
|
||||
4. [[sso/sso-comparison|协议对比与选型指南]] — 了解全景，学会选型
|
||||
5. [[sso/sso-saml|SAML 2.0]] / [[sso/sso-cas|CAS 协议]] — 按需阅读，了解企业级和传统方案
|
||||
|
||||
## 关联笔记
|
||||
|
||||
|
||||
Reference in New Issue
Block a user