SCIM vs. LDAP: Key Differences + Which To Use

If you’ve been investigating protocols to handle user provisioning for your SaaS app recently, you might be forgiven for thinking SCIM and LDAP perform exactly the same function.

In reality, these two protocols are very different. While they can both be used as part of a wider Single Sign-On (SSO) implementation, they have different use cases, different strengths and very different implementations.

In this article, we’ll give you a quick overview of which protocol you should pick for your situation, then dive into the details of exactly what each protocol does, what you can use them for and how they can be used together.

SCIM vs LDAP: Which protocol should you use?

Both SCIM and LDAP are widely supported protocols, with open standards and battle-tested implementations which have endured years of testing.

Use SCIM if: You’re deploying a cloud-based SaaS app and want maximum simplicity, and maximum compatibility with identity provider platforms for provisioning users onto your app.

Use LDAP if: Your app will primarily be deployed on-prem/self-hosted and you want a smooth user provisioning process tied directly into your customer’s user directory. LDAP works best when you’re primarily serving customers in a legacy ecosystem or if using internal network resources is especially important to your app’s functionality.

For most use cases, SCIM is the correct provisioning choice.

Read more:

• What is SCIM provisioning?
• Directory Sync by WorkOS
• SAML vs. LDAP: How to Choose The Right Protocol‍
• Looking for an SSO Protocol? Read: What is SAML

What is SCIM?

An acronym meaning System for Cross-Domain Identity Management, SCIM is an open, RESTful standard which allows an identity provider platform (IdP) like Microsoft Entra, Okta or Google Workspace to provision and manage users on a 3rd-party service provider (e.g. your SaaS app).

SCIM allows your enterprise customers to maintain an access list to your app — choosing exactly which of their employees can access your platform and what they can do on it via SCIM groups assignments - without you having to take manual action or keep on top of provisioning requests.

The protocol is primarily used by enterprise IT admins to automate provisioning tasks on their end, either allowing them to provision users onto a new app in bulk, or set up automated systems to add specific employees to specific systems.

For example, their HRIS system (like Workday or BambooHR) might automatically provision new employees from the Customer Support department onto a cloud-based support system the company uses.

As an app developer, SCIM makes it easy for you to build a single provisioning endpoint into your app, and then open that up to lots of different enterprise customers with lots of different IdPs. More lucratively, it massively reduces the friction for those customers to then bring on end-users. That means more monthly-billable seats for you.

What SCIM is great at

• It’s simple and straightforward to implement: SCIM requires you to implement a minimum of two resources (/Users and /Groups). The associated objects are also self-explanatory, with only a few attributes you need to worry about. Best of all, it’s just a standard, HTTP-based API.
• It’s widely compatible: Perhaps as a result of that simplicity, SCIM is supported by every single IdP out there. Beyond IdPs, some of your customer’s other IT systems — like ServiceNow — are likely to support SCIM. That means less work for your customer and more paying users for your app.
• It excels at cross-domain provisioning: As the name suggests, SCIM’s speciality is making it easy for identity systems to provision users on cloud-based apps and services specifically. Unlike LDAP, SCIM is specifically built for the web, with a RESTful design and complete flexibility over your authorization methods.

What SCIM is not so great at

• It’s good at provisioning, and provisioning only: Unlike LDAP which can have broad information-transfer capabilities and handle SSO authentication via Kerberos, SCIM is only for provisioning users, deprovisioning users and keeping their identity data on your app synced with their employer’s IdP. SCIM cannot be used for actual authentication via SSO.
• Not every IdP follows the spec: While the SCIM standard is simple, open and, well, standardized - not every IdP sticks to this. Some will use different naming conventions for attributes or use attributes slightly differently from other vendors. However, the biggest deviation you’ll see amongst IdPs are in how they treat access groups and user suspensions, with potentially disastrous consequences if you don’t account for these differences in your SCIM endpoint.

What is LDAP?

Lightweight Directory Access Protocol — known as LDAP — is a protocol for accessing and maintaining directory services.

Specifically, LDAP connects to directories like Microsoft Entra ID (formerly known as Azure Active Directory) and allows apps to execute CRUD actions on those apps. In this user provisioning context, that would be creating a user, reading their details, updating those details or deleting that user’s details.

Unlike SCIM, LDAP systems come with built-in support for handling full SSO authentication via Kerberos, though this is rarely used. When the authentication capabilities are used, this is almost always for on-premise use cases, that use usernames and passwords for authentication, and requires tight integration with the directory service and LDAP client.

LDAP isn’t just limited to identity management — The protocol is commonly used for accessing information about networked devices (like printers), file shares or even information about business locations or departments within the business.

