第五部分：高级主题 on IDaaS Book

IAM RBAC、ABAC、ReBAC 授权模型对比与选型指南 | IDaaS Book

Wed, 01 May 2024 00:00:00 +0800

20.1 IAM 授权模型的演进

在企业 IAM（身份与访问管理）体系中，授权模型决定了"谁能访问什么"。从早期的自主访问控制（DAC）和强制访问控制（MAC），到如今主流的 RBAC、ABAC、ReBAC，每一次演进都在提升权限管理的精细度和可扩展性。理解这些模型的区别，是设计可维护 IAM 权限体系的前提。关于 IAM 整体概念和身份生命周期管理，请参阅 IAM 基础概念；IAM 架构层面的设计考量见 IAM 架构设计指南。

1960s-70s 1970s-80s 1990s-2000s 2000s-2010s 2019
 │ │ │ │ │
 DAC MAC RBAC ABAC ReBAC
(自主) (强制) (角色) (属性) (关系)
 NIST 2004 XACML 2003 Google Zanzibar

复杂度递增，精细度递增

20.2 IAM RBAC（基于角色的访问控制）

RBAC 在 IAM 体系中的定位

在企业 IAM 实践中，RBAC 是使用最广泛的授权模型。它的核心优势在于"角色"这个概念与组织架构天然对齐——HR 系统里叫"部门经理"，IAM 系统里就映射为 manager 角色，权限跟着角色走，而非跟着人走。这使得 IAM 权限审计（“谁拥有管理员权限？"）和权限回收（员工离职时移除角色即可）变得直观可控。本节聚焦 Keycloak 中的 RBAC 落地，实际生产环境中常与 IAM 会话管理配合，确保角色变更后会话及时失效。

核心模型

用户 ──→ 角色 ──→ 权限

Alice → [经理] → [审批报销, 查看团队报表]
Bob → [员工] → [提交报销, 查看自己的报表]

RBAC 的三个层次

RBAC0（基础 RBAC）：用户 → 角色 → 权限 RBAC1（层次 RBAC）：角色之间有继承关系

第21章：IAM / IDaaS 安全最佳实践 — 密钥管理、令牌保护与攻击面防御 | IDaaS Book

Thu, 02 May 2024 00:00:00 +0800

21.1 安全总则

IDaaS 是安全基础设施的核心，它保护着所有应用的入口。如果 IDaaS 被攻破，攻击者就拿到了"万能钥匙"。

因此，IDaaS 自身的安全必须比它所保护的应用更高一个等级。

21.2 密码安全

密码哈希

绝对必须使用单向哈希，绝不能明文或可逆加密存储密码
推荐算法顺序：Argon2id > bcrypt > scrypt > PBKDF2
Argon2 是 2015 年密码哈希竞赛（PHC）的获胜者，Argon2id 是其推荐的抗侧信道混合变体（RFC 9106 推荐使用 Argon2id），内存硬（Memory-hard），抗 ASIC 攻击

密码策略

最小长度 ≥ 12 字符（长度比复杂度更重要）
检查密码是否在已知泄露密码库中（Have I Been Pwned API）
密码历史检查（不能与最近 5 次相同）
但不要强制每 90 天换密码（NIST SP 800-63B 已取消此建议）
只在怀疑凭证泄露时要求更改

密码传输

登录表单必须通过 HTTPS POST
绝不在 URL 参数中传输密码
使用 Content-Security-Policy 头防止 XSS

21.3 Token 安全

Access Token

短有效期（5-15 分钟）
使用非对称签名（RS256/ES256），资源服务器用公钥验证
包含 audience（aud）限制可用范围
使用 DPoP 或 mTLS 绑定 Token 到客户端

Refresh Token

Rotation：每次使用后发放新 Token，旧 Token 立即失效
Reuse Detection：同一 Refresh Token 被使用两次即视为泄露，立即吊销该令牌链（该用户/该客户端的相关令牌）
存储在 HttpOnly Secure Cookie 中（Web）或 Keychain/Keystore（移动）

ID Token

只在客户端验证，绝不应发送给资源服务器
验证清单：签名、iss、aud、exp、iat、nonce
使用 Pairwise Subject Identifier 防止跨应用用户追踪

