🚧 Roadmap — 本页描述的能力尚在路线图中，概念与设计已定型，接口与操作步骤以正式发布为准。
Azure AD / Okta / 标准 OIDC
Provider 抽象（见 F1 整合原理）的意义就在这一页：对接第二家、第三家 Human IAM，不需要 GenAuth 改内核，只需要一个新的 provider 实现。本页描述三个路线图上的 provider 将以什么方式对接——只讲概念形态，不含配置步骤，因为它们还不存在；等它们存在时，会长在这一页上。
三个 provider 共用同一套对接语言，即 Provider 接口的三个能力面：
| 能力面 | 对接时回答的问题 |
|---|---|
| 联邦登录 | 授权确认（Consent）时，用户用哪个企业账号登录 |
| 目录读取 | 被委托人是否真实存在、身份如何映射 |
| 权限评估 | 人的真实权限——三方交集的缩权（attenuation）下界 |
Azure AD（Entra ID）将以什么方式对接
- 联邦登录：标准 OIDC 授权码流程对接 Microsoft 身份平台，授权确认页跳转企业账号登录，身份断言回到 GenAuth。
- 身份映射：以租户内稳定的目录对象标识作为用户映射键——概念上对应其身份断言中的对象 ID 类 claim，保证改名、换邮箱不影响委托记录的归属。
- 权限评估与 scope 映射：以目录组与应用角色的只读断言作为输入——"张三 ∈ 某个组 / 持有某个应用角色"经映射层翻译为可委托 scope 的白名单上限，只收窄、不放大。
Okta 将以什么方式对接
- 联邦登录：标准 OIDC 授权码流程对接 Okta，形态与上文一致。
- 身份映射：以 Okta 目录中的稳定用户标识作为映射键，委托记录锚定目录条目而非登录名。
- 权限评估与 scope 映射：以群组断言（groups 类 claim）及授权服务器下发的自定义 claim 作为权限评估输入，经映射层进入三方交集。
标准 OIDC 将以什么方式对接
标准 OIDC provider 是兜底通道：任何实现 OIDC Discovery 与授权码流程的合规 IdP，都可以作为身份联邦来源接入。
- 联邦登录：通过 OIDC Discovery 发现端点，走标准授权码流程；
sub作为默认用户映射键，支持以自定义 claim 覆盖。 - 权限评估的诚实边界：OIDC 标准只保证身份层。你的 IdP 若提供可读的权限断言（组/角色类 claim 或只读权限接口），映射层照常工作；若不提供，三方交集中"人的真实权限"一项将不可评估，缩权退化为显式委托范围 ∩ 企业批准边界两方交集——文档会在对应配置处如实标注，不假装评估过。
用你的需求给 roadmap 排序
三个 provider 的实现顺序由真实需求驱动。如果你的组织正在使用其中某家 IdP、希望优先支持，欢迎告诉我们三件事：你在用哪家、权限模型长什么样（组/角色/权限点）、希望委托哪些能力——这会直接影响排期。在此之前，可以先读接入你已有的认证体系了解不依赖特定 provider 的接入路径。
下一步
- 原理：整合原理：OIDC 与 OAuth Scope 如何打通 —— Provider 抽象与三个整合层次
- 参照：接入 Authing —— Implemented provider 的对接形态长什么样
- 指南：接入你已有的认证体系 —— 现在就能走的接入路径