第二部分：协议与标准 on IDaaS Book

第5章：IAM OAuth 2.0 深度解读 — 授权模式、令牌管理与安全最佳实践 | IDaaS Book

Thu, 01 Feb 2024 00:00:00 +0800

5.1 设计哲学

OAuth 2.0（RFC 6749）是由 IETF 制定的授权框架，它的核心使命简单而明确：让用户可以在不向第三方应用暴露自己密码的情况下，授权该应用访问自己在服务提供商处的受保护资源。

OAuth 2.0 解决的真实问题

想象一个场景：你想让一个照片冲印应用访问你存在云盘上的照片。

没有 OAuth 的糟糕做法：你给冲印应用你的云盘用户名和密码。

冲印应用可以冒充你做任何事（不是只读照片，还能删除文件、修改设置）
你无法限制冲印应用的权限范围
你改密码后，冲印应用就失效了，但你得在所有第三方应用上重设
冲印应用的服务器被黑，你的密码就泄露了

OAuth 2.0 的做法：

冲印应用重定向你到云盘的授权页面
你（在云盘的页面上）登录并确认"允许冲印应用读取照片"
云盘给冲印应用发一个访问令牌（Access Token），只能读照片，有效期 1 小时
冲印应用用这个令牌访问你的照片
你随时可以在云盘上撤销这个授权

5.2 核心角色

OAuth 2.0 定义了四个核心角色：

资源所有者（Resource Owner）
 │ 通常是终端用户
 │ 拥有受保护资源的数据
 ▼
客户端（Client）
 │ 第三方应用，想访问资源
 │ 
 ▼
授权服务器（Authorization Server）
 │ 认证资源所有者，发放令牌
 │ 
 ▼
资源服务器（Resource Server）
 托管受保护资源的服务

5.3 授权模式（Grant Types）

OAuth 2.0 定义了四种核心授权模式，加上 PKCE 扩展和 Device Flow：

5.3.1 授权码模式（Authorization Code）

这是最安全、最广泛使用的模式。核心特征是用户浏览器不直接接触 Access Token——它只拿到一个一次性授权码（authorization code），由后端服务器用这个 code 去换 token，用户密码全程不经过客户端后端。

OAuth 2.0 授权码流程与 PKCE — IAM 认证授权核心协议图解 | IDaaS Book

Tue, 07 Jul 2026 00:00:00 +0800

为什么需要这份图解

OAuth 2.0 授权码流程（Authorization Code Flow）是所有现代身份协议的基础。OIDC 基于它、单页应用靠它、移动 App 也用它——但大部分资料要么只有文字描述，要么跳过了关键的安全细节。

这份图解的目标是：一图看懂完整交互，然后逐帧理解每个参数的设计意图和攻击面。

授权码流程完整时序图

下面是 OAuth 2.0 Authorization Code Flow 的标准交互，包含四个角色：用户（Resource Owner）、客户端（Client）、授权服务器（Authorization Server）和资源服务器（Resource Server）。

 sequenceDiagram
 actor User as 用户<br/>(Resource Owner)
 participant Client as 客户端<br/>(Client)
 participant AS as 授权服务器<br/>(Authorization Server)
 participant RS as 资源服务器<br/>(Resource Server)

 Note over User,RS: ═══ 第一步：发起授权请求 ═══
 User->>Client: 1. 点击「使用 XX 账号登录」
 Client->>Client: 2. 构造授权请求 URL<br/>含 client_id, redirect_uri,<br/>response_type=code, scope,<br/>state（防 CSRF 随机值）

 Note over User,RS: ═══ 第二步：用户授权 ═══
 Client->>User: 3. HTTP 302 重定向到<br/>授权服务器的 /authorize 端点
 User->>AS: 4. 浏览器跟随重定向，<br/>用户在授权服务器页面登录并确认授权
 AS->>AS: 5. 验证用户身份<br/>检查 client_id 和 redirect_uri<br/>是否与注册时一致

 Note over User,RS: ═══ 第三步：获取授权码 ═══
 AS->>User: 6. HTTP 302 重定向回<br/>redirect_uri?code=AUTH_CODE&state=xxx
 User->>Client: 7. 浏览器跟随重定向，<br/>将 code 和 state 传给客户端
 Client->>Client: 8. 验证 state 参数<br/>（防止 CSRF 攻击）

 Note over User,RS: ═══ 第四步：用授权码换令牌 ═══
 Client->>AS: 9. POST /token<br/>grant_type=authorization_code<br/>code=AUTH_CODE<br/>redirect_uri（再次发送以验证）<br/>client_id + client_secret
 AS->>AS: 10. 验证 code（一次性）<br/>验证 redirect_uri 一致性<br/>验证 client 身份
 AS->>Client: 11. 返回 {access_token,<br/>refresh_token, expires_in}

 Note over User,RS: ═══ 第五步：使用令牌访问资源 ═══
 Client->>RS: 12. GET /api/user<br/>Authorization: Bearer {access_token}
 RS->>AS: 13. （可选）验证 token<br/>introspect 或本地校验
 RS->>Client: 14. 返回受保护资源