21.4 会话安全

Set-Cookie: session_id=xxx;
 Secure; # 仅通过 HTTPS 传输
 HttpOnly; # JavaScript 不可访问（防 XSS 窃取）
 SameSite=Lax; # CSRF 纵深防御之一；最强为 SameSite=Strict（但影响跨站回跳）
 Path=/;
 Max-Age=3600; # 短生命周期
 Domain=auth.example.com # 限定在认证域

注：SameSite 是 CSRF 纵深防御的一环，不应作为唯一防线；主流浏览器已默认 Lax+POST 限制，仍需配合 CSRF Token / Origin / Sec-Fetch-Site 校验。

第22章：IAM 高可用与 IDaaS 性能扩展 — 缓存策略、集群扩展与容量规划 | IDaaS Book

Fri, 03 May 2024 00:00:00 +0800

22.1 IDaaS 的性能模型

IDaaS 系统的负载特征：

读多写少：认证操作远多于管理操作（100:1 或更高）
突发性强：工作日早晨的登录高峰
延迟敏感：用户等待认证的时间忍受度极低（期望 < 500ms）
状态管理：Session 和 Token 需要分布式存储

关键性能指标

指标	目标值	说明
登录延迟（P50）	< 200ms	正常情况
登录延迟（P95）	< 500ms	高峰情况
登录延迟（P99）	< 1s	极端情况
Token 签发延迟	< 50ms	不含用户认证
Token Introspection	< 10ms	资源服务器高频调用
可用性	99.99%	年停机 < 52 分钟

22.2 数据库优化

IDaaS 的性能瓶颈往往在数据库。

查询优化

索引策略：

-- Keycloak 中最频繁的查询路径（示例基于 JPA schema，实际表/列名随版本而变，
-- 且 Keycloak 默认已为多数查询列建好索引，手动建索引前请先确认避免重复）
-- 查找用户的 Session
CREATE INDEX idx_user_session_user ON USER_SESSION(USER_ID);

-- 查找 Realm 的 Session
CREATE INDEX idx_user_session_realm ON USER_SESSION(REALM_ID);

-- Client Session 关联到 User Session（外键为 USER_SESSION_ID）
CREATE INDEX idx_client_session_user_session ON CLIENT_SESSION(USER_SESSION_ID);

-- 离线 Token 查找
CREATE INDEX idx_offline_user_session ON OFFLINE_USER_SESSION(USER_SESSION_ID);

连接池

db-pool-initial-size: 10
db-pool-min-size: 10
db-pool-max-size: 单节点合理的最大连接数
 ≈ 该节点的并发工作线程数（受 DB 总连接上限 / 节点数 约束）
 例：DB 最大连接 600，3 节点，则单节点上限 ≈ 600 / 3 × 0.7 ≈ 140
 （确保 节点数 × 单节点池上限 ≤ 数据库 max_connections 的合理比例，如 60–70%）

读写分离

对于大规模部署（>100K 用户）：

第23章：IAM 监控与可观测性最佳实践 — Metrics、日志、Trace 三位一体 | IDaaS Book

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

23.1 IAM 为什么需要专门的可观测性策略

在企业 IT 架构中，IAM 是一个特殊的存在——它不是业务系统，却是所有业务系统的登录入口。当 IAM 出现性能退化时，症状不会首先出现在 IAM 自身，而是表现为"应用登录慢"“Token 刷新失败"“新员工无法入职"等下游问题。等你从业务告警回溯到 IAM 时，往往已经过了十分钟。

IAM 可观测性要回答的核心问题不是"CPU 满没满”，而是：

当前有几条认证链路在排队？ 每一秒的排队都在影响用户登录体验
Token 签发的 P99 延迟有没有漂移？ 今天 50ms，下周变成 200ms——IAM 自身可能还在正常范围内，但上游应用已经在报超时
哪些 Client 在频繁请求？ 可能是业务扩容的正常行为，也可能是一个忘记加缓存的微服务正在 DoS 你的 Token Endpoint
审计日志里有没有异常模式？ 凌晨 3 点突然冒出一堆 admin 角色的 Token 签发——要不就是运维在加班，要不就是凭证泄露

