--- source_url: "https://developer.okta.com/docs/concepts/scim/" title: "Understanding SCIM | Okta Developer" mirrored_at: 2026-08-15T15:04:34.906Z host: developer.okta.com cited_in_42a: true mirror_canonical: "https://index.42a.ai/developer.okta.com/docs/concepts/scim/index" --- > **Original source:** https://developer.okta.com/docs/concepts/scim/ This topic covers the concepts and use cases for SCIM and Okta. When you're ready to create a SCIM integration, see [Build a SCIM provisioning integration](https://developer.okta.com/docs/guides/scim-provisioning-integration-overview). For reference information on how to implement SCIM with Okta, see [SCIM Protocol (opens new window)](https://developer.okta.com/docs/api/openapi/okta-scim/guides/). ## What is SCIM for? SCIM, or the [System for Cross-domain Identity Management (opens new window)](https://scim.cloud/) specification, is an open standard designed to manage user identity information. SCIM provides a defined schema for representing users and groups, and a RESTful API to run CRUD operations on those user and group resources. The goal of SCIM is to securely automate the exchange of user identity data between your company's cloud apps and any Service Providers (SP). Managing user lifecycles in your org is a fundamental business problem. Hiring employees is just the first step. You also need to provision apps for their job, enforce corporate security policies, and update user accounts as they advance through your company. At the end of their employment, you need to ensure that all access is quickly and thoroughly revoked across all apps. Manually handling all of this can be time-consuming and error-prone. ![SCIM user lifecycle diagram](https://developer.okta.com/img/oin/scim_lifecycle.png) As your company grows, the number of user accounts and provisioned software apps increases. Requests to add and remove users, reset passwords, change permissions, and add new types of accounts all take up valuable IT department time. With the SCIM protocol, user data is stored in a consistent way and can be shared with different apps. Since data is transferred automatically, complex exchanges are simplified and the risk of error is reduced. Adopting SCIM for domain management improves overall security for your company. Employees no longer need to sign in to each of their accounts. As teams develop new workflows and adopt new apps, your company can ensure security policy compliance across all accounts. ## How does Okta help? [Okta Lifecycle Management (opens new window)](https://help.okta.com/okta_help.htm?id=ext_Provisioning_Deprovisioning_Overview) is a platform solution to provision and manage user accounts in cloud-based apps. Okta serves as a universal directory for identity-related information, giving the following benefits: - IT departments can manage the user provisioning lifecycle through a single system. - New employees are automatically provisioned with a user account for their apps. - You can create employee accounts either directly from Okta accounts or shared from external systems such as HR apps or Active Directory. - Any profile updates (such as department changes) populate automatically. - Inactive employees are automatically deactivated from their apps. > **Note**: Okta event hooks provide a mechanism for outbound calls to notify your systems of events occurring in your Okta org. The event hooks can, for example, provision external app access after a user account is created in Okta. Event hooks are a flexible and lightweight alternative to SCIM. See [Event hook implementation](https://developer.okta.com/docs/guides/event-hook-implementation/nodejs/main/). ## How does SCIM work? Provisioning consists of a set of actions between a SCIM client (like Okta) and the SCIM server (such as your cloud-based integration or service provider). Using REST-style architecture and JSON objects, the SCIM protocol communicates data about users or groups. As an app developer, you define the use cases needed and then build the corresponding SCIM actions into your integration. By implementing support for the SCIM standard, an integration in the Okta Integration Network is notified when a user is created in Okta. An integration is also notified when the user is updated or removed from their app in Okta. The provisioning actions performed by an integration are described using the database operation acronym "CRUD": Create, Read, Update, and Delete. The four CRUD operations are the building blocks that combine to solve your end-to-end use cases. For more information about these operations for users and for groups, see the corresponding sections in the [SCIM V2.0 (opens new window)](https://developer.okta.com/docs/api/openapi/okta-scim/guides/scim-20/) and [SCIM V1.1 (opens new window)](https://developer.okta.com/docs/api/openapi/okta-scim/guides/scim-11/) references. ### Create This SCIM operation creates users in your downstream app based on the values in the Okta user profile and group assignments. ### Read Information about user and group resources can be queried from your app to match them against existing Okta resources. If the resources don't exist, they can be imported into Okta. ### Update If a resource in your app needs to be updated based on data changed in Okta, this operation updates existing user or group attributes. Alternatively, if your app functions as the source of truth for specific attributes of a user identity, this action updates the Okta user profile. > **Note:** If your SCIM server is out of sync with Okta, then it might not receive updates for the out-of-sync attributes. See **Update a specific user (PUT)** in [SCIM V2.0 (opens new window)](https://developer.okta.com/docs/api/openapi/okta-scim/guides/scim-20/#update-a-specific-user-put) and [SCIM V1.1 (opens new window)](https://developer.okta.com/docs/api/openapi/okta-scim/guides/scim-11/#update-a-specific-user-put). User attributes can be mapped from your source into Okta. Conversely, an attribute can be mapped from Okta to a target attribute in your app. > **Note:** The `active` user attribute represents a user's status, and relates to activating, reactivating, and deactivating a user. Therefore, this attribute behaves differently than most other attributes. > > The first time that you assign a user to an app and `active=true` in Okta, the user is set to `active=true` on the SCIM server. Reassigning a user to an app works similarly. Afterwards, Okta doesn't pull in a user whose status is set to `active=false`, even in a full import. Even if Okta is the source of truth, updating through a profile push doesn't update the user status downstream to the SCIM app. > > See **Update a specific user (Patch)** in [SCIM V2.0 (opens new window)](https://developer.okta.com/docs/api/openapi/okta-scim/guides/scim-20/#update-a-specific-user-patch) and [SCIM V1.1 (opens new window)](https://developer.okta.com/docs/api/openapi/okta-scim/guides/scim-11/#update-a-specific-user-patch). ### Delete (Deprovision) Deleting or deprovisioning user profiles in SCIM operations depends on whether Okta or your SCIM app is the source of truth for user profile information. - If an admin deprovisions a user's profile inside Okta, the user resource inside your SCIM app is updated with `active=false`. If that user needs to be reprovisioned later (for example, a return from parental leave or if a contractor is rehired), then you can switch back the `active` attribute to `true`. Deactivated user accounts lose access to their provisioned Okta integrations. Your app can run different actions after deprovisioning a user, such as changing user access permissions or removing a license. - If an admin deletes a deactivated user profile inside Okta, the user resource inside your SCIM app isn't changed. The initial deactivation step already set `active=false`. Okta doesn't send a request to delete the user resource inside the customer's SCIM app. - SCIM app sources the user: A user profile is deleted from inside your SCIM app. The user's profile is then deleted inside Okta when an import from your SCIM app is run. - SCIM app sources the Okta integration: A user profile is marked with `active=false` inside your SCIM app. The user's profile is then marked as deactivated in Okta when an import from your SCIM app runs. ### Sync passwords Outside of the base CRUD operations, Okta supports other provisioning features like syncing passwords. Password synchronization helps you coordinate Okta-sourced users to ensure that a user's Active Directory (AD) password and their Okta password always match. With password synchronization, your users have a single password to access apps and devices. This option sets the user's password for your integration to match the Okta password or to be assigned a randomly generated password. For more information about this functionality and how to configure it in the Okta product, see [Synchronize passwords from Okta to Active Directory (opens new window)](https://help.okta.com/okta_help.htm?id=ext_Security_Using_Sync_Password). ### Map profile attributes Another provisioning feature supported by Okta is the mapping of user profile attributes. After enabling provisioning, you can set an app as the "source" from which user profiles are imported or the "target" to which attributes are sent. Okta uses a Profile Editor to map specific user attributes from the source app to the Okta user profile. ## Lifecycle management using profile sourcing Profile sourcing defines the flow and maintenance of user attributes. When a profile is sourced from outside of Okta (example: an HR app or LDAP), then the Okta user's attributes and lifecycle state are derived exclusively from that resource. The SCIM protocol handles the secure exchange of user identity data between the profile source and Okta. In this scenario, the profile isn't editable in Okta by the user or an Okta admin. For example, if the lifecycle state of the user is changed to "Disabled" in Active Directory, then on the next SCIM read operation, the linked Okta user profile is switched and given the corresponding lifecycle state of `active=false`. For more information about profile sourcing and how to configure it in the Admin Console, see: - [Profile sourcing (opens new window)](https://help.okta.com/okta_help.htm?id=ext_Directory_Profile_Masters) - [Provisioning and Deprovisioning (opens new window)](https://help.okta.com/okta_help.htm?id=ext_Provisioning_Deprovisioning_Overview) ## Handle SCIM server rate limiting (HTTP 429) When integrating a custom SCIM app with Okta, it's important to understand how Okta handles rate limiting. If your SCIM server responds with an `HTTP 429 Too Many Requests` error, Okta automatically detects this response and attempts to restore normal provisioning operations without requiring manual intervention. ### Automatic retry behavior When a SCIM server returns an `HTTP 429` status code, Okta immediately pauses the provisioning task. - The provisioning task's status in the Admin Console is updated with a message indicating the failure was due to API rate limiting. - Okta automatically reschedules the operation for a later retry based on specific timing rules. - No action is required from an administrator. The process is fully automated. ### Retry timing and exponential backoff Okta's retry logic depends on the presence and format of the `Retry-After` header in the `HTTP 429` response. For repeated failures, Okta employs an exponential backoff strategy. The wait time for the first retry is determined as follows: Condition Okta's wait time Example `Retry-After` header with a seconds value is present Okta waits the exact number of seconds specified. `Retry-After: 120` Okta waits two minutes `Retry-After` header isn’t present Okta defaults to a five-minute wait `Retry-After` header is in an **unsupported format** (for example, HTTP-date) Okta defaults to a five-minute wait `Retry-After: Wed, 11 Mar 2026 23:29:00 GMT` Okta defaults to a five-minute wait > **Note:** Okta's rate-limit handling only supports integer values (seconds) in the `Retry-After` header. Non-integer or `null` values aren’t processed, causing the retry logic to use the default wait time. If a provisioning job continues to receive `HTTP 429` errors, Okta implements an exponential backoff strategy with progressively longer wait times. For each subsequent retry attempt, Okta doubles the previous wait time. This retry process continues for a maximum of 10 attempts. If the 10th attempt also fails due to rate limiting, the task fails permanently and requires manual intervention. ### Supported operations and integrations This automatic rate-limiting behavior applies to a wide range of provisioning operations and SCIM-based integrations. Supported operations: - User provisioning (Create, update, and delete) - User activation and deactivation - User profile synchronization - Group Push (Create, update, and delete) - User import Applicable integrations: - All custom SCIM 1.1 integrations - All custom SCIM 2.0 integrations - Official Okta integrations for apps that use SCIM, such as the Slack SCIM API and Zoom SCIM API ## Provisioning use cases Provisioning actions can be combined to solve for end-to-end use cases. Okta supports these common Provisioning use cases: - Provision downstream apps automatically when a new employee joins the company. - Update your downstream apps automatically when changes are made to employee profile attributes. - Remove an employee's access to downstream apps automatically on termination or leave. - Link existing downstream apps users with Okta users using a one-time import. ## Publish SCIM-based provisioning integrations For your customers to use your SCIM provisioning integration with Okta, you need to publish it through the [Okta Integration Network (opens new window)](https://www.okta.com/integrations/). After you have built and tested your SCIM app, read through our [Publish an OIN integration](https://developer.okta.com/docs/guides/submit-app-overview/) guide. For more information about SCIM and how to use the Admin Console to set up provisioning in your integration, see: - [Provision cloud applications (opens new window)](https://help.okta.com/okta_help.htm?id=ext_prov_okta_lcm_user_provision) - [SCIM Technical FAQs](https://developer.okta.com/docs/concepts/scim/faqs/) - [Build a SCIM provisioning integration](https://developer.okta.com/docs/guides/scim-provisioning-integration-overview) - [Add SCIM provisioning to app integrations (opens new window)](https://help.okta.com/okta_help.htm?id=ext_Apps_App_Integration_Wizard-scim) - [Provisioning Concepts (opens new window)](https://support.okta.com/help/s/article/okta-provisioning?language=en_US) - [Provision on-premises apps (opens new window)](https://help.okta.com/okta_help.htm?id=ext_OPP_configure) - IETF [Overview and Specification of the SCIM Protocol (opens new window)](https://scim.cloud/) For setting up Active Directory or LDAP for profile sourcing: - [Manage your Active Directory integration (opens new window)](https://help.okta.com/okta_help.htm?id=ext_okta_active_directory_agent) - [Manage your LDAP provisioning integration (opens new window)](https://help.okta.com/okta_help.htm?id=ext_LDAP_Provisioning)