每一步的设计意图

步骤	关键参数	为什么这么设计
2	`response_type=code`	指定使用授权码模式（不是 implicit）
2	`state`	随机值，防止 CSRF——客户端在第 8 步验证，攻击者无法伪造
2	`redirect_uri`	必须在授权服务器上预注册，防止令牌被重定向到攻击者控制的地址
4	用户在授权服务器页面上登录	客户端永远看不到用户的密码——这是 OAuth 的核心理念
6	`code` 通过浏览器返回	授权码作为中间凭证，即使被截获也没有用——因为没有 client_secret
9	`code` + `client_secret`	授权码 + 客户端密钥双重验证，确保只有合法客户端能换取 token
9	`redirect_uri` 再次发送	防止授权码被注入到其他客户端的回调中（mix-up attack 防护）
12	`Authorization: Bearer`	Bearer token——持有即有权，所以必须通过 HTTPS 传输

PKCE：授权码流程的安全补丁

PKCE（Proof Key for Code Exchange，RFC 7636） 是授权码流程的关键安全扩展。它最初为移动 App 设计（因为移动端无法安全存储 client_secret），但现在 OAuth 2.1 要求所有客户端都必须使用 PKCE。

OAuth 2.0 攻击面与防护 — IAM 安全威胁分析与防御指南 | IDaaS Book

Wed, 08 Jul 2026 00:00:00 +0800

为什么需要这份攻击面分析

OAuth 2.0 是 IDaaS 世界的授权语言，但它不是「用了就安全」的银弹。RFC 6749 在 2012 年发布时，某些安全假设（如「机密客户端不会运行在不可信环境」）在移动和 SPA 时代已经被打破。

理解 OAuth 的攻击面不是为了「破解 OAuth」，而是为了正确地实现它。以下五个攻击面是过去十年里真实发生过的漏洞模式，每一个都配有攻击流程图和防护措施。

五大攻击面总览

#	攻击面	根本原因	关键防护	相关规范
1	Redirect URI 劫持	授权服务器未严格校验 redirect_uri	精确匹配白名单	RFC 6749 §3.1.2
2	CSRF / State 参数缺失	客户端不验证 state	生成并验证随机 state	RFC 6749 §10.12
3	授权码拦截	无 PKCE 时授权码可被恶意 App 截获	PKCE（code_challenge + code_verifier）	RFC 7636
4	Mix-Up Attack	客户端未校验 issuer / 端点一致性	验证 iss 参数 + redirect_uri 二次校验	RFC 9207
5	Token 泄露与重放	Bearer Token 持有即有权	DPoP / mTLS sender-constraining + 短有效期	RFC 9449

1. Redirect URI 劫持

攻击原理

攻击者诱导用户点击一个精心构造的授权链接，其中 redirect_uri 被替换为攻击者控制的地址。用户在授权服务器上正常登录后，授权码被重定向到攻击者服务器。

JWT 深入解读 — 结构、声明、验证与安全最佳实践 | IDaaS Book

Sun, 12 Jul 2026 00:00:00 +0800

