3. 企业身份平台能力模型

企业身份平台并不是一个“登录页面”，而是由多个能力域拼装而成的身份基础设施。理解它与 OIDC 的对接面，关键不是记住 OIDC 的端点名称，而是先看清平台内部各能力域分别承担什么职责、它们与 OIDC 协议交互的边界在哪里。只有把能力模型拆开，才能判断一次集成中哪些部分由协议解决、哪些部分必须由平台自身实现。

六个能力域及其职责边界

一个典型的企业身份平台通常包含六个相互协作的能力域：

• 统一认证（Authentication）：验证“你是谁”。它管理凭据类型（密码、证书、FIDO2、OTP）、认证策略（MFA 触发条件、风险评分）、认证会话的生命周期。OIDC 的 /authorize 端点最终会落到这一层完成实际的身份核验。
• 单点登录（SSO）：解决“一次登录、多应用通行”。它依赖统一认证产生的会话，并通过 OIDC 的 ID Token 与授权码流程把身份断言传递给下游应用。SSO 的核心是会话共享与信任传递，而不是重新认证。
• 用户目录（Directory）：存储身份主体及其属性。可以是 LDAP、关系数据库或云目录。OIDC 的 sub、preferred_username、email、groups 等声明都来源于此。
• 权限管理（Authorization）：决定“你能做什么”。包括角色、权限点、策略、资源范围。OIDC 本身不定义授权模型，但可以通过 scope、claims 或 Token 中的自定义声明把权限信息传递给应用。
• 审计合规（Audit & Compliance）：记录“谁在何时做了什么”。它消费认证、授权、令牌签发等事件，形成可追溯的日志与报表，满足等保、SOX、GDPR 等要求。
• OIDC 协议层：作为对外接口，把上述能力以标准协议暴露给应用。它不替代任何能力域，而是能力域的“出口”。

这六个域的关系可以用下面的能力模型图表示。图中同时标出了 OIDC 协议层与各能力域之间的对接面，便于判断集成时问题出在哪一层。

OIDC 与各能力域的对接面

把能力模型拆开后，OIDC 的对接面就变得清晰。OIDC 协议层对外暴露标准端点，对内调用各能力域。具体来说：

统一认证对接面：当 RP 把用户重定向到 /authorize 时，平台需要在这一步完成凭据校验、MFA 挑战和风险判断。如果认证失败，OIDC 返回 error=login_required 或 error=access_denied；如果认证成功，平台生成授权码并进入令牌交换。这一层的集成重点是认证策略的配置，而不是协议本身。

单点登录对接面：SSO 依赖统一认证产生的会话。OIDC 的 ID Token 是 SSO 的载体，其中 iss、sub、aud、exp、iat 是必须校验的声明。平台需要保证同一用户在多个 RP 之间共享会话，同时通过 prompt=none 支持静默续期。如果 SSO 失效，通常表现为用户被反复要求登录，此时应检查会话 Cookie 的域范围与 SameSite 属性。

用户目录对接面：OIDC 的 sub 是用户目录中身份主体的稳定标识，preferred_username、email、groups 等声明来自目录属性。集成时需要确认目录中的属性是否被正确映射到 ID Token 的 claims。例如，LDAP 中的 uid 映射为 sub，mail 映射为 email，memberOf 映射为 groups。如果映射缺失，RP 可能拿不到预期声明。

权限管理对接面：OIDC 不定义授权模型，但可以通过 scope 请求权限范围，通过自定义 claims 传递角色或权限点。例如，在 ID Token 中加入 roles: ["admin","auditor"]，或在 Access Token 中加入 permissions: ["order:read","order:write"]。平台需要决定哪些权限信息放在 ID Token（面向用户身份）、哪些放在 Access Token（面向资源访问）。

审计合规对接面：OIDC 的令牌签发、刷新、撤销事件都应被审计记录。典型字段包括：事件时间、sub、client_id、grant_type、scope、结果状态、来源 IP。审计系统消费这些事件后，可以生成登录报表、异常检测和合规报告。如果审计缺失，等保测评中的“身份鉴别”和“访问控制”条款将难以满足。

集成时的判断依据

在实际集成中，遇到问题时可以按能力域逐层排查。下面给出一个简化的判断路径，帮助定位问题出在哪个对接面：