Skip to main content
Identity Authority
Category: User Provisioning

SCIM Endpoint

Also known as: SCIM, SCIM API endpoint, SCIM service endpoint, SCIM API server
Simply put

A SCIM endpoint is the web address where an application receives requests to create, update, or remove user and group accounts from an identity provider. It lets an organization's central identity system automatically keep user access in the connected application in sync, rather than requiring administrators to manage those accounts by hand.

Formal definition

A SCIM endpoint is the HTTP-based service exposed by an application (the service provider) that implements the System for Cross-domain Identity Management (SCIM) standard so that an identity provider can provision and deprovision identity resources. In typical implementations it exposes RESTful resource paths such as /Users and /Groups, against which the provisioning source issues create, read, update, and delete operations to synchronize user and group records. This is an IGA lifecycle-management (provisioning/synchronization) mechanism and is distinct from runtime access enforcement and from authentication, SCIM governs how account and attribute data are pushed into a target system, not how a principal authenticates or is authorized at access time. Exact supported resources, schema extensions, and operations depend on the service provider's SCIM implementation and the profile it supports; consult the specific vendor documentation, as capabilities vary by deployment.

Why it matters

Manual account management across a growing portfolio of applications is error-prone and slow, and the gaps it creates are a governance and security liability. When an employee changes roles or leaves an organization, any application whose accounts are managed by hand risks retaining stale or orphaned access until an administrator remembers to remove it. A SCIM endpoint lets the central identity provider push those lifecycle changes, creation, attribute updates, and deprovisioning, into the connected application automatically, closing the window during which access lingers after it should have been revoked.

Because SCIM standardizes how identity data is synchronized, it reduces the need for bespoke, per-application integration code. Identity providers such as Microsoft Entra, AWS IAM Identity Center, and Okta document how to build to or consume a SCIM endpoint, which means an application that exposes a conformant endpoint can be provisioned by multiple identity sources without custom connectors for each. This matters for both operational scale and for audit: consistent, automated provisioning produces more predictable and reviewable access data than manual processes.

It is important to keep SCIM's scope clear. A SCIM endpoint governs how account and attribute data are provisioned and deprovisioned, an IGA lifecycle concern, not how a user authenticates or what they are authorized to do at access time. A well-implemented SCIM endpoint improves the timeliness and accuracy of the underlying account data, but it does not by itself enforce access decisions; runtime authorization and authentication are handled by separate mechanisms.

Who it's relevant to

IAM and Integration Engineers
Engineers building or consuming a SCIM endpoint implement the RESTful resource paths and operations that let an identity provider synchronize accounts. Provider documentation from Microsoft Entra, AWS IAM Identity Center, and Okta describes how to build a conformant endpoint or connect to one, and engineers must confirm which resources, schema extensions, and operations are actually supported on both ends.
Identity Governance Leads
For those responsible for joiner-mover-leaver processes, a SCIM endpoint is the mechanism that automates provisioning and deprovisioning into connected applications, reducing reliance on manual account management. It supports lifecycle accuracy but should not be confused with access certification, segregation-of-duties enforcement, or runtime authorization, which are handled separately.
SaaS Application Providers
Vendors whose applications are targets for enterprise provisioning expose a SCIM endpoint so that customer identity providers can automatically manage users and groups without custom per-customer connectors. Offering a conformant endpoint broadens the set of identity providers that can integrate and provision accounts against the application.
Compliance and Audit Teams
Automated, standardized provisioning tends to produce more consistent and reviewable account data than manual processes, which supports access reviews and audit. Reviewers should understand that SCIM governs how account and attribute data are pushed into a system, not how access is enforced at runtime, and scope their evaluations accordingly.

Inside SCIM

Base URL and versioned path
A SCIM service provider typically exposes endpoints under a base URL that includes a version segment (for example /scim/v2), which anchors all resource-specific paths.
/Users resource endpoint
The endpoint used to create, read, update, and delete user resources. It supports standard HTTP verbs (POST, GET, PUT, PATCH, DELETE) for provisioning and deprovisioning identities, depending on what the service provider implements.
/Groups resource endpoint
The endpoint for managing group resources and their membership, used to synchronize group-based structures between an identity provider and the service provider.
Discovery endpoints
SCIM defines endpoints such as /ServiceProviderConfig, /ResourceTypes, and /Schemas that let a client discover the provider's supported features, resource types, and attribute schemas rather than assuming them.
Query, filter, and PATCH semantics
Endpoints commonly accept filtering, pagination, and sorting parameters for reads, and PATCH operations for partial updates. Support varies by implementation and should be confirmed against the provider's advertised configuration.
Authorization layer
SCIM itself is a provisioning protocol and does not define its own authentication mechanism; endpoints are typically protected by a separate scheme such as an OAuth 2.0 bearer token, depending on the deployment.

Common questions

Answers to the questions practitioners most commonly ask about SCIM.