关于 IAM 整体架构设计（包括高可用和性能扩展）请参阅 IAM 架构设计指南和 IAM 高可用与性能扩展。本章专注于"怎么看到问题正在发生”。

23.2 IAM 可观测性三层模型

IAM 可观测性可以按照数据形态分为三层——这不是凭空造的框架，而是 Google SRE 的"三大支柱"（Metrics / Logs / Traces）在身份领域的工程化映射：

 graph TB
 subgraph "第一层：Metrics（指标）"
 M1["认证请求 QPS"]
 M2["Token 签发延迟 P50/P95/P99"]
 M3["LDAP/DB 后端延迟"]
 M4["Session 活跃数"]
 M5["错误率（4xx/5xx）"]
 end

 subgraph "第二层：Logs（日志）"
 L1["审计日志 Audit Logs"]
 L2["应用日志 App Logs"]
 L3["安全事件日志 Security Events"]
 end

 subgraph "第三层：Traces（链路追踪）"
 T1["Browser → IDP → LDAP"]
 T2["OAuth Token 完整链路"]
 T3["SAML Assertion 签发过程"]
 end

 subgraph "告警层"
 A1["延迟 SLO 告警"]
 A2["错误率突增"]
 A3["审计异常检测"]
 end

 M1 & M2 & M3 --> A1
 M5 --> A2
 L1 & L3 --> A3
 M4 --> A1

 T1 & T2 --> M2
 L2 --> M3

 style A1 fill:#f96,stroke:#333
 style A2 fill:#f96,stroke:#333
 style A3 fill:#f96,stroke:#333

图释：Metrics 层是实时监控的主力——你通过 QPS、延迟、错误率判断"系统是否健康"；Logs 层回答"刚才发生了什么"，尤其是审计日志是合规审计的硬需求；Traces 层解决"认证请求慢在哪一步"——当 P99 延迟从 50ms 漂移到 500ms 时，Trace 告诉你瓶颈是 LDAP 查询还是 Token 签名运算。三层叠加形成告警规则。

IAM 安全合规与等保 2.0 要求 Checklist — 身份认证、访问控制与审计落地指南 | IDaaS Book

Fri, 10 Jul 2026 00:00:00 +0800

为什么 IAM 是等保 2.0 的核心控制域

等保 2.0（GB/T 22239-2019《信息安全技术网络安全等级保护基本要求》）将安全要求分为技术和管理两大类。在技术层面，身份与访问管理（IAM）跨越了"安全计算环境"和"安全区域边界"两个控制域，直接影响以下测评项：

身份鉴别（Identification and Authentication）：你是谁
访问控制（Access Control）：你能做什么
安全审计（Security Audit）：你做了什么

三者构成等保的"事前预防→事中控制→事后追溯"闭环。IAM 系统（无论是自建 Keycloak 还是 SaaS IDaaS）就是实现这个闭环的核心基础设施。

等保 IAM 要求逐条对照表（以三级为例）

以下对照表按 GB/T 22239-2019 三级安全标记保护要求整理，列出每项要求、测评要点和 IAM 技术落地方式。关于 IAM 整体概念见 IAM 基础概念，架构设计考量见 IAM 架构设计指南。

8.1.4.2 身份鉴别（安全计算环境）

等保要求	测评要点	IAM 落地方式	对应协议/技术
a) 身份标识和鉴别	所有用户登录需唯一标识+密码/证书	LDAP/AD 统一用户目录，所有应用通过 OIDC/SAML 回调 IAM 做认证	OIDC Authorization Code Flow + PKCE
b) 标识唯一性	用户名/UID 全局唯一，不存在同名账号	IAM 用户目录强制唯一约束（uid/email），禁止重复注册	LDAP uid 唯一索引
c) 登录失败处理	连续失败锁定账户，会话超时自动退出	Keycloak Brute Force Detection，Token 短有效期（5-15min），Session Idle/Max 超时	Keycloak Realm Settings → Security Defenses
d) 远程管理加密	管理接口必须 HTTPS，禁止明文传输凭证	IAM Admin Console 强制 HTTPS，管理 API 用 mTLS 或 JWT Bearer Token	TLS 1.2+、mTLS
e) 双因素认证	重要操作需两种以上鉴别技术组合	管理员强制 TOTP/WebAuthn，高敏感操作（删除用户/改权限）要求 Step-up MFA	TOTP（RFC 6238）、WebAuthn/FIDO2
f) 口令复杂度	最小长度 ≥ 8，包含大小写+数字+特殊字符中 3 种	Keycloak Password Policy：最小长度 8，至少 1 数字+1 特殊字符+1 大写	Keycloak Password Policies

