What Is SCIM? System for Cross-Domain Identity Management Explained

SCIM, the System for Cross-domain Identity Management, is an open standard for automating user and group lifecycle changes between an identity provider and an application. It lets an organization create, update, disable, and remove accounts without asking an application administrator to repeat every directory change manually.

In B2B SaaS, SCIM also needs to preserve tenant context. Each directory connection should resolve to one customer organization so that a change intended for one tenant cannot alter another tenant’s memberships, roles, or access.

How does SCIM work?

At the protocol level, a SCIM client – usually an identity provider such as an enterprise directory – sends standardized HTTP requests to a SCIM service provider, such as a SaaS application. The application validates those requests and applies the changes to its user, group, and membership records.

SCIM 2.0 is defined by two primary IETF standards:

• RFC 7643 defines the core schema for resources such as Users and Groups.
• RFC 7644 defines the protocol operations used to create, retrieve, update, search, and delete those resources.

SCIM reduces repetitive administration, but it is not an interactive login protocol. SAML or OpenID Connect can authenticate a user at sign-in, while SCIM provisions and deprovisions the account that the user signs into. Many enterprise deployments use both, but neither standard universally requires the other.

A typical lifecycle looks like this:

1. An administrator configures a SCIM connection between the organization’s directory and the SaaS application.
2. The directory sends a request to create a user or group.
3. The application validates the request and maps the external identity to an internal record.
4. Later directory changes update user attributes, group membership, or account status.
5. When access should end, the directory disables or removes the corresponding application membership.

SCIM resources and endpoints

SCIM commonly represents people as User resources and collections of people as Group resources. A service provider can expose discovery endpoints including /Schemas, /ResourceTypes, and /ServiceProviderConfig, along with resource endpoints such as /Users and /Groups.

Depending on the service provider’s supported capabilities, clients can use operations such as:

• POST to create a resource;
• GET to retrieve or filter resources;
• PUT to replace a resource;
• PATCH to update selected attributes or group membership; and
• DELETE to remove a resource where the implementation supports that behavior.

SCIM defines the interoperable framework, but applications still need to document their supported schemas, filters, patch behavior, authentication method, and deprovisioning semantics.

Example SCIM deactivation request

The example below illustrates a SCIM 2.0 PATCH that sets a User resource’s standard active attribute to false. The service provider still defines how that state maps to suspension, membership removal, or deletion in its own identity model.

PATCH /Users/2819c223-7f76-453a-919d-413861904646
Content-Type: application/scim+json

{
  "schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
  "Operations": [
    {
      "op": "replace",
      "path": "active",
      "value": false
    }
  ]
}

This request shape follows the SCIM schema and protocol standards; it does not imply that every provider performs an irreversible delete when active becomes false.

How to automate SCIM provisioning across customer tenants

SCIM provisioning covers account creation and ongoing changes such as attribute updates, group synchronization, suspension, reactivation, and deprovisioning. In a multi-tenant application, every connection and operation must bind to an authorized customer context derived from the authenticated connection and the application’s own configuration – not an untrusted request field alone.

1. Create or identify the customer organization. Assign a stable internal tenant or account ID before provisioning users.
2. Bind the directory connection to that tenant. Credentials, external directory identifiers, schemas, and mappings must resolve to one authorized customer context.
3. Validate and normalize incoming resources. Enforce connection authentication, schema rules, attribute types, and accepted values.
4. Prevent duplicate identities. Match stable identifiers such as externalId and normalized userName, reconcile safe retries, and handle uniqueness conflicts explicitly. A repeated SCIM POST is not inherently idempotent and may correctly return a conflict.
5. Process groups separately from roles. An identity-provider group is not automatically an application role. Keep group-to-role mapping explicit and reviewable.
6. Handle suspension and deprovisioning deliberately. Distinguish disabling access, removing one tenant membership, and deleting a global identity.
7. Reconcile failures. Record correlation IDs and outcomes, expose actionable errors, retry only safe operations, and compare directory state with application state when necessary.
8. Audit tenant and actor context. Log which connection requested the change, which tenant and resource were affected, and whether the operation succeeded.

Example: one person in two customer organizations

Suppose Alex belongs to both Acme and Beta. Each customer directory should control only its own tenant membership. Disabling Alex in Acme must not remove Alex’s Beta membership, roles, or access.

In Frontegg, deprovisioning a user from Tenant A removes that tenant membership without changing the user’s memberships in other tenants. The global user identity is deleted only when the removed membership was the user’s last tenant membership. This boundary prevents a lifecycle action from one customer from becoming a cross-tenant deletion.

SCIM vs. just-in-time provisioning

SCIM and just-in-time provisioning can both create application access, but they use different triggers and cover different parts of the lifecycle.

Frontegg supports JIT independently of SCIM, and the two can coexist. JIT creates a membership on first authenticated login, while SCIM can create it proactively. If SCIM has already provisioned the user, the first login resolves to the existing account rather than creating a duplicate. Teams should still define which source owns mutable attributes and group membership.

SCIM vs. SAML

SCIM manages identity lifecycle data; SAML communicates authentication assertions for single sign-on. SCIM can create or disable an application account without authenticating an interactive session. SAML can authenticate a session without synchronizing the user’s full lifecycle in advance.

An enterprise SaaS application may use SSO for authentication and SCIM for lifecycle management. This combination is common, but SAML SSO is not a prerequisite imposed by the SCIM standard.

Benefits of SCIM

SCIM can prepare access before first login, process offboarding for users who may never return, and reduce repetitive user and group administration. Its standardized schema and protocol give identity providers and applications a shared lifecycle foundation, while each application still defines its supported behavior and the distinction between disabling access, removing a tenant membership, and deleting an identity.

SCIM implementation safeguards

A secure SCIM implementation must protect the connection, preserve tenant boundaries, and make lifecycle operations safe to repeat. Test the failure cases as carefully as the successful create-user path.

• Use TLS and properly scoped connection credentials.
• Derive tenant context from the authenticated connection, not an untrusted payload attribute.
• Make create, update, and deprovisioning handlers idempotent.
• Validate filters, pagination, PATCH semantics, and schema extensions against SCIM 2.0.
• Avoid logging tokens or unnecessary sensitive directory attributes.
• Separate “disable access,” “remove membership,” and “delete identity.”
• Test duplicate, delayed, out-of-order, and partially failed operations.
• Verify that a group change cannot grant an unintended role.
• Record tenant, connection, resource, correlation ID, outcome, and error details for investigation.

SCIM provisioning with Frontegg

Frontegg provides tenant-scoped SCIM 2.0 provisioning for B2B SaaS applications. Its SCIM Provisioning API separates Management endpoints from tenant self-service endpoints, where authorized users can manage a SCIM connection for their account.

Frontegg can import identity-provider groups and lets authorized customer administrators map those groups to Frontegg roles. Keeping the mapping explicit helps applications avoid treating an external group name as an automatic authorization decision.

For the broader identity model behind tenant-aware provisioning and its relationship to JIT, see B2B user management and SaaS multitenancy.