Okta vs Entra ID SCIM Request Bodies in Practice: Who Deviates from RFC 7644?

One of the most underrated aspects of enterprise identity management is the practical compatibility of SCIM (System for Cross-domain Identity Management) endpoints. In theory, RFC 7644 defines the standard protocol, and both Okta and Microsoft Entra ID (formerly Azure AD) should follow it. But when you actually capture the HTTP request bodies that the two directories send to a SCIM endpoint, you'll find that their behavior diverges on several key fields in ways that can break a "standards-compliant implementation" — especially when leaver processes depend on those fields.

Why "Standard SCIM" Isn't Enough in the Real World

The RFC 7644 specification text allows flexibility, and Okta and Entra ID each chose different implementation paths. For developers building or maintaining SCIM endpoints, this means you can't just write code to the RFC — you also have to adapt to the actual behavior of the two dominant directories.

The most direct consequence: if your endpoint only handles the ideal cases defined by the RFC, then when Entra ID or Okta sends a PUT instead of a PATCH, or omits certain attributes, leaver accounts may not be properly deactivated. An active leaver account is a red flag in a compliance audit.

SCIM (System for Cross-domain Identity Management) is an open standard for cross-domain identity management published by the IETF. Its core specifications include RFC 7643 (which defines the core schema and resource model, such as User, Group, and their attributes) and RFC 7644 (which defines protocol operations including GET, POST, PUT, PATCH, DELETE, as well as filtering and pagination). Its goal is to let identity providers (IdPs such as Okta and Entra ID) synchronize users and groups with various applications (Service Providers) through a unified REST-style interface. However, SCIM leaves room on key details: for example, both PUT and PATCH can be used for updates, but the spec doesn't mandate one as the default; whether attributes are required, how multi-valued attributes are serialized, and the semantics of DELETE also leave significant room for interpretation. This "flexibility within the spec" is precisely the root of divergence among vendor implementations, and the reason SCIM is considered "standard in appearance but fragmented in practice" in real-world integrations.

Okta's Actual Request Behavior

When configuring SCIM applications, Okta defaults to using PATCH operations to update user attributes. Its request body typically includes a schemas array pointing to urn:ietf:params:scim:api:messages:2.0:PatchOp, followed by an Operations list.

The key difference lies in how Okta handles the active attribute. When a user is deactivated in Okta, Okta may send {"op":"replace","path":"active","value":false}, but not all Okta configurations push this operation by default. If the "Deactivate Users" push option isn't checked in the SCIM app configuration, the endpoint receives no notification at all.

Another practical issue is how Okta serializes multi-valued attributes. When sending arrays like emails and phoneNumbers, it may include primary flags and type fields, while some SCIM implementations only parse value, resulting in data loss.

Entra ID's Actual Request Behavior

Entra ID's SCIM provisioning service behaves significantly differently from Okta. It tends to use PUT operations to replace the entire resource rather than PATCH. This means the request body Entra ID sends contains a complete user representation, and if your endpoint only updates some fields when handling PUT, you may accidentally overwrite existing data.

Entra ID's handling of user offboarding is also worth noting. When a user is disabled in Entra ID or removed from the provisioning scope, Entra ID may send a PATCH with active: false, or it may simply stop sending requests — depending on whether the configuration is "soft delete" or "hard delete." If configured for hard delete, Entra ID may send a DELETE request, and if your endpoint doesn't implement DELETE, it returns 405, causing Entra ID to retry and eventually enter quarantine.

SCIM provisioning is the process by which an IdP continuously pushes user and group create, update, and delete operations to downstream applications. Unlike passing identity assertions only at login (such as SAML/OIDC), it maintains state synchronization between the directory and the application. Entra ID's provisioning service is driven by periodically polling the directory for changes (incremental sync), so its request cadence and batching behavior don't fully align with users' real-time actions. When a sync request fails, Entra ID marks that object as "quarantined" and retries with exponential backoff, during which the entire provisioning job may be paused. Understanding this mechanism helps explain why an endpoint returning 405 or 400 leads to prolonged account residue — the problem is often not a single failure, but the overall provisioning stalling after entering retry quarantine.

