Okta与Entra ID的SCIM请求体实战对比：谁在偏离RFC 7644？

企业身份管理中最容易被低估的环节之一，是SCIM（System for Cross-domain Identity Management）端点的实际兼容性。理论上，RFC 7644定义了标准协议，Okta和Microsoft Entra ID（原Azure AD）都应该遵循。但当你真正抓取两个目录发往SCIM端点的HTTP请求体时，会发现它们在多个关键字段上的行为差异足以让一个"标准实现"崩溃——尤其是当员工离职（leaver）流程依赖这些字段时。

为什么"标准SCIM"在真实环境中不够用

RFC 7644的规范文本提供了灵活性，而Okta和Entra ID各自选择了不同的实现路径。对于构建或维护SCIM端点的开发者来说，这意味着不能只按RFC写代码，还必须针对两个主流目录的实际行为做适配。

最直接的后果是：如果你的端点只处理了RFC定义的理想情况，当Entra ID或Okta发送PUT而非PATCH、或者省略某些属性时，离职用户的账号可能不会被正确停用。一个活跃的leaver账号，在合规审计中就是一条红线。

SCIM（System for Cross-domain Identity Management）是一套用于跨域身份管理的开放标准，由IETF发布，核心规范包括RFC 7643（定义核心Schema和资源模型，如User、Group及其属性）和RFC 7644（定义协议操作，包括GET、POST、PUT、PATCH、DELETE以及过滤、分页等）。它的目标是让身份提供方（IdP，如Okta、Entra ID）与各种应用（Service Provider）之间用统一的REST风格接口同步用户和组。然而SCIM在关键细节上留有余地：例如PUT与PATCH都可用于更新，但规范未强制某一个为默认；属性是否必填、多值属性如何序列化、DELETE的语义等也有较大解释空间。这种"规范内灵活性"正是不同厂商实现产生分歧的根源，也是SCIM在实际集成中被认为"看似标准、实则碎片化"的原因。

Okta的实际请求行为

Okta在配置SCIM应用时，默认倾向于使用PATCH操作来更新用户属性。它的请求体通常包含一个schemas数组，指向urn:ietf:params:scim:api:messages:2.0:PatchOp，然后是Operations列表。

关键差异在于Okta对active属性的处理。当用户在Okta中被停用时，Okta可能发送{"op":"replace","path":"active","value":false}，但并非所有Okta配置都默认推送这个操作。如果SCIM应用配置中未勾选"停用用户"的推送选项，端点就收不到任何通知。

另一个实际问题是Okta对多值属性的序列化方式。它在发送emails、phoneNumbers等数组时，可能包含primary标记和type字段，而部分SCIM实现只解析了value，导致数据丢失。

Entra ID的实际请求行为

Entra ID的SCIM供给（provisioning）服务在行为上与Okta有显著不同。它更倾向于使用PUT操作来替换整个资源，而不是PATCH。这意味着Entra ID发送的请求体包含完整的用户表示，如果你的端点在PUT处理中只更新了部分字段，就可能意外覆盖已有数据。

Entra ID在用户离职时的处理也值得注意。当用户在Entra ID中被禁用或从供给范围中移除时，Entra ID可能发送active: false的PATCH，也可能直接停止发送请求——具体取决于配置是"软删除"还是"硬删除"。如果配置为硬删除，Entra ID可能发送DELETE请求，而你的端点如果未实现DELETE，就会返回405，导致Entra ID重试并最终进入隔离状态。

SCIM供给（provisioning）是IdP持续将用户和组的创建、更新、删除推送到下游应用的过程，与仅在登录时传递身份断言（如SAML/OIDC）不同，它维护的是目录与应用之间的状态同步。Entra ID的供给服务通过定时轮询目录变更（增量同步）来驱动，因此其请求节奏和批量行为与用户的实时操作并不完全一致。当同步请求失败时，Entra ID会把该对象标记为"隔离（quarantine）"，按指数退避重试，期间可能暂停整个供给作业。理解这一机制有助于解释为何端点返回405或400会导致长时间的账号残留——问题往往不是单次失败，而是进入重试隔离后整体供给了停滞。

两者与RFC 7644及互操作性配置的偏离

根据对两个目录实际请求的观察，偏离主要体现在三个方面：

• 操作语义：Okta偏好PATCH，Entra ID偏好PUT，而RFC对两者都支持但未规定默认。
• 属性过滤：Entra ID可能发送RFC中未强制要求的属性（如urn:ietf:params:scim:schemas:extension:enterprise:2.0:User中的manager），而Okta可能省略某些标准属性。
• 错误处理：两个目录对SCIM端点返回的错误码反应不同，影响重试和供给状态。

新的SCIM互操作性配置（interoperability profiles）试图缩小这些差异，但截至当前，两个目录的默认行为仍未完全对齐这些配置。

SCIM互操作性配置（SCIM interoperability profiles，由IETF SCIM WG推动）是一组在RFC基础上进一步收紧约束的规范，旨在明确PUT/PATCH的预期用法、必填属性、过滤语法、错误响应格式等，以减少IdP与应用之间的歧义。它并非替代RFC 7644，而是提供更严格的"子集与子行为"约定，使实现方能在明确的预期下编写端点。不过，互操作性配置属于较新的工作，Okta和Entra ID的默认行为尚未完全对齐这些约定，因此开发者仍需以实际抓包行为为准，而不能仅依赖规范文本或宣称的兼容性。

如何避免Leaver账号残留

处理两个目录的差异时，核心目标是确保无论Okta还是Entra ID发送什么，离职用户的active状态都能被正确设置为false。

一个实用的做法是在SCIM端点中同时支持PATCH和PUT，并在PATCH处理中显式检查active属性的任何操作。对于Entra ID的DELETE请求，实现软删除逻辑（标记为非活跃）而非物理删除，可以避免重试风暴。

此外，建议在端点中记录每个请求的原始body和来源目录，这样当leaver账号未被停用时，可以快速定位是Okta未发送操作，还是Entra ID配置为不发送停用信号。

两个目录都在向标准靠拢，但在实际部署中，针对Okta和Entra ID的差异化处理仍然是SCIM端点稳定运行的必要条件。

Leaver流程是身份治理中的关键控制点：员工离职后，其在各下游系统中的账号必须及时停用或回收，否则会形成"孤儿账号"，成为合规审计（如SOX、ISO 27001、SOC 2）中的高风险项。在SCIM场景下，leaver账号残留通常有两种成因：一是IdP侧配置未启用"停用推送"，目录根本不发送active:false；二是端点侧未正确处理IdP发来的PUT、PATCH或DELETE。因此治理策略需要两端同时覆盖——既要在Okta、Entra ID的供给配置中确认停用/删除行为已开启，也要在SCIM端点中实现对多种操作语义的兼容处理，并保留请求日志以便归因。