8.1.4.3 访问控制（安全计算环境）

等保要求	测评要点	IAM 落地方式	对应协议/技术
a) 账户与权限分配	为每个用户/进程分配独立账户和权限	RBAC 角色绑定，用户只分配必要角色；服务账户用 Client Credentials Grant	RBAC + Client Credentials
b) 默认账户处理	删除或重命名默认账户，修改默认口令	部署后立即禁用 admin 默认账户，创建命名管理员；Keycloak 初始 admin 改密码	Keycloak Admin CLI
c) 冗余账户清理	离职/转岗及时禁用或删除	SCIM 自动同步 HR 系统，用户状态变更自动生效；定期审计僵尸账户	SCIM 2.0 (RFC 7644)
d) 最小权限原则	管理员授予完成工作所需的最小权限	RBAC 细粒度角色拆分（只读管理员、用户管理员、Client 管理员），禁止共享超级管理员	Keycloak Fine-Grained Admin Permissions
e) 访问控制策略	由授权主体（安全管理员）配置策略，而非开发者	集中式 IAM 策略管理，应用只做 PEP（策略执行点），不自行决策	XACML/OPA 策略引擎
f) 控制粒度	主体粒度达用户级，客体粒度达文件/数据库表级	ABAC 可做到属性级授权；Keycloak Authorization Services 支持资源级权限	UMA 2.0、Keycloak AuthZ Services
g) 安全标记	敏感数据打标签，基于标签控制访问	用户属性打安全等级标签，ABAC 策略读取标签决策	ABAC 属性策略

8.1.4.5 安全审计（安全计算环境）

等保要求	测评要点	IAM 落地方式	对应协议/技术
a) 审计功能开启	审计覆盖所有用户、所有安全事件	Keycloak Event Listener 开启，记录 LOGIN/LOGOUT/TOKEN_EXCHANGE/ADMIN 事件	Keycloak Events、Syslog
b) 审计记录完整性	记录时间、用户、事件类型、结果、来源 IP	Event 包含：时间戳（timestamp）、用户 ID、事件类型（type）、结果（success/error）、IP	Keycloak Event 结构
c) 审计记录保护	防篡改、防删除，定期备份	审计事件推送到不可篡改存储（ELK + 只读索引、Syslog 远程服务器），定期归档	Logstash → Elasticsearch
	d) 审计记录留存	留存 ≥ 6 个月	日志归档策略：热数据 30 天（ES）、温数据 90 天（S3/对象存储）、冷数据 6 个月（归档存储）

实践指南：Keycloak 事件日志的具体配置步骤（CLI 参数、环境变量、Syslog/ELK 导出、数据库膨胀处理）见 Keycloak 审计日志配置与 IAM 合规实践。

第23章：去中心化身份与可验证凭证 — DID、VC 与自主权身份技术详解 | IDaaS Book

Sat, 04 May 2024 00:00:00 +0800

23.1 当前身份模型的根本缺陷

当前的"中心化 + 联邦"身份模型有三个根本问题：

身份数据被平台控制：用户的数据存在各个 IdP 上，用户没有真正的所有权。
身份孤岛：每个平台的用户身份独立存在，无法跨平台携带。
隐私不足：用户登录行为被 IdP 完全可见（IdP 知道你访问了哪些应用）。

去中心化身份（Decentralized Identity）试图从根本上改变这种模式。

23.2 去中心化身份的核心理念

传统模型： 去中心化模型：
 
 [IdP] 持有你的数据 你持有你的数据
 │ │
 ├── [App1] ├── [App1]
 ├── [App2] vs. ├── [App2]
 └── [App3] └── [App3]
 
IdP 是必需的中间人 没有必需的中间人

核心理念：