How Both Deviate from RFC 7644 and Interoperability Profiles

Based on observations of actual requests from both directories, the deviations manifest in three main areas:

• Operation semantics: Okta prefers PATCH, Entra ID prefers PUT, while the RFC supports both but doesn't specify a default.
• Attribute filtering: Entra ID may send attributes not mandated by the RFC (such as manager in urn:ietf:params:scim:schemas:extension:enterprise:2.0:User), while Okta may omit certain standard attributes.
• Error handling: The two directories react differently to error codes returned by SCIM endpoints, affecting retries and provisioning state.

The new SCIM interoperability profiles attempt to narrow these differences, but as of now, the default behavior of both directories still hasn't fully aligned with these profiles.

SCIM interoperability profiles (promoted by the IETF SCIM WG) are a set of specifications that further tighten constraints on top of the RFC, aiming to clarify the expected usage of PUT/PATCH, required attributes, filter syntax, error response formats, and more, in order to reduce ambiguity between IdPs and applications. They don't replace RFC 7644 but provide stricter "subset and sub-behavior" conventions, enabling implementers to write endpoints with clear expectations. However, interoperability profiles are relatively new work, and the default behavior of Okta and Entra ID hasn't yet fully aligned with these conventions, so developers still need to rely on actual captured traffic rather than spec text alone or claimed compatibility.

How to Avoid Leaver Account Residue

When handling the differences between the two directories, the core goal is to ensure that regardless of what Okta or Entra ID sends, the leaver's active status is correctly set to false.

A practical approach is to support both PATCH and PUT in the SCIM endpoint, and to explicitly check for any operation on the active attribute during PATCH handling. For Entra ID's DELETE requests, implementing soft delete logic (marking as inactive) rather than physical deletion can avoid retry storms.

Additionally, it's recommended to log the raw body and source directory of each request in the endpoint, so that when a leaver account isn't deactivated, you can quickly determine whether Okta didn't send the operation or Entra ID was configured not to send the deactivation signal.

Both directories are moving toward standards, but in real-world deployments, differentiated handling for Okta and Entra ID remains a necessary condition for stable SCIM endpoint operation.

Leaver processes are a critical control point in identity governance: after an employee leaves, their accounts across downstream systems must be promptly deactivated or reclaimed, otherwise "orphan accounts" form and become high-risk items in compliance audits (such as SOX, ISO 27001, SOC 2). In SCIM scenarios, leaver account residue typically has two causes: first, the IdP-side configuration doesn't enable "deactivation push," so the directory never sends active:false at all; second, the endpoint side doesn't correctly handle the PUT, PATCH, or DELETE sent by the IdP. Therefore, governance strategy needs to cover both sides — confirm that deactivation/deletion behavior is enabled in Okta and Entra ID's provisioning configurations, while also implementing compatible handling of multiple operation semantics in the SCIM endpoint and retaining request logs for attribution.

One-line Summary

Okta and Entra ID's SCIM implementations differ in key ways, and endpoints need differentiated adaptation to prevent leaver account residue.

Paragraph Summary

The article points out that the practical compatibility of SCIM endpoints is often underestimated: although RFC 7644 defines the standard protocol, Okta and Microsoft Entra ID behave significantly differently in real requests. Okta defaults to using PATCH to update users, and whether it pushes active:false depends on configuration; Entra ID tends to use PUT to replace the entire resource and may send DELETE when a user is removed, with endpoints that don't implement DELETE returning 405 and triggering retry quarantine. If these deviations aren't handled, leaver accounts won't be deactivated, creating compliance risk. The author recommends that SCIM endpoints support both PATCH and PUT, implement soft delete for DELETE, explicitly check the active attribute, and log raw request bodies and source directories for quick issue diagnosis.