SCIM and SAML get mentioned in the same breath and confused constantly, because both involve the identity provider and both are how it talks to applications. They do different jobs, and the difference matters most at offboarding time. SAML is about logging in. SCIM is about the account being there to log into. SAML proves who a person is; SCIM makes sure their account exists and is current.
SAML (authentication) SCIM (provisioning)
"who are you?" "does your account exist, and is it current?"
----------------------------------------- -------------------------------------------
user opens the app identity provider creates the account
app hands off to the identity provider updates attributes and groups as they change
IdP confirms identity, user is let in deactivates the account when the person leaves
disable a user in the IdP: SAML logins stop | the account, local logins and tokens remain,
| unless SCIM (or another path) removes themWhat does each protocol do?
| SAML | SCIM | |
|---|---|---|
| Full name | Security Assertion Markup Language | System for Cross-domain Identity Management |
| Job | Authentication: proving who the user is at login | Provisioning: creating, updating and deactivating the account |
| Standard body | OASIS, SAML 2.0 (2005) | IETF, RFC 7643 and 7644 (2015) |
| Runs when | A person opens the application and is redirected to the identity provider | The directory changes: a hire, a move, a departure |
| Direction | Browser-mediated exchange between application and identity provider | The identity provider calls the application's API |
| Data carried | A signed assertion: this is the user, here are their attributes | Users and groups: names, emails, active flag, memberships |
| What it produces | A logged-in session | An account that exists, with the right attributes, or does not |
| Modern alternative | OpenID Connect, on OAuth 2.0 | None; SCIM is the provisioning standard |
SAML
SAML is an authentication protocol and the one that powers most single sign-on. When a user opens an application, the application hands off to the identity provider. The identity provider confirms who they are and returns a signed assertion, and the user is let in without a separate password. SAML is the exchange that carries that assertion of identity. A developer who worked through the protocol described the gap that surprised him:
SAML is just an authentication protocol, it doesn't really handle user provisioning. Which was confusing to me, because any time you'd use it you typically also need some kind of provisioning mechanism.
SCIM
SCIM is a provisioning protocol. It is how the account itself gets created, updated and deactivated in the application. Before anyone can log in the account has to exist and carry the right attributes and group memberships, and SCIM is what keeps that account in sync with the source of truth. One protocol handles the door, and the other handles whether there is a room behind it.
Why do you usually need both?
Each protocol on its own leaves a gap that the other was built to fill.
| Setup | Login | Account creation | Account removal | Where it leaves gaps |
|---|---|---|---|---|
| SAML only | Federated | Manual, or JIT on first login | Manual | Accounts linger after departure; local passwords keep working |
| SCIM only | Local password or another method | Automatic | Automatic | No single sign-on; rare in practice |
| SAML and SCIM | Federated | Automatic | Automatic | Only where the application gates or lacks one of the two |
SAML without SCIM
People can log in, but their accounts are not created or removed automatically. Someone joins and an administrator makes the account by hand, or the application creates it on first login. Someone leaves and the account lingers, because turning off SAML stops future logins without deleting the account or catching a local login that skips SSO. Authentication is federated while provisioning stays entirely manual.
SCIM without SAML
Accounts stay in sync but there is no single sign-on, so login is handled some other way. This is the rarer case, since applications tend to ship SAML first.
Both
Run both and the picture is complete, with SAML federating authentication and SCIM keeping the accounts current. The trouble is that support is uneven. A great many applications offer SAML while gating SCIM behind a higher tier or not offering it at all. Companies end up with SSO everywhere and automated provisioning only where SCIM happens to be available and affordable.
Does disabling SAML deprovision a user?
No, and this is the most expensive confusion in the pair.
What disabling SSO actually stops
It stops new SAML logins, and nothing else. The account in the application still exists, any local password still works, any token the person issued still functions, and existing sessions stay valid until they expire on the application's own schedule. That is how a company can be certain someone was offboarded while their access quietly remains.
The three ways access survives
A local login that was created before SSO arrived, or allowed as a fallback for when SSO breaks, and which no directory change touches. A personal access token or API key the person generated inside the application, which authenticates without the identity provider at all. And a live session, held open in a browser tab or a mobile app, which nothing revokes until the application decides to.
SAML gives you "Bob can't log into the CRM ever again", SCIM gives you "... and his CRM user and sessions are immediately revoked".
The session point is the one most often missed. Another commenter in the same thread spelled out why it is a compliance matter and not a technicality:
Enterprises are forced by their customers and regulators to show that terminated employees lose access immediately. There are two ways to make that happen: force everything to flow through a VPN, and SCIM.
Real deprovisioning needs a provisioning path, SCIM or otherwise, reaching into each application, rather than SAML being switched off at the front door.
Where does OIDC fit in?
OIDC, which often replaces SAML in newer stacks, changes nothing about this comparison.
It sits on the authentication side
OpenID Connect is a newer authentication protocol built on OAuth 2.0. It answers the same question SAML answers, in JSON rather than XML and with better support in mobile and single-page applications, and it says nothing about whether an account exists. SCIM remains the provisioning counterpart whether the login runs on SAML or on OIDC.
One product limitation worth knowing
Some identity providers attach SCIM only to applications configured with SAML, not to the same application configured with OIDC, so choosing the newer login protocol can cost the provisioning connection. That is a limitation of the product rather than a property of either protocol, and it is worth checking before a migration rather than after.
Iden takes SSO as given and covers what SAML leaves open. It creates and deactivates the account inside each application, over SCIM where the application offers it and over the application's API or a custom connector where it does not, so that disabling a person in the identity provider also closes the accounts behind the front door. The connector catalogue shows which path each application uses. The feature behind it is Day one access, without a ticket.
200+ connectors. SCIM where the app has it, an API where it does not, and a custom connector where neither exists.