用户拥有并控制自己的身份数据
无需依赖中心化的身份提供方
选择性披露：用户决定分享哪些信息
零知识证明：可以在不泄露信息的情况下证明某件事

23.3 DID（Decentralized Identifier，去中心化标识符）

DID 是 W3C 推荐标准（DID Core 1.0，2021 年成为 W3C Recommendation），是一种新型的全球唯一标识符，不由任何中心机构签发。

DID 的格式

did:example:123456789abcdefghi
│ │ │
│ │ └── 方法特定标识符
│ └────────── DID 方法（指定了如何解析 DID）
└────────────── Scheme（固定为 did）

DID 方法

不同的 DID 方法对应不同的底层技术：

第24章：零信任 IAM 架构 — 身份驱动的持续安全验证体系 | IDaaS Book

Sun, 05 May 2024 00:00:00 +0800

24.1 从城堡到零信任

传统安全模型：城堡与护城河

 防火墙
 ┌───────────────────────┐
 │ 内网（安全） │
 │ [应用] [数据库] [文件] │
 ┌───┐ │ │
 │员工│──→│ VPN 接入 │
 └───┘ └───────────────────────┘
 ×
 外网 = 不安全

问题：
- 一旦进入内网，几乎可以为所欲为
- VPN 凭据泄露 = 整个网络沦陷
- 边界越来越模糊（SaaS、远程办公、多云）

零信任核心原则

“永远不信任，始终验证”（Never Trust, Always Verify）

（这一口号源自 John Kindervag / Forrester 2010 的零信任早期表述；NIST SP 800-207 将其具化为：不基于网络位置给予隐式信任、显式验证、最小权限、假设已沦陷等原则。）

零信任不是一种产品，而是一种安全架构理念。在 IAM（身份与访问管理）体系中，零信任将"身份"提升为安全决策的核心依据——这与传统 IAM 以"认证通过后放行"的模式有根本区别。IAM 架构的整体设计思路可参考 IAM 架构设计指南。

传统安全	零信任安全
信任但验证	从不信任，始终验证
基于位置（内网=安全）	基于身份和上下文
一次性认证	持续评估
网络分段	微隔离
边界防御	假设边界已被攻破

24.2 身份：零信任 IAM 的基石

在零信任架构中，身份取代 IP 地址成为新的安全边界。IAM 系统不再是"登录后就完成任务"的旁路组件，而是持续参与每一次访问决策的核心引擎：

IAM 架构设计指南 — 从单体到零信任的演进 | IDaaS Book

Thu, 09 Jul 2026 00:00:00 +0800

IAM 架构的核心问题

设计一个 IAM 系统架构，本质上是在回答三个问题：

身份数据放在哪？——集中存储还是分布在各处？
谁来做认证决策？——单一权威源还是多点自治？
如何应对规模和故障？——垂直扩展、水平扩展还是多活？

这三个问题的答案，决定了 IAM 架构的形态。下面从经典到现代，逐一解析。

三种经典 IAM 架构模式

中心化 IAM 架构

所有身份数据和认证逻辑集中在一个中心节点，所有应用统一对接这个中心。

 graph TB
 subgraph "应用层"
 A1[Web 应用]
 A2[移动 App]
 A3[API 网关]
 A4[内部系统]
 end

 subgraph "中心 IAM 层"
 IAM[IAM Server<br/>认证 + 授权 + 审计]
 LDAP[(LDAP / DB<br/>身份存储)]
 end

 A1 --> IAM
 A2 --> IAM
 A3 --> IAM
 A4 --> IAM
 IAM --> LDAP

 style IAM fill:#f9f,stroke:#333,stroke-width:2px
 style LDAP fill:#bbf,stroke:#333

优点：

策略统一，一处管控所有访问
审计完整，所有认证事件集中在一条日志流
接入简单，应用只需对接一个端点

缺点：

IAM 认证协议选型指南 — OAuth 2.0 vs OIDC vs SAML vs LDAP vs SCIM 决策框架 | IDaaS Book

Fri, 10 Jul 2026 00:00:00 +0800

协议选型为什么重要

IAM 系统的核心任务是"把正确的身份信息，在正确的时机，以正确的方式，交给正确的应用"。而协议就是这条信息传递通道的语法和合同。

