SAML and SCIM: What Enterprise Buyers Actually Expect

SAML, or OIDC, handles authentication: proving that the person logging in is who the customer's identity provider says they are, at the moment they log in. SCIM handles provisioning: creating, updating, and removing accounts in your system as people join, move teams, or leave, driven by changes in the customer's own directory rather than by anyone logging in at all.

A customer can have SAML working perfectly and still have accounts in your system for people who left the company months ago, because nothing about a login flow ever tells you someone should be removed.

The two protocols solve genuinely different problems, which is why a buyer asks about them separately rather than treating one as a substitute for the other.

Without SCIM, an offboarded employee at the customer keeps whatever access they had in your system until someone at the customer, or on your side, remembers to remove it manually. Enterprise buyers ask about this directly, often as a named question about automated deprovisioning, not a general question about access control.

This is also the gap most likely to show up in an actual incident, not just a questionnaire: a departed employee's credentials are a real, ongoing access risk for however long the manual removal takes.

Hand-rolling SAML assertion parsing is a well-documented source of authentication bypass bugs, since the protocol has enough edge cases in signature validation and assertion handling that small mistakes turn into real vulnerabilities. Most teams are better served by an identity middleware layer that already handles those protocol details, reserving engineering time for the mapping logic specific to your app: which SAML or SCIM attributes map to which roles, teams, or custom fields.

That mapping layer is where your actual product knowledge lives, and it's the part a generic library can't do for you no matter how good the underlying protocol handling is.

Test deprovisioning end to end, not just provisioning: remove a user from the customer's directory and confirm they actually lose access in your system, not just that a webhook fired. Test attribute mapping when the customer's directory doesn't match your schema cleanly, since real customer directories are messier than your test tenant.

Test what happens to an active session when the identity provider forces a logout, too. A user who's been removed from the directory but keeps a live session in your app because nothing checks that mid-session is still exposed, even with SAML and SCIM both technically wired up.

Cover these checks before calling SSO done:

• Remove a user from the customer's directory and confirm they actually lose access in your system, not only that a webhook fired.
• Test attribute mapping against a directory that doesn't match your schema cleanly, since real customer directories are messier than your test tenant.
• Check what happens to a user's active session at the moment they are deprovisioned in the customer's directory.
• Verify a fallback exists for missing or unexpected attributes, such as a default role for a new SCIM user.

SAML alone gets a customer's users logged in, and it's tempting to treat that as the whole enterprise SSO requirement. Buyers increasingly ask for both in the same security questionnaire, and SAML-only leaves exactly the deprovisioning gap described above open, unresolved by anything the login flow does.

If SCIM isn't built yet, say so plainly rather than answering the questionnaire as though SAML alone covers it. A clear roadmap answer holds up better under a follow-up question than an answer that turns out to overstate what's actually built.

Real customer directories rarely line up cleanly with the roles and fields your app expects. One customer's directory might have a department attribute your app has never seen, while another omits an attribute your mapping logic assumes is always present.

Build a fallback for missing or unexpected attributes into the mapping layer itself, such as a default role a new SCIM user gets when the incoming attributes don't map cleanly, rather than letting an unmapped attribute silently fail the provisioning call or, worse, grant broader access than intended by default.