scim-docs/content/overview/comparison.md

---
title: Why is SCIM better ?
description : Differences between several centralized user management protocols in a world of web application hosting that show **SCIM is an upgrade.**
color : green
weight : 4
---
### Others management protocols
{{< switch-box title="Ldap" >}}
With this LDAP approach <strong>everything is centralized</strong> (except authorization).

{{< imgproc "ldap-diagram.png" "LDAP diagram" "mr-t-1-5 mr-b-1-5">}}

<strong>Everything speaks the LDAP protocol langage.</strong> Identities are stored in an LDAP directory, which is provisioned via LDAP protocol. Authentication is done by the  application that asks the user’s credentials and validates them against the directory via LDAP protocol.
{{< /switch-box >}}

{{< switch-box title="Ldap+SSO" >}}
This architecture <strong>tackles the two main drawbacks of the only LDAP approach</strong> : the missing single sign-on and the security vulnerability. <strong>Authentication is delegated to other web protocols</strong> (like OAuth, OIDC or SAML). This way, the user logs in only once to the identity provider.

{{< imgproc "ldap-sso-diagram.png" "LDAP with SSO diagram" "mr-t-1-5 mr-b-1-5" >}}

{{< /switch-box >}}


{{< switch-box title="SSO" >}}
On modern web infrastructure, LDAP started to be abandoned because <strong>loose provisioning can also be done via SSO protocols.</strong>

{{< imgproc "sso-diagram.png" "SSO only diagram" "mr-t-1-5 mr-b-1-5" >}}

{{< /switch-box >}}

{{< switch-box title="SSO+SCIM" >}}
<strong>SCIM solve the remaining problems</strong> via a simple standard web api. This infrastructure is <strong>event driven, a provisioning action on the IdP is quickly passed on all applications.</strong>

{{< imgproc "sso-scim-diagram.png" "SSO with SCIM diagram" "mr-t-1-5 mr-b-1-5" >}}

{{< /switch-box >}}

| | LDAP | LDAP & SSO | SSO | SSO & SCIM |
| -------- | -------- | -------- | -------- | -------- |
| Easy to implement | {{< svg-render cross >}} <br> *Mature but old and difficult* | {{< svg-render cross >}} <br> *Mature but old and difficult* | {{< svg-render cross >}} {{< svg-render check >}} <br> *Simple and web native, but non-standard IdP* | {{< svg-render check >}} <br> *Cli or UI could be used on IdP or on apps* |
| Many implementations | {{< svg-render check  >}} | {{< svg-render check  >}} | {{< svg-render check  >}} | {{< svg-render cross >}} <br> *Not a lot of implementations yet* |
| Single sign-on | {{< svg-render cross >}} <br> *User must sign-on each application* | {{< svg-render check  >}} | {{< svg-render check  >}} | {{< svg-render check  >}} |
| No trust issues | {{< svg-render cross >}} <br> *Expose user’s credentials to each application* | {{< svg-render cross >}} | {{< svg-render check >}} <br> *Zero trust in applications* | {{< svg-render check >}} <br> *Zero trust in applications* |
| Scalable provisioning | {{< svg-render cross >}} <br> *By diffing, each app reads all and compares it* | {{< svg-render cross >}} <br> *By diffing, each app reads all and compares it* | {{< svg-render check >}} <br> *No diffing, modern storage, SQL database can be used* | {{< svg-render check >}} <br> *Real time atomic provisioning* |
| Scalable provisioning | {{< svg-render cross >}} <br> *Only when apps trigger it or when the user logs in* | {{< svg-render cross >}} <br> *Only when apps trigger it or when the user logs in* | {{< svg-render cross >}} <br> *No way to remove a user from the application* | {{< svg-render check  >}} |
| GDPR Compliant | {{< svg-render cross  >}} | {{< svg-render cross  >}} | {{< svg-render cross  >}} | {{< svg-render check  >}} |