SCIM and SAML get mentioned in the same breath and confused constantly, because both involve your identity provider and both are how it talks to your apps. But they do different jobs. SAML is about logging in. SCIM is about the account being there to log into.
Put simply: SAML proves who you are. SCIM makes sure you exist.
What each one does
SAML (Security Assertion Markup Language) is an authentication protocol. It is what powers single sign-on. When a user opens an app, the app hands off to the identity provider, the identity provider confirms who they are, and the user is let in without a separate password. SAML is the exchange that carries that assertion of identity.
SCIM (System for Cross-domain Identity Management) is a provisioning protocol. It is how the account itself gets created, updated, and deactivated in the app. Before anyone can log in, the account has to exist and carry the right attributes and group memberships. SCIM is what keeps that account in sync with the source of truth.
One handles the door. The other handles whether there is a room behind it.
Why you usually need both
Each alone leaves a gap.
With SAML but no SCIM, people can log in, but their accounts are not created or removed automatically. Someone joins and an admin makes the account by hand. Someone leaves and the account lingers, because turning off SAML stops future logins without deleting the account or catching any local login that skips SSO. Authentication is federated; provisioning is manual.
With SCIM but no 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 apps tend to ship SAML first.
Run both and the picture is complete: SAML federates authentication, SCIM keeps the accounts current. The trouble is that support is uneven. A great many apps offer SAML while gating SCIM behind a higher tier or not offering it at all. So companies end up with SSO everywhere and automated provisioning only where SCIM happens to be available and affordable.
The deprovisioning trap
The most expensive confusion is believing that disabling someone in the identity provider deprovisions them. It does not. It stops new SAML logins. The account in the app still exists, any local login still works, and any token they created still functions. This is how a company can be confident someone was offboarded while their access quietly remains. Real deprovisioning needs a provisioning path, SCIM or otherwise, reaching into each app, not just SAML being switched off at the front door.
OIDC, by the way, changes nothing here. OpenID Connect is a newer authentication protocol, an alternative to SAML built on OAuth 2.0. It sits on the authentication side of this comparison. SCIM remains the provisioning counterpart regardless of whether login runs on SAML or OIDC.
Related terms
- SCIM. The provisioning protocol in this comparison.
- SCIM provisioning. What SCIM actually automates.
- Deprovisioning. The removal step that SAML alone does not accomplish.
- Identity Governance and Administration (IGA). The governance layer above both protocols.