What is the SCIM protocol (System for Cross-domain Identity Management)?
Automating identity management has become a top priority for any company that keeps adding business applications. This article covers the essentials of the SCIM protocol: what it is, how it works technically, the concrete benefits it brings to IT teams, and how it compares with other identity protocols such as SAML, SSO and LDAP. Thanks to a shared standard, companies can connect their various systems while keeping custom development to a minimum, even as the number of employees or applications grows.
SCIM, short for System for Cross-domain Identity Management, is a standardized protocol that automates identity management between an identity provider and an application. In practice, SCIM automatically creates, updates and deletes user accounts, with no manual work on each platform involved. It is an open standard published by the IETF. Its current version, SCIM 2.0, is described in RFCs 7642, 7643 and 7644, and its principle remains the same whatever the identity provider or target application.
SCIM's main strength lies in this standardization: instead of building a specific integration for each application, IT teams rely on a common protocol that is widely recognized and adopted across the industry. This lightens the workload for administrators and makes identity management more reliable across the whole company, from the day an employee is hired to the day they leave.
How does the SCIM protocol work?
SCIM is built on a simple principle: automating identity data exchanges between two systems that would otherwise have to be synchronized by hand, at a significant cost in time and effort for IT teams.
Exchanges between identity provider and application, throughout the lifecycle
In a SCIM architecture, the identity provider (IdP), meaning the company's directory or identity management solution, acts as the sender. It sends the target application the information needed to create or update a user account: name, email, group membership, activation status. The application, for its part, exposes an interface that can receive this information and apply it directly, so nobody has to enter the same data in two different places.
These exchanges cover the entire lifecycle of a user account: creation when someone joins, updates when they change role or work group, then deactivation when they leave. This is what allows a company to keep its internal directory consistent with all of its applications, including cloud-hosted ones, wherever the employees concerned are located.
The data format used
On the technical side, SCIM relies on a REST API and the JSON data format. The SCIM schema defines two main resource types: Users, for user accounts, and Groups, for the groups they belong to. Each resource follows a standardized schema, which ensures that any SCIM-compatible application understands the information it receives without extra processing. Create, read, update and delete operations rely on the standard HTTP methods (POST, GET, PUT, PATCH, DELETE) and apply directly to both resource types.
This common foundation (REST API, JSON, standardized schema) explains why SCIM has become a reference for identity provisioning: software vendors only need to implement the protocol once to become compatible with most identity providers on the market, whether their product is a SaaS service or a tool installed on premises.
What are the benefits of SCIM for IT management?
Beyond the technical side, the value of SCIM for an IT team shows up very concretely on several levels: speed, security and workload.
Automate account creation and deletion with SCIM provisioning
The first benefit of SCIM provisioning is the automated creation and deletion of user accounts. When a new employee joins the company, their access to the various applications is created automatically as soon as they are registered in the directory, without IT teams having to step in application by application. The same automation applies when a contract ends: deactivating the account in the IdP is automatically passed on to every tool involved, which greatly reduces the risk of leaving an active account behind after someone leaves.
Reduce errors and security risks
Entering user accounts manually in several different systems multiplies the risk of error: forgotten deactivations, inconsistent information across platforms, orphaned accounts that remain active when they should not. These orphaned accounts are a real security risk, since they are access points that escape administrators' control. By automating the synchronization of identity data, SCIM naturally cuts down on this type of error and strengthens control over the application landscape, however complex the information system.
Save time on access administration
For a company managing several hundred or even several thousand users, manual account management puts a heavy load on IT teams. SCIM frees up that time for higher-value work instead of repetitive account creation or update tasks. It also improves the user experience: employees get their access from day one, with no waiting time caused by manual processing. This is the case in GLPI, where the SCIM plugin automates provisioning for technician and end-user accounts, while authentication is handled separately, for example through the OAuth SSO plugin.
SCIM compared with other identity protocols
SCIM is often mentioned alongside other identity and access management protocols. It helps to clarify the role of each one, as they complement each other rather than compete.
SCIM vs SAML: what is the difference?
SAML is an authentication protocol: it lets a user prove their identity and access an application without entering their credentials again. SCIM does not handle authentication, but provisioning, meaning the creation and updating of the accounts themselves. In practice, the two protocols are often used together: SCIM prepares the user account, then SAML manages the login to the application.
SCIM vs SSO: what role does each play?
SSO (single sign-on) lets a user log in once to access several applications, without re-entering a password for each one. As with SAML, the link with SCIM is direct: SCIM makes sure the account exists and its information is up to date, then SSO handles the everyday login experience. A company that sets up SSO therefore has every reason to rely on SCIM as well to automate provisioning. In GLPI, the OAuth SSO plugin handles login (Google, Microsoft Entra ID, Okta, etc.), while the SCIM plugin manages the account lifecycle.
SCIM vs LDAP: what is the difference?
LDAP and SCIM do not address the same need: LDAP is used to query a directory and authenticate users, while SCIM is used only to provision accounts in applications. LDAP is still widely used to manage a corporate directory. SCIM, which is more recent, was designed to meet the needs of modern architectures, particularly when a company combines several cloud platforms and applications that do not share the same directory. Which one to use depends on the context: LDAP suits an information system centralized around a single domain, while SCIM offers more flexibility as the number of applications or products to connect grows, or when some of them are hosted outside the internal network. In many cases, both approaches coexist, for instance when a company moves its information system towards an integration with Microsoft Entra ID (formerly Azure Active Directory) while keeping an existing LDAP directory.
SCIM and open source: identity management without proprietary connectors
In an information system built around open source tools, a recurring challenge is connecting the various software components without piling up custom developments. This is precisely one of SCIM's strengths: because it relies on an open, widely adopted standard, it can link a directory or identity provider to an application without a proprietary connector or a purpose-built API.
For an IT department that wants to stay in control of its information system, this approach has a direct benefit. It avoids depending on a single vendor for access management, while relying on a protocol supported by most of today's identity providers and business applications. IT teams can evolve their application landscape, connect new products and services, or change identity provider without calling their whole identity management architecture into question. This principle matches the very philosophy of a tool like GLPI: relying on open standards rather than proprietary mechanisms, so the company keeps control of its information system. To learn more about what the tool offers day to day, all of its features are presented in detail on the website.
How to implement SCIM in your information system
Implementing SCIM follows a fairly similar logic from one system to another, even though the exact steps vary depending on the identity provider and the application involved.
Key deployment steps
- Configure the identity provider to expose the account and group data to be synchronized
- Enable SCIM provisioning support on the application side, usually through a dedicated authentication token
- Define the attributes to synchronize (identifiers, emails, groups, activation status) according to business needs
- Run a first test synchronization on a limited number of accounts to check that the data sent is consistent
- Set up continuous monitoring to make sure the synchronization process keeps working correctly over time
This setup can build on resources that are already documented. For a concrete example combining SCIM and authentication through a cloud identity provider, the SCIM provisioning tutorial with OAuth SSO and Azure AD details the technical steps to follow in that specific context.
Technical prerequisites and SCIM support
On the identity provider side, the directory must be SCIM-compatible, which is the case for most current cloud solutions, such as Microsoft Entra ID or Okta. An on-premises Active Directory does not support SCIM natively: it usually goes through Entra ID or a third-party tool. On the application side, a SCIM endpoint must be exposed, usually with documentation listing the supported attributes and the methods available for the Users and Groups resources. It is also recommended to check the integration's scalability limits beforehand, especially for companies with a large workforce or a high number of groups to synchronize.
SCIM in a nutshell
The SCIM protocol now plays a central role in corporate identity management. By automating user account provisioning, it reduces the effort needed to administer access and limits the risks tied to orphaned accounts. This page has covered the main technical and functional points of SCIM: its definition, how it works, its benefits, how it compares with SAML, SSO and LDAP, and the main steps to implement it. For a company that relies on open source tools, SCIM remains an accessible way to gain efficiency at every level of its information system, without giving up control over its identity data.