Does a SCIM endpoint authenticate users at sign-in?
No. A SCIM endpoint is a provisioning interface, not an authentication mechanism. It handles the lifecycle administration of identity resources such as users and groups, creating, reading, updating, and deactivating accounts, as part of identity governance and administration (IGA) concerns. Runtime authentication of a user at sign-in is a separate step handled by protocols such as OpenID Connect or SAML 2.0. A SCIM endpoint typically populates and maintains the account that an authentication flow later verifies, but it does not itself verify who a principal is.
Does provisioning an account through a SCIM endpoint also assign what that account is allowed to do?
Not in the authorization-decision sense. SCIM can convey attributes, group memberships, and (via the enterprise user extension or entitlement resources) some entitlement-related data, but this is administration of identity state rather than runtime authorization enforcement. What a principal may actually do is determined at access time by an enforcement layer, for example a PDP evaluating policy under RBAC, ABAC, or PBAC, using the attributes and memberships that provisioning may have supplied. Populating a group through SCIM does not itself enforce access; it is one input that a downstream authorization model may consult, depending on configuration.
How should a SCIM endpoint typically be authenticated and secured?
In most deployments the SCIM endpoint is protected by an OAuth 2.0 bearer token, though some implementations also support other schemes such as basic authentication or long-lived API tokens depending on the vendor and profile. Because SCIM messages carry personal and account data over the wire, transport-layer protection (TLS) is generally expected. Note that securing the channel and authorizing the client that calls the endpoint are distinct from anything the SCIM payload itself does; the endpoint is a privileged administrative interface and is often scoped and rate-limited accordingly.
What resource types and operations should a SCIM endpoint be prepared to handle?
The core resource types are typically Users and Groups, exposed at paths such as /Users and /Groups, with a schema-discovery mechanism (/Schemas, /ResourceTypes, /ServiceProviderConfig) that advertises supported features. Operations generally map to HTTP methods: POST to create, GET to read or query, PUT for full replacement, PATCH for partial updates, and DELETE for removal. Support for PATCH and for filtering can vary between implementations, so interoperability testing against the specific client and service provider is advisable rather than assuming full coverage.
How is user deactivation usually handled through a SCIM endpoint?
Deprovisioning behavior varies by deployment. Many identity providers signal deactivation by setting the 'active' attribute to false via PATCH or PUT rather than issuing a hard DELETE, allowing the service provider to disable rather than erase the account. Whether a DELETE performs a soft or permanent removal depends on the service provider's implementation. Because this varies, teams should confirm how their specific target interprets both 'active=false' and DELETE, particularly where audit retention or joiner-mover-leaver requirements apply.
How should errors and synchronization mismatches on a SCIM endpoint be handled?
SCIM defines standard HTTP status codes and a structured error response format, so clients should handle conditions such as 409 for uniqueness conflicts, 404 for missing resources, and 429 where rate limiting applies, depending on what the service provider returns. Because SCIM provisioning and the identity provider's own state can drift, many deployments rely on periodic reconciliation or full synchronization passes in addition to event-driven updates. Idempotent handling and correlation on a stable identifier help avoid duplicate resources when retries occur.

Common misconceptions

SCIM endpoints handle user authentication or sign-in.
SCIM is a provisioning and lifecycle-management protocol for creating, updating, and deactivating identity resources. It is an identity governance and administration concern, not a runtime authentication mechanism; the actual sign-in flow is handled by separate protocols such as SAML 2.0 or OpenID Connect. SCIM endpoints are themselves typically protected by a separate authorization scheme.
All SCIM endpoints support the same operations and attributes across every service provider.
Support for PATCH, filtering, pagination, bulk operations, and specific attributes varies by implementation. The /ServiceProviderConfig and /Schemas discovery endpoints exist precisely because clients should not assume capabilities and should verify what a given provider actually supports.
A working SCIM endpoint guarantees real-time enforcement of access changes.
SCIM provisions and updates identity data such as account state and group membership, but it does not itself enforce access at request time. Runtime enforcement depends on separate components (for example a PDP/PEP and token validation) and on how downstream systems consume the provisioned data, which may not be instantaneous depending on configuration.

Best practices

Query the /ServiceProviderConfig, /ResourceTypes, and /Schemas discovery endpoints before integrating, rather than hardcoding assumptions about supported operations, filters, or attributes.
Protect SCIM endpoints with a robust authorization scheme (commonly an OAuth 2.0 bearer token) and serve all traffic over TLS, since SCIM does not define its own authentication mechanism.
Use PATCH for partial updates where the provider supports it to avoid overwriting attributes, and confirm PATCH support through the advertised service provider configuration before relying on it.
Version-pin against the SCIM path the provider exposes (for example /scim/v2) and handle pagination and filtering explicitly, as behavior varies between implementations.
Treat SCIM as an IGA/lifecycle concern and validate that deprovisioning through DELETE or attribute deactivation actually revokes access in downstream systems, since provisioning does not guarantee real-time enforcement.
Log and monitor provisioning operations for reconciliation and to support access reviews and segregation-of-duties controls, and handle SCIM error responses so failed operations do not silently leave stale accounts.
Application Security Isn’t Optional Anymore.