SAML and SCIM solve different problems. SAML lets an identity provider tell your application who a user is at login. SCIM, defined in RFC 7643 and RFC 7644, lets that provider create, update and deactivate user accounts in your application over an API. SAML handles the door, SCIM handles the guest list.
What does SAML do?
The SAML 2.0 technical overview from OASIS describes assertions: XML statements an identity provider issues about a user, covering authentication, attributes and authorization decisions. In the common web browser profile, the user visits your app, is redirected to the identity provider, signs in there, and returns with a signed assertion your app trusts.
Result: one login, central password and multi-factor policy, and no password stored in your app. What SAML does not do is tell your app that a person exists before they sign in, or that they left yesterday.
What does SCIM do?
SCIM standardizes provisioning. RFC 7643 defines the core schema for users and groups, and RFC 7644 defines the HTTP protocol for creating, reading, replacing, patching and deleting those resources, plus search, filtering and bulk operations. The identity provider acts as the client and your application exposes a SCIM endpoint.
With it, hiring someone in the directory creates their account, moving them between groups changes their role, and removing them deactivates the account without an administrator touching your app.
Where do they overlap?
Both carry identity attributes: email, name, group membership. Both are driven by the customer's identity provider. A SAML assertion can carry attributes and even create an account on first login, called just-in-time provisioning. That overlap makes SCIM look optional, which is the common mistake.
Why is SAML alone not enough?
Take a constructed example. A customer with 400 seats uses SAML only. An engineer leaves and is disabled in the directory. They can no longer sign in through SSO. But their account in your app still exists, any API tokens or sessions they hold may still work, and the account still occupies a seat and shows in audits. With SCIM, deactivation arrives as an API call, and you can revoke sessions and tokens on receipt.
Group-based roles show the same gap. Under SAML alone, role changes apply only when the user next logs in.
When do you need each?
- SAML only: a small customer base, few users per tenant, and low data sensitivity.
- SAML plus SCIM: enterprise customers, regulated data, or any buyer whose questionnaire asks about automated deprovisioning.
- SCIM only: rare. Provisioning without federated login leaves password management in your hands.
An alternative to SAML is OpenID Connect, which many providers also support. It sits in the same slot as SAML and pairs with SCIM the same way.
What should you build first?
Build SSO first, because it is the first thing buyers ask for. Design your user model for SCIM from the start: a stable external ID, an active flag that disables rather than deletes, and group mapping to roles. Retrofitting those later is painful.
How to check or apply this
- Confirm your login flow accepts signed SAML assertions and validates signature, audience and expiry.
- Add a stable external identifier to your user model.
- Implement an active flag and revoke sessions and API tokens when it flips.
- Expose a SCIM endpoint for users and groups following RFC 7644.
- Test deprovisioning end to end against a real identity provider.
- Log provisioning events for customer audits.
Quick check
Is SCIM a replacement for SAML?
No. SAML authenticates a login. SCIM manages account lifecycle. They complement each other.
Does disabling a user in SSO remove their API access?
Not on its own. Tokens and sessions issued earlier need explicit revocation, which SCIM deactivation can trigger.
Sources
Last reviewed: 18 October 2026.