LDAP is TCP/IP-based but works best on private networks. Unlike SCIM  which is web-based and works well with your existing SaaS app, LDAP predates the web so it runs on a different port, and has different usage, security and performance characteristics.

Here’s how it works: An LDAP server, set up within a network, acts as a connection point for LDAP clients. When a client makes a request to the LDAP server, it relays that request to the directory service which returns the result, back to the client, again via the LDAP server.

What LDAP is great at

• It’s built for on-prem provisioning: If your customer plans to deploy your product inside their own network, LDAP is a natural choice for provisioning users. Your product can tie straight into their directory service, which is often an enterprise’s “golden source of truth” for user accounts.

• It goes beyond authentication data: While SCIM is purely focused on user provisioning and identity data, LDAP can be used to exchange a much wider variety of data. This can be a big advantage if your app needs to access secured resources and services on behalf of authenticated employees, or make use of physical devices on the corporate network.
• It’s vastly more mature than SCIM: Having been around over 3 decades, LDAP is much more battle-tested and proven than SCIM, albeit with the tradeoff that LDAP relies on the dated transfer protocol of TCP/IP, while SCIM is built on HTTP.
• It scales well in huge environments: LDAP is optimized for high read volumes so it’s well-suited to environments with a high query load. It also supports data replications across multiple servers which significantly enhances scalability and availability.

What LDAP is not so great at

• Cross-domain authentication and access: While LDAP's functionality isn't inherently limited across domains, Kerberos, which is often used to authenticate users against LDAP-based directories, doesn’t work well in cross-domain environments.It’s not browser-friendly, lacks token-based authentication and is usually associated with a single directory rather than supporting multiple different IdPs.
• It’s much more difficult to implement than SCIM: With its client-server architecture, TCP/IP protocol and close tie-in to directory services, LDAP is not a walk in the park to implement. Developers moving from LDAP to SCIM often find the newer, REST-based SCIM protocol to be a breath of fresh air.

Additionally, most LDAP environments don’t work well with the “public internet” so to really support LDAP, you usually need to have a way to deploy code into your customers' environment so that the code is in the same security/network zone as theirs.

What can you use SCIM and LDAP for?

Despite their differences, both of these protocols can be used for some similar purposes:

• User Provisioning: Both protocols allow user access credentials and access levels to be verified from a central source.
• Profile Data Exchange: Both protocols can allow users to log in once, and then access multiple different services or apps.
• Access Management: Both protocols can facilitate tight, granular access to secure systems or physical resources (like printers).

Both protocols can be used to execute each of these use cases. Developers who want to support these use cases primarily on-prem will use LDAP, whereas SCIM is favored by developers who want their apps to remain cloud-hosted — or just want an easier implementation.

Frequently asked questions about SAML and LDAP

Can you use SCIM and LDAP together?

For user provisioning specifically, these two protocols are directly competitive and would not be used together. However, in theory, a developer who needs cloud-based authentication and the ability to access directory data which is not identity related may use SCIM and LDAP together, but this is a very rare use case.

Which is better, SCIM or LDAP?

LDAP is a broad service and is not directly comparable to SCIM, but the user provisioning aspects can be compared. SCIM is easier to implement than LDAP and owing to its HTTP-based protocol, is more widely compatible for cloud applications. By contrast, LDAP is harder to implement and less suited for cloud-based user provisioning, but it is much more deeply integrated into the average enterprise customer’s estate.

Is SCIM the same as SSO? Can it be used for SSO?

Single Sign-On is the process of authenticating a user, and then allowing them automatic access to multiple services. While SCIM cannot handle an authentication flow, it is commonly used as part of a wider SSO solution. Specifically, SCIM is used by service providers and IdP to sync a database of users who are allowed to SSO into an app.

Read more: SCIM vs SAML: What Each Does and How To Use Them Together?

Next steps

Prefer a done-for-you approach and don’t want to spend days configuring your app to use SCIM or wondering if you should’ve used LDAP instead?

Directory Sync by WorkOS allows you to quickly enable SCIM provisioning from all major corporate identity providers with a straightforward, API-based integration.

• Get started fast: With SDKs for every popular platform, and Slack-based support, you can implement Directory Sync in minutes rather than weeks.
• Avoid the back-and-forth: WorkOS’s Admin Portal takes the pain out of onboarding your customers’ IT teams and configuring your app to work with each of your customer’s identity provider.
• Events-based processing: While webhooks are also supported, WorkOS’ events API means every SCIM request is processed in order, and in real-time. You’ll never miss a provisioning request again.
• Pricing that makes sense: Unlike competitors who price by monthly active users, WorkOS charges a flat rate for each company you onboard - whether they’re syncing 10 or 10,000 users with your app.

Explore Directory Sync by WorkOS.