Skip to main content
Identity Authority
Category: User Provisioning

SCIM Connector

Also known as: SCIM, SCIM provisioning connector, SCIM endpoint connector
Simply put

A SCIM connector is a software component that links an identity system to an application so that user and group accounts can be created, updated, and removed automatically. It uses the System for Cross-domain Identity Management (SCIM) standard, a common language that lets different systems exchange identity information. This automation reduces the manual work of setting up and managing accounts across multiple applications.

Formal definition

A SCIM connector implements the System for Cross-domain Identity Management (SCIM) specification, an open standard for managing user identity information, to automate the provisioning and deprovisioning of user and group accounts between an identity provider or IGA platform and a SCIM-compliant target resource. It typically operates against a SCIM endpoint (a service exposing SCIM resource endpoints such as /Users and /Groups) and handles lifecycle operations such as create, read, update, and delete of accounts and group memberships. Per the evidence, connectors of this type are used both for cloud and on-premises applications and, in some vendor implementations (for example Okta's on-premises provisioning), require no specific SCIM knowledge to build and use. This is an identity lifecycle and provisioning concern; SCIM connectors govern account state synchronization and are distinct from runtime authentication and authorization enforcement, which are out of scope for this term. Behavior varies by vendor implementation and SCIM profile support, so supported operations and attribute mappings depend on configuration.

Why it matters

Manual account management across a growing portfolio of applications is error-prone and difficult to audit. When provisioning is handled by hand, accounts are frequently created inconsistently, attributes drift out of sync between the identity source and the target application, and, most critically, deprovisioning is often delayed or missed entirely when a user leaves or changes roles. Orphaned accounts that persist after an offboarding are a well-understood attack surface. A SCIM connector addresses this by giving an identity provider or IGA platform a standardized way to push lifecycle changes (create, update, delete) to a SCIM-compliant target, so account state in the application tracks the authoritative source.

Because SCIM is an open standard, connectors reduce the integration burden of supporting many applications, each of which might otherwise expose a proprietary provisioning API. Per the evidence, SCIM is described as the standard for automated provisioning of users and groups between IAM systems and applications across cloud and hybrid environments, and connectors of this type support both cloud and on-premises apps. In some vendor implementations, such as Okta's on-premises provisioning, no specific SCIM knowledge is required to build and use a connector, which lowers the operational barrier to onboarding new targets.

It is important to scope expectations correctly: a SCIM connector governs account and group lifecycle synchronization, not runtime access decisions. It ensures the right accounts exist with the right attributes and memberships, but it does not authenticate users or enforce authorization at access time. Timely deprovisioning through SCIM strengthens an organization's security posture, but it complements rather than replaces authentication and authorization controls. Actual behavior, including which lifecycle operations and attribute mappings are supported, varies by vendor implementation and SCIM profile, so the security value depends on how completely a given connector is configured.

Who it's relevant to

IAM and Provisioning Engineers
Engineers responsible for connecting identity providers and IGA platforms to downstream applications use SCIM connectors to automate account lifecycle operations. They configure attribute mappings, validate supported SCIM operations against each target's endpoint, and troubleshoot synchronization behavior, which varies by vendor implementation and profile support.
Identity Governance Leads
Governance teams rely on automated provisioning and deprovisioning to keep account state aligned with authoritative sources across cloud and hybrid environments. Timely, standardized deprovisioning through SCIM supports cleaner access reviews and reduces the risk of orphaned accounts, though the connector itself handles lifecycle state rather than certification or segregation-of-duties enforcement.
System Administrators
Administrators onboarding new applications benefit from connectors that, in some implementations such as Okta's on-premises provisioning, require no specific SCIM knowledge to build and use. They manage the day-to-day operation of provisioning to both cloud and on-premises targets.
Compliance and Audit Officers
Automated, standardized provisioning produces more consistent and auditable account lifecycle records than manual processes. Compliance stakeholders should note that a SCIM connector synchronizes account and group state and is distinct from runtime authentication and authorization controls, which fall outside its scope.

Inside SCIM

SCIM Endpoint Configuration
The base URL and resource paths (such as /Users and /Groups) exposed by the target service provider that the connector calls to perform provisioning operations. In most deployments this is defined per SCIM 2.0 conventions, though exact paths and supported resources vary by vendor.
Authentication to the SCIM Service
The credential mechanism the connector uses to authenticate itself to the target endpoint, commonly an OAuth 2.0 bearer token or a long-lived API token depending on configuration. This authenticates the connector as a client and is distinct from authenticating the end users being provisioned.
Attribute and Schema Mapping
The mapping between source identity attributes (for example from an IdP or HR system) and the SCIM resource schema, including core User attributes and any supported enterprise or custom extension attributes. Mapping fidelity depends on the schema the service provider actually supports.
Provisioning Operations
The lifecycle actions the connector performs against SCIM resources, typically create, read, update, deactivate/delete, and group membership changes, corresponding to SCIM HTTP verbs. These are IGA administration operations, not runtime access enforcement decisions.
Synchronization Logic
The reconciliation behavior that keeps source and target identity states aligned, which may operate on a scheduled basis or in response to events depending on the connector and platform. Behavior around deprovisioning and conflict handling varies by implementation.

Common questions

Answers to the questions practitioners most commonly ask about SCIM.

Does a SCIM connector handle authentication for the identities it provisions?
No. A SCIM connector is a provisioning mechanism concerned with the lifecycle of identity resources (creating, updating, deactivating, and deleting users and groups) in a target system. It does not authenticate the end users whose accounts it manages, nor does it participate in runtime access flows. Authentication of those users is handled separately by the target application or an associated identity provider, typically through protocols such as SAML 2.0 or OpenID Connect. The connector itself does authenticate to the SCIM endpoint (commonly using a bearer token or OAuth 2.0 credentials) to authorize its own API calls, but that is service-to-service authorization for provisioning operations and should not be conflated with authenticating the provisioned users.
Is a SCIM connector the same thing as real-time access enforcement, deciding what a user can do at login?
No. A SCIM connector operates in the identity governance and administration (IGA) domain, propagating account state and group or role membership to a target system ahead of, or independent of, any given access request. It is not a policy decision point (PDP) or policy enforcement point (PEP) and does not evaluate authorization decisions at the moment of access. In most deployments the connector writes attributes and memberships that a target application later consults when making its own access decisions, but the runtime enforcement is performed by the application, not by the connector. Lifecycle propagation and real-time enforcement are distinct concerns.
How do I map source attributes to the SCIM schema when target systems extend or vary it?
SCIM defines a core schema for users and groups along with an enterprise user extension, but many target systems add custom attributes or interpret optional fields differently. In practice you configure an attribute mapping in the provisioning source that translates source identity attributes to SCIM core, enterprise-extension, and any vendor-defined custom schema attributes exposed by the target's SCIM endpoint. Behavior for unmapped, multi-valued, or complex attributes varies by implementation, so validate against the target's advertised schema (often available via the SCIM schema and resource-type discovery endpoints where supported) rather than assuming uniform handling.
How should deprovisioning be configured through a SCIM connector?
SCIM supports both deactivation, typically by setting the user's active attribute to false via a PATCH or PUT, and deletion via the DELETE operation. Which behavior a target honors, and whether a DELETE performs a soft or hard delete, depends on the target implementation. Many organizations prefer deactivation over deletion to preserve audit history and support reactivation, and align the trigger with an authoritative source event such as an HR termination. Confirm how the specific target treats each operation before relying on it, since the SCIM standard does not mandate a single retention behavior.
How are provisioning errors and partial failures handled when using a SCIM connector?
SCIM operations return HTTP status codes and error responses, and connectors typically implement retry, logging, and reconciliation logic on top of those responses. Handling of conflicts (for example a duplicate user), rate limiting, and transient failures depends on both the connector and the target endpoint's behavior. Where supported, some deployments use periodic reconciliation or full synchronization passes to detect and correct drift between the source of truth and the target. You should review how your specific connector surfaces failures, whether it retries idempotently, and whether it alerts governance owners, because these behaviors are not uniform across products.
What credentials and connection settings does a SCIM connector require to reach a target endpoint?
A SCIM connector generally needs the target's SCIM base URL and credentials to authorize its API calls, commonly a long-lived bearer token or an OAuth 2.0 client credentials grant, depending on what the target supports. Connections are expected to run over TLS. Beyond credentials, configuration typically includes attribute mappings, provisioning scope (which users and groups are in scope), and the enabled operations (create, update, deactivate, delete). Specific supported authorization methods and configuration options vary by vendor, so consult the target system's SCIM documentation for the exact requirements and any supported discovery endpoints.

Common misconceptions

A SCIM connector authenticates users into the target application.
A SCIM connector performs identity lifecycle administration, provisioning, updating, and deprovisioning accounts and group memberships. It does not authenticate end users at runtime; authentication is handled separately, typically via a federation protocol such as SAML 2.0 or OpenID Connect. Provisioning (an IGA concern) and authentication are distinct steps.
SCIM and the federation protocol (SAML or OIDC) are interchangeable or redundant.
SCIM addresses provisioning and account lifecycle management, while SAML or OIDC address single sign-on and authentication at access time. They typically operate together but solve different problems, and one does not replace the other.
Any two SCIM 2.0 implementations will interoperate fully out of the box.
While SCIM 2.0 defines a common schema and protocol, service providers differ in which resources, attributes, extensions, and operations they support. In practice attribute mapping and connector-specific adjustments are often required, and behavior varies by vendor and deployment.

Best practices

Scope the connector's service credential to the minimum provisioning permissions required, and rotate long-lived API tokens or manage OAuth 2.0 client credentials according to your secret-management policy.
Validate the target service provider's actual supported SCIM schema and operations before designing attribute mappings, rather than assuming full SCIM 2.0 coverage.
Define explicit deprovisioning and account-deactivation behavior so that departed or deactivated identities are removed or disabled promptly, supporting joiner-mover-leaver processes.
Keep provisioning (SCIM) and authentication (SAML/OIDC) configurations documented as separate concerns to avoid conflating lifecycle management with runtime access enforcement.
Monitor and log connector operations and reconciliation results so failed or partial provisioning actions can be detected and remediated, and feed this into access certification and review processes.
Test attribute mapping and synchronization behavior in a non-production environment first, since conflict handling and edge-case behavior can differ by connector and vendor.
a promotional banner asking how ready are you for PCI DSS 4.0? With a call-to-action to get the checklist now.