整合原理：OIDC 与 OAuth Scope 如何打通
Agent Identity 不替代你的 Human Identity 体系，它接在上面。GenAuth 通过统一的 Provider 抽象与你既有的 Human IAM 打通三件事：用户是谁（身份联邦）、用户能做什么（权限读取）、委托怎么表达（scope 映射）。
为什么必须打通：权限之源在 Human IAM
权限的源头永远是人。Agent 行使的每一分权力，都是人从 Human Identity 体系里显式让渡的——可缩窄、可审计、可随时收回（见GenAuth 是什么）。这句世界观落到工程上，就是缩权（attenuation）的三方交集：
Agent 实际权限 = 人的真实权限 ∩ 显式委托范围 ∩ 企业批准边界
三个集合里，"显式委托范围"来自授权确认（Consent），"企业批准边界"来自 Agent 注册审批——这两个 GenAuth 自己管。但**"人的真实权限"只有一个权威来源：你既有的 Human IAM**。用户、组织、角色、权限策略都住在那里，而且每天都在变。
不打通，会出现三个断层：
- 身份断层——GenAuth 被迫另建一套账号，"张三"在两边成了两个人，委托记录对不上企业目录；
- 缩权失去下界——不知道张三本人能做什么，就无法兑现"不能委托你没有的权限"；
- 两套权限语言各说各话——Human IAM 说"报表系统只读角色"，委托说 scope，中间没有翻译层。
先说清一件事：打通不是迁移。你的用户、组织、权限模型全部留在原地，GenAuth 只做联邦、读取与映射——不接管、不写回。完整的接入路径见旗舰指南接入你已有的认证体系。
层次一 · 身份联邦（Identity Federation）——用户是谁
委托由一次授权确认开始，而授权确认的前提是：站在确认页前的这个人，就是企业目录里的那个人。 身份联邦用标准 OIDC 解决这件事——授权确认时跳转到你的 Human IAM 完成登录，身份断言回到 GenAuth，委托记录从第一行起就锚定在企业目录的真实用户上。
在私有化同域旁挂形态下，这对应完整旅程的第 ⑧ 跳（SaaS 形态无此跳，用户目录由租户托管，见部署形态）：
联邦层带来的直接收益：单点登录体验不变、密码永远不经过 GenAuth、离职停用在 Human IAM 一处生效——委托侧自然跟着失效。
层次二 · 权限读取——用户能做什么
上图第 ③ 跳回答的是三方交集里的第一个集合：人的真实权限。GenAuth 向 Human IAM 发起只读的权限评估——张三是否真的持有他想委托出去的权限——拿到权限断言后，才允许委托进入签发。
这一层的纪律只有三条，但每条都是硬的：
- 只读——GenAuth 只评估、不修改，你的权限模型不会被反向写入；
- 实时——断言在签发时评估，人事调动、角色回收在下一次委托签发时立即生效；
- 取交集，不放大——权限断言只用来收窄委托，永远不会给 Agent 添加人本来没有的权限。
权限读取的完整机制（含"每跳只收窄"的原理）见委托令牌与缩权。
层次三 · scope 映射——委托语言怎么对齐
Human IAM 里的权限词汇（角色、组、权限点）与委托 scope（服务.能力:动作 形态的授权切片）是两套语言。scope 映射是中间的翻译层，做三件事：
- 词汇对齐——把目录侧断言（如"张三 ∈ 报表-只读组"，示意）映射为可委托 scope 的白名单；
- 粒度对齐——角色是粗粒度的，scope 是细粒度的：一个角色解锁的是一组 scope 的可委托上限，用户在授权确认页仍可以只勾选其中一部分；
- 变更传导——目录侧的授权变化经映射层传导到委托侧：角色被回收，对应 scope 从下一次签发起自动出局。
映射的方向是单向的：目录断言作为输入进入三方交集，委托 scope 永远不会反向改写你的权限模型。
Provider 抽象：一个接口，对接多家 Human IAM
三个整合层次收敛为 Provider 接口上的三个能力面：联邦登录、目录读取、权限评估。每家 Human IAM 的协议细节（端点形态、claim 命名、目录 API）被封装在各自的 provider 实现内部，GenAuth 的委托引擎只面对统一接口——对接下一家 IdP，是加一个 provider，而不是改一次内核。
当前的 provider 名录只有两栏——要么已实现，要么在路线图，没有第三种状态：
| Implemented | Roadmap |
|---|---|
| Authing | Azure AD（Entra ID） |
| Okta | |
| 标准 OIDC |
每个 provider 的对接形态、配置项与当前进度，都在各自页面如实标注。
标准挂靠与兼容路线
| 标准 | 在整合中的位置 |
|---|---|
| OpenID Connect Core 1.0 | 身份联邦层的协议底座：企业账号登录 + 身份断言 |
| OAuth 2.0（RFC 6749） | scope 作为委托范围的表达语言 |
| Token Exchange（RFC 8693） | 委托令牌（Delegate Token）的兑换与 delegation 语义挂靠，详见 B3 |
| IETF AAT 草案 | "每跳只收窄"（attenuation）的标准化方向 |
兼容路线声明：ID-JAG（Identity Assertion Authorization Grant，OAuth 工作组在研标准）及其商业化形态 XAA 正在把"企业 IdP 作为跨应用授权的裁决点"写进标准，GenAuth 的 Provider 抽象将其列为身份联邦层的既定兼容方向——协议定稿即接入，不做私有分叉。
下一步
- 上手：接入 Authing —— Implemented provider 的配置页
- 指南：接入你已有的认证体系 —— "不动你现有 IdP"的完整路径
- 架构：部署形态 —— SaaS 与私有化同域旁挂的边界差异