JWT 是什么

JWT（JSON Web Token，RFC 7519） 是 IAM 领域最核心的数据格式之一。它不是认证协议，而是一种紧凑的、URL 安全的令牌格式，用于在双方之间传递声明（Claims）。OAuth 2.0 的 Access Token、OpenID Connect 的 ID Token 都使用 JWT 作为载体。

一句话理解：JWT 是一个自包含的、可验证的 JSON 对象——你把信息编码进去，接收方可以独立验证它的真实性和完整性，不需要回查颁发服务器。

JWT 在 IAM 中的角色

 graph LR
 A[认证请求] --> B[IDP 验证身份]
 B --> C[签发 JWT]
 C --> D1[Access Token<br/>访问 API]
 C --> D2[ID Token<br/>身份信息]
 C --> D3[Refresh Token<br/>续期]
 D1 --> E[Resource Server<br/>验证 JWT 签名和声明]
 D2 --> F[Client<br/>解析用户信息]

JWT 不解决「你是谁」的问题（那是认证协议的事），它解决的是「我怎么相信你给我的信息是真的」。

JWT 的结构

一个 JWT 由三部分组成，用 . 分隔：

OAuth 2.1 相比 OAuth 2.0 的变化 — IAM 协议升级与迁移指南 | IDaaS Book

Wed, 08 Jul 2026 00:00:00 +0800

为什么需要 OAuth 2.1

OAuth 2.0（RFC 6749）发布于 2012 年。在接下来近十年里，安全研究者发现了若干严重攻击面——Redirect URI 劫持、授权码拦截、CSRF、Mix-Up Attack、Token 泄露重放。社区通过一系列补充 RFC 逐个修补：

RFC 7636 (PKCE)：防止授权码拦截（2015）
RFC 6819 / Security BCP：安全威胁模型与缓解措施
RFC 9207 (iss 参数)：防止 Mix-Up Attack（2022）
RFC 9449 (DPoP)：Token 发件人约束（2024）

OAuth 2.1 不是全新协议，而是把这些分散的最佳实践整合成一份统一规范。它同时移除了已被证明不安全的流程，并强化了默认安全配置。

如果你现在在写一个新的 OAuth 客户端或授权服务器，应该直接以 OAuth 2.1 为目标——2.0 的安全模型已经过期。

变化总览

 graph TD
 A["OAuth 2.0 (RFC 6749, 2012)"] --> B["OAuth 2.1 (draft-ietf-oauth-v2-1)"]
 
 B --> C1["✅ 保留 & 强化"]
 B --> C2["❌ 废弃 & 移除"]
 B --> C3["🆕 新增"]

 C1 --> D1["Authorization Code Flow"]
 C1 --> D2["Client Credentials Flow"]
 C1 --> D3["Device Code Flow<br/>(RFC 8628)"]
 C1 --> D4["Refresh Token"]
 C1 --> D5["Bearer Token<br/>(不推荐，但仍可用)"]

 C2 --> E1["Implicit Grant<br/>(response_type=token)"]
 C2 --> E2["ROPC / Password Grant<br/>(grant_type=password)"]
 C2 --> E3["无 PKCE 的授权码流程"]
 C2 --> E4["redirect_uri 宽松匹配"]

 C3 --> F1["PKCE 对所有客户端强制"]
 C3 --> F2["DPoP (RFC 9449)"]
 C3 --> F3["iss 参数 (RFC 9207)"]
 C3 --> F4["Refresh Token 发件人约束"]
 C3 --> F5["redirect_uri 精确匹配"]

七大核心变化

1. PKCE 对所有客户端强制

OAuth 2.0：PKCE（Proof Key for Code Exchange）只推荐给公共客户端（SPA、移动 App），机密客户端可以不用。

第6章：OpenID Connect — ID Token、UserInfo 端点与认证流程 | IDaaS Book

Fri, 02 Feb 2024 00:00:00 +0800

6.1 OAuth 2.0 缺了什么？

OAuth 2.0 解决的是授权问题——我允许这个应用访问我的资源。但它没有解决认证问题——这个用户是谁？