选错协议的代价不是"功能少了几个"，而是：

问题类型	典型后果	实际案例
协议不匹配	用 OAuth 做认证，结果拿到 Access Token 却不知道用户是谁	早期很多开发者把 OAuth 2.0 当成"社交登录协议"用
过度设计	在内部管理面板里用 SAML，每个 SP 都要交换 XML 元数据	几十个内部工具维护 SAML metadata 的运维噩梦
协议混用	OIDC + SAML 双栈但未统一会话管理，导致登出不同步	用户在一个应用登出，另一个应用会话依然有效
安全盲区	PKCE 缺失、redirect_uri 未校验、state 参数未使用	OAuth 授权码拦截、CSRF、Mix-Up Attack

本章不重复 OAuth 2.0、OIDC、SAML 的协议细节——那些在协议与标准部分有完整阐述。这里专注于决策：你面对一个具体场景时，该选哪个协议、为什么、不选其他协议的原因是什么。

五大协议的核心定位

在进入决策树之前，先理解每个协议在 IAM 体系中的核心角色——它们解决的是不同层面的问题：

 graph TD
 subgraph "IAM 协议体系"
 AUTH_Z[授权<br/>OAuth 2.0] --> |构建于| AUTH_N[认证<br/>OpenID Connect]
 AUTH_N --> |替代/互补| SAML[SAML 2.0<br/>企业 SSO]
 DIR[LDAP<br/>目录查询] --> |用户源| AUTH_N
 DIR --> |用户源| SAML
 PROV[SCIM<br/>生命周期管理] --> |同步到| AUTH_N
 PROV --> |同步到| SAML
 end

 style AUTH_Z fill:#e1f5fe
 style AUTH_N fill:#c8e6c9
 style SAML fill:#fff9c4
 style DIR fill:#f3e5f5
 style PROV fill:#ffe0b2

协议	核心问题	在 IAM 中的位置	数据格式	典型端口
OAuth 2.0	“我能做什么？（授权）”	授权层——控制第三方应用对受保护资源的访问范围	JSON	通常 HTTPS
OpenID Connect (OIDC)	“你是谁？（认证）”	认证层——OAuth 2.0 + 身份层，标准化用户身份传递	JSON (JWT)	HTTPS
SAML 2.0	“企业里的你是谁？（联邦认证）”	身份联邦——跨组织/跨域传递用户身份断言	XML	HTTPS / Redirect
LDAP	“用户信息在哪？（目录查询）”	用户存储——身份数据的查询、验证和修改协议	ASN.1 / LDIF	389 / 636
SCIM	“用户怎么创建/更新/删除？（生命周期）”	用户供应——自动化用户帐号的 CRUD 生命周期管理	JSON (REST)	HTTPS

一句话判断：需要授权第三方访问资源 → OAuth 2.0；需要证明"我是谁" → OIDC 或 SAML；需要连企业 AD → LDAP；需要自动创建/删除用户 → SCIM；需要跨公司 SSO → SAML 或 OIDC Federation。

IAM 会话管理与 Token 生命周期 — SSO 会话、Token 刷新与吊销机制 | IDaaS Book

Fri, 10 Jul 2026 00:00:00 +0800

IAM 会话管理为什么重要

IAM 系统中，“会话” 是连接认证与授权的桥梁。一次登录不只是验证密码——它创建了一个受控的信任窗口，在这个窗口内用户无需重复认证即可访问多个应用。这个窗口的管理——创建、刷新、吊销——决定了系统的安全性和用户体验。

理解 IAM 会话管理需要先澄清三层会话：

会话层	含义	生命周期
IDP 会话	用户在 IDP（如 Keycloak）的登录状态	用户登出或超时
应用会话	用户在某应用内的登录状态	应用自身管理
Token 会话	Access Token / Refresh Token 的有效期	Token 过期或吊销

三层会话之间通过 SSO 协议（OIDC、SAML）联动，但各层独立管理。这种解耦设计是理解 Token 刷新、会话吊销和登出传播的关键。

Token 生命周期全景

