SCIM vs LDAP: one pushes accounts, the other answers directory queries

SCIM and LDAP both deal with users and groups, so they get compared. They solve different problems, and replacing one with the other usually ends badly.

Short answer: SCIM is a REST and JSON standard for provisioning accounts and groups into applications: create, update, deactivate and delete. LDAP is a directory protocol for authentication and lookup: an application binds as a user and searches the directory. SCIM pushes changes to apps; LDAP lets apps query a directory. Most organizations run both.

What SCIM is

SCIM stands for System for Cross-domain Identity Management. RFC 7643 defines the User and Group schema, and RFC 7644 defines the protocol: HTTP methods, JSON payloads, filtering, pagination and bulk operations.

A SCIM service provider exposes endpoints such as /Users and /Groups. An identity provider or HR system calls them to create a user, update an attribute, move the user between groups, or set active to false when someone leaves.

SCIM does not authenticate the end user. It is an administrative API. The value is lifecycle: when a user is created, renamed, moved or terminated in the source system, the change reaches the application without a human clicking through an admin console.

What LDAP is

LDAP is a binary directory protocol defined in RFC 4510 and RFC 4511. A directory stores entries in a tree, each identified by a distinguished name (DN). Clients use operations such as bind, search, compare, add, modify and delete.

LDAP's core authentication operation is the bind: the client sends a DN and a password, and the server accepts or rejects it. Applications also use LDAP to search for users, groups and attributes, which is why VPNs, Wi-Fi controllers, mail servers, printers and older internal apps speak it.

SCIM vs LDAP at a glance

The common architecture

A typical enterprise stack looks like this:

1. HR system is the source of truth for joiners, movers and leavers.
2. Identity provider imports from HR, authenticates users, and holds groups and roles.
3. SCIM pushes those users and groups into SaaS applications such as Slack, Zoom, Atlassian or GitHub.
4. LDAP serves the applications that cannot speak SCIM: VPN concentrators, Wi-Fi controllers, printers, NAS devices and legacy Java applications.
5. SAML or OIDC handles the interactive login for applications that support browser SSO.

The identity provider sits in the middle. It receives changes from HR, provisions downstream apps over SCIM, and exposes LDAP to the systems that need a directory. SSO is a separate channel: SCIM creates the account, SAML or OIDC signs the user in.

When to use SCIM

• A SaaS application supports SCIM and you need automated onboarding and offboarding.
• You want group membership to drive application roles.
• You need deprovisioning to take effect quickly when someone leaves.
• You have multiple applications and manual account creation no longer scales.

SCIM is the right tool when the application offers a SCIM endpoint and your identity provider can act as the SCIM client.

When to use LDAP

• The application only supports LDAP for authentication or directory lookup.
• You need a queryable directory for network gear, VPNs or legacy software.
• You are consolidating multiple local user stores into one directory.
• You need group lookups for file shares, mail routing or POSIX accounts.

LDAP is the right tool when the client speaks LDAP and there is no SCIM or OIDC option.

Do you need both?

Often, yes. SCIM does not replace LDAP because most network devices and legacy applications do not speak SCIM. LDAP does not replace SCIM because it has no standard lifecycle API for SaaS provisioning, and exposing a directory to the internet for every SaaS vendor is worse than giving each vendor a scoped SCIM token.

The clean design is one identity provider with:

• SCIM outbound to modern SaaS.
• LDAP inbound from legacy applications.
• SAML or OIDC for browser SSO.
• A single user and group model behind all three.

Security notes

• SCIM tokens are credentials. Use HTTPS, scope the token to the tenant, rotate it, and log every write.
• LDAP simple bind sends a password. Use LDAPS or StartTLS, and never expose LDAP directly to the internet.
• Use a read-only service account for lookups. Applications that only search should not have write access to the directory.
• Deprovisioning is the test that matters. Create a test user, disable them in the source, and confirm that SCIM and LDAP access both stop.

How Casdoor fits

Casdoor can act as a SCIM service provider, exposing /Users and /Groups so external systems can create, read, update and delete users and groups. It also has a SCIM 2.0 syncer that pulls users from an external SCIM server into Casdoor (read-only), and it can serve LDAP to applications that need a directory. That lets one identity provider cover SCIM provisioning, LDAP lookups and SAML or OIDC sign-in.

Casdoor is open source and self-hostable; Casdoor Cloud starts at $9 per month for a dedicated instance with no per-user fees.

Related reading: what SCIM is, SCIM vs SAML, SCIM vs JIT provisioning and LDAP vs Active Directory.