在企业 IAM（身份与访问管理）体系中，认证是授权的前提。一个完整的 IAM 平台不仅要能发 Token，还要能标准地回答「这个 Token 代表谁」。这就是 OIDC 在 IAM 栈中的位置——它是 OAuth 2.0 之上专门解决身份认证的标准化层。

很多开发者早期犯的错误是用 OAuth 2.0 来做认证：

"用户通过 OAuth 登录了，所以我知道他是谁"

但这不安全，因为：

OAuth 2.0 没有定义用户身份的标准化传递方式
Access Token 不包含用户身份信息（或者每个实现各不相同）
没有标准化的发现机制
没有会话管理

OpenID Connect（OIDC） 就是 OAuth 2.0 之上的一个薄层，专门解决认证问题。

6.2 OIDC 的核心概念

OIDC = OAuth 2.0 + 身份认证 + JWT

OIDC 在 OAuth 2.0 基础上增加了：

ID Token（JWT 格式）：携带用户身份信息的安全令牌
UserInfo 端点：获取用户额外属性的标准接口
发现文档：自动发现服务器配置的标准机制
会话管理：登录、登出、会话状态

ID Token vs Access Token

特性	ID Token	Access Token
用途	认证（这是谁）	授权（能做什么）
受众	客户端应用	资源服务器
格式	JWT	JWT 或不透明字符串
包含用户信息	是	不一定
应该发送给资源服务器？	不	是

6.3 ID Token 深度解析

JWT 结构

JWT（JSON Web Token，RFC 7519）由三部分组成，用 . 分隔：

第7章：IAM SAML 2.0 身份联邦 — 断言、绑定、元数据与 SSO 流程图解 | IDaaS Book

Sat, 03 Feb 2024 00:00:00 +0800

7.1 历史与现状

在企业 IAM（身份与访问管理）体系中，SAML（Security Assertion Markup Language）是由 OASIS 标准组织制定的基于 XML 的身份联邦协议。SAML 2.0 于 2005 年发布，是 Web 浏览器 SSO 的行业先驱，至今仍是 IAM 身份联邦场景中与 OIDC 并列的两大支柱协议之一。

尽管 OIDC 在新应用中的采用率已远超 SAML，但 SAML 2.0 在企业级应用中依然占有重要地位。特别是在以下场景：

金融、政府、教育等传统行业
大型企业的遗留应用
需要与 Microsoft AD FS 集成的场景
教育和研究联邦（如 eduGAIN、InCommon，基于 Shibboleth）

SAML vs OIDC 的历史视角

	SAML 2.0	OIDC
发布时间	2005	2014
数据格式	XML	JSON
签名方式	XML DSig	JWS
加密方式	XML Enc	JWE
绑定协议	重定向、POST、Artifact 等	HTTP（Redirect/POST，含 form_post/jwt response mode）
移动端支持	差	好
SPA 支持	差	好
复杂度	高	低
行业采用	传统企业	现代应用

一句话总结：遗留系统用 SAML，新系统用 OIDC，作为 IDaaS 平台两者都要支持。

SAML 2.0 攻击面与安全防护 — IAM 身份联邦安全深度分析 | IDaaS Book

Sun, 12 Jul 2026 00:00:00 +0800

为什么需要 SAML 安全分析

上一章 OAuth 2.0 攻击面与防护分析了 OAuth 的五类攻击——但 IAM 身份联邦的另一大支柱 SAML 2.0 同样拥有自己的攻击面。在企业实践中，SAML 承载着金融、政务、教育等领域的身份联邦流量，一次 SAML 安全漏洞就可能导致跨系统身份伪造。

SAML 的安全挑战与 OAuth 不同：OAuth 的安全问题多集中在 HTTP 重定向和 Token 传递环节，而 SAML 的根因在于 XML 解析的复杂性——签名验证、XML Schema、实体引用等 XML 特性给了攻击者更多操作空间。

以下四个攻击面是过去二十年里真实发生过的漏洞模式，每一个都配有攻击流程图、根因分析和防护方案。

四大攻击面总览