OAuth 2.0 / OIDC 的会话本质上是 Token 的生命周期管理。三个核心 Token 各司其职：

 sequenceDiagram
 participant U as 用户/客户端
 participant IDP as IDP (Keycloak)
 participant App as 应用
 participant RS as 资源服务器

 Note over U,RS: 第一阶段：认证与授权
 U->>IDP: 1. 登录请求（OIDC Authorization Code + PKCE）
 IDP->>U: 2. 返回授权码（Authorization Code）
 U->>IDP: 3. 授权码换取 Token（Token Endpoint）
 IDP->>U: 4. Access Token (5min) + Refresh Token + ID Token

 Note over U,RS: 第二阶段：使用 Access Token
 U->>RS: 5. API 请求 (Authorization: Bearer <AT>)
 RS->>RS: 6. 验证签名 + aud + exp
 RS->>U: 7. 返回资源

 Note over U,RS: 第三阶段：Token 过期 → 刷新
 U->>IDP: 8. Refresh Token 请求新 Access Token
 IDP->>IDP: 9. 验证 Refresh Token + 轮换
 IDP->>U: 10. 新 Access Token + 新 Refresh Token

 Note over U,RS: 第四阶段：用户登出
 U->>IDP: 11. 登出请求（/logout, 含 id_token_hint）
 IDP->>IDP: 12. 吊销所有 Token + 销毁 IDP Session
 IDP->>App: 13. 可选：Backchannel Logout 通知

Access Token（访问令牌）

Access Token 是访问资源的"通行证"——资源服务器用它来判断"这个请求有没有权限"。

第五部分：高级主题 on IDaaS Book

IAM RBAC、ABAC、ReBAC 授权模型对比与选型指南 | IDaaS Book

20.1 IAM 授权模型的演进

20.2 IAM RBAC（基于角色的访问控制）

RBAC 在 IAM 体系中的定位

核心模型

RBAC 的三个层次

第21章：IAM / IDaaS 安全最佳实践 — 密钥管理、令牌保护与攻击面防御 | IDaaS Book

21.1 安全总则

21.2 密码安全

密码哈希

密码策略

密码传输

21.3 Token 安全

Access Token

Refresh Token

ID Token

21.4 会话安全

Cookie 属性

第22章：IAM 高可用与 IDaaS 性能扩展 — 缓存策略、集群扩展与容量规划 | IDaaS Book

22.1 IDaaS 的性能模型

关键性能指标

22.2 数据库优化

查询优化

连接池

读写分离

第23章：IAM 监控与可观测性最佳实践 — Metrics、日志、Trace 三位一体 | IDaaS Book

23.1 IAM 为什么需要专门的可观测性策略

23.2 IAM 可观测性三层模型

IAM 安全合规与等保 2.0 要求 Checklist — 身份认证、访问控制与审计落地指南 | IDaaS Book

为什么 IAM 是等保 2.0 的核心控制域

等保 IAM 要求逐条对照表（以三级为例）

8.1.4.2 身份鉴别（安全计算环境）

8.1.4.3 访问控制（安全计算环境）

8.1.4.5 安全审计（安全计算环境）

第23章：去中心化身份与可验证凭证 — DID、VC 与自主权身份技术详解 | IDaaS Book

23.1 当前身份模型的根本缺陷

23.2 去中心化身份的核心理念

23.3 DID（Decentralized Identifier，去中心化标识符）

DID 的格式

DID 方法

第24章：零信任 IAM 架构 — 身份驱动的持续安全验证体系 | IDaaS Book

24.1 从城堡到零信任

传统安全模型：城堡与护城河

零信任核心原则

24.2 身份：零信任 IAM 的基石

IAM 架构设计指南 — 从单体到零信任的演进 | IDaaS Book

IAM 架构的核心问题

三种经典 IAM 架构模式

中心化 IAM 架构

IAM 认证协议选型指南 — OAuth 2.0 vs OIDC vs SAML vs LDAP vs SCIM 决策框架 | IDaaS Book

协议选型为什么重要

五大协议的核心定位

IAM 会话管理与 Token 生命周期 — SSO 会话、Token 刷新与吊销机制 | IDaaS Book

IAM 会话管理为什么重要

Token 生命周期全景

Access Token（访问令牌）