#	攻击面	根本原因	关键防护	相关规范
1	XML 签名包装（XSW）	SAML 处理器在签名校验后取错 XML 节点	仅信任签名引用的元素，使用 XPath 白名单	SAML 2.0 Security §3.1
2	断言重放（Replay）	SP 未校验断言的时效性/一次性/受众	校验 NotOnOrAfter + InResponseTo + Audience + OneTimeUse	SAML 2.0 Core §2.5
3	XXE 注入	SAML 处理器解析含外部实体的 XML 断言	禁用 DTD 和外部实体（XXE-safe parser config）	OWASP XXE Prevention
4	元数据伪造/MITM	攻击者替换 SP 元数据中的证书	证书 pinning、metadata 签名、TLS 双向校验	SAML 2.0 Metadata

1. XML 签名包装（XSW）

攻击原理

XSW 是 SAML 历史上最著名也最危险的攻击类别（CVE-2012-0053 等）。核心思路是：XML 签名覆盖了原始断言，攻击者在签名覆盖之外插入伪造断言，利用 SAML 处理器「只验签不看节点」的缺陷完成身份伪造。

SCIM 2.0 协议深度解读 — IAM 跨域身份同步标准 | IDaaS Book

Mon, 05 Feb 2024 00:00:00 +0800

9.1 为什么需要 SCIM？——IAM 用户生命周期的标准化

在企业 IAM（身份与访问管理）体系中，OAuth 2.0 和 OIDC 解决了认证和授权问题，SAML 解决了联邦 SSO 问题，但它们都没有回答一个 IAM 核心问题：如何标准化地创建、更新和删除用户？SCIM 正是 IAM 用户生命周期管理的标准答案——它把"入职创建账号 → 调岗修改权限 → 离职回收身份"这一整套 IAM 流程变成了标准化的 REST API。

在 SCIM 出现之前，每个系统都有自己的用户 API：

App1: POST /api/v1/users {"name": "..."} ← 每种格式都不一样
App2: PUT /rest/user/create {"userName": "..."}
App3: SOAP <CreateUser><Name>...</Name></CreateUser>

SCIM（System for Cross-domain Identity Management） 就是为了结束这种混乱而生的标准。它由 IETF 制定，共三份 RFC：RFC 7642（定义、概念与概述）、RFC 7643（Core Schema，含 User/Group 资源与 JSON 编码）、RFC 7644（Protocol，REST API 与 PATCH 语义）。

9.2 SCIM 的核心概念

核心数据模型

SCIM 定义了核心资源类型：

第8章：LDAP 与目录服务 — IAM 身份源集成、Active Directory 对接与目录同步 | IDaaS Book

Sun, 04 Feb 2024 00:00:00 +0800

8.1 IAM 目录服务概述 — LDAP 与 Active Directory 基础

目录服务是一种专门为读操作优化的分布式数据库，用于存储组织化的、层次化的信息。在 IAM 体系中，目录服务是最重要的身份数据源——大多数企业的员工身份仍然以 LDAP/AD 为权威来源，IAM 平台通过 LDAP 协议消费这些身份数据，再向现代应用暴露 OIDC/SAML 等标准协议。

为什么不是关系数据库？

特性	目录服务	关系数据库
读/写比例	100:1 或更高	变化多样
数据模型	层次化（树状）	关系化（表）
查询语言	LDAP Filter	SQL
性能优化	索引和缓存优先	事务和一致性
数据结构	灵活 Schema	固定 Schema
典型用途	身份查找、认证	业务数据处理
扩展方式	只读副本	读写分离

目录服务是为"查找"而生的：员工查找、组查找、认证等操作要求极低的延迟和极高的读并发，这正是目录服务的设计目标。

8.2 LDAP 协议基础

LDAP 数据模型

LDAP 数据以树状结构（Directory Information Tree, DIT）组织：

 dc=example,dc=com
 │
 ┌─────────┼─────────┐
 │ │ │
ou=users ou=groups ou=services
 │ │
cn=张三 cn=engineers

每个节点称为一个 Entry（条目），具有：