SCIM vs SAML: What They Do and How They Differ

SCIM vs SAML is a common point of confusion in identity security. Here’s what each one does, how they differ from one another, and where they land in the context of an IGA program.

SAML vs SCIM: The Core Difference

SAML and SCIM are two different protocols that are used in the routine authorization, management, and governance of identities. In a nutshell, SAML governs how an application understands that a user is who they say are, and the process by which they authenticate and get access to a session. SCIM is a protocol often used in the act of governing whether an account, and the groups and attributes attached to it, actually exists and match what the source of truth says it should.

What is SAML?

SAML (Security Assertion Markup Language) is an authentication and federation standard maintained by OASIS. It defines XML-encoded assertions describing authentication, attribute, and authorization information, plus the protocol messages that carry those assertions between systems. SAML is not directly involved in the identity governance lifecycle, but rather focuses on the action of allowing users to reach applications they should be able to.

What does SAML allow?

SAML allows an identity provider (IdP), the system that authenticates the user, to vouch for that user in a standardized, signed assertion, and a service provider (SP), the application the user is trying to reach, accepts that assertion as the proof of the user’s identity. Another way of thinking about it is that SAML is the bridge between the identity provider and the service provider, ensuring that applications can trust a login without ever handling the user’s credentials themselves.

What’s a practical example of SAML?

For example, let’s imagine that an employee at a bank tries to access an HR solution (the service provider) and is redirected to an SSO screen (the identity provider), where they authenticate using their password and an authenticator app. Behind the scenes, once the user has authenticated themselves, the identity provider returns a signed SAML assertion stating who the employee is and which attributes travel with the login, such as their department and employee ID. The HR solution then trusts the SAML signature and opens a session on that basis.

A signed assertion proves a session is real at the moment it’s issued. However, it’s important to recognize that a signed assertion alone says nothing about the account behind that session, the groups it belongs to, the entitlements it carries, or whether any of that still deserves to exist a week, a month, or a year later. It can simply be thought of as the key that is used to unlock the single-sign-on gate based on user identity at that point in time.

What is SCIM?

SCIM (System for Cross-domain Identity Management) is an open IETF standard for account and group provisioning, built on top of REST. It acts as a stable, reliable framework commonly used by IAM and IGA applications to connect to applications and leverage a common schema to create, read, update and delete users, groups, endpoints, and standard identity lifecycle operations.

What does SCIM allow?

In practice, SCIM is a standard that allows a system, such as an IGA platform, to create, update, and remove data on accounts and group memberships in a target application without a bespoke integration per system.

Where SAML answers “is this session real?”, SCIM allows applications to ask and answer “does this account, and its group memberships, exist and match what it’s supposed to be right now?”.

What’s a practical example of SCIM?

Let’s imagine a company hired a new salesperson for their EMEA region. When the new hire’s start date arrives, the HR system marks them as active, and that event triggers the IGA platform.

First, the IGA platform reads the HR record and evaluates it against governance policy: does this person’s role, location, and department entitle them to a CRM account and membership in the “Sales-EMEA” group? Are there any separation-of-duties conflicts? Do any approvals need to fire?

Once that evaluation passes, the IGA platform issues a SCIM request to the CRM, which creates the account and assigns the group membership. The target system updates only after governance has signed off. Six months later, the salesperson moves laterally within the organization and that initial group membership becomes obsolete. The same sequence runs again: the HR record changes, the IGA solution detects the lifecycle event, re-evaluates entitlements against current policy, and issues a follow-up SCIM call that removes the old group assignment and applies the new one.

SCIM’s job, in this example, is enable the IGA solution to keep the CRM record in sync with the HR source of truth across the entire identity lifecycle. That maintained connection is what prevents access rights from drifting over time or stacking on top of each other. SAML’s job is to act as a key and ensure a user can access what they should be able to access.

It is worth noting that many IdPs can issue a SCIM request natively (i.e. creating an account), but they cannot check whether either group membership creates a separation-of-duties conflict, apply an approval workflow before the change lands, notice if the transfer never gets logged anywhere else, or catch it if the HR record itself turns out to be wrong.

In a proper IGA deployment, those checks happen before the SCIM call goes out. The IGA platform evaluates governance policy first, and then drives the protocol. SCIM is, therefore, used to move access data, but identity governance decides whether the data should move at all.

What’s the difference between SCIM, OData and REST?

One point of confusion that sometimes surfaces is the difference between SCIM, OData, and REST. REST (Representational State Transfer) is not a protocol in the strict sense but rather a framework for building web APIs which defines a set of conventions for using standard HTTP methods (GET, POST, PUT, DELETE) to create, read, update, and delete resources.

OData (Open Data Protocol) is a broader, general-purpose standard built on REST that enables users to easily query or filter data using a defined protocol. This is often used to facilitate integrations between various applications across many domains, and is also often leveraged in identity security. However, OData is not intended or built to work with identity and access data in the way that SCIM is.

In a nutshell, the main differentiation is that OData and SCIM are protocols that establish standards, both are built on top of REST, but SCIM is specifically designed to work with data related to identity security while OData can be applied to a larger variety of business applications or integrations outside of identity security.

What Identity Governance Adds

Identity Governance and Administration (IGA) is the discipline of deciding, documenting, and continuously verifying who should have access to what, and why. It covers the full identity lifecycle, including onboarding, job changes, and offboarding, plus the certification, Separation of Duties (SoD), reconciliation and compliance reporting work that keeps that access honest over time.

An IGA platform can use SCIM, OData, REST, or other protocols to effectively govern identities across applications. The benefits of using an IGA platform to govern and manage identities are extensive.

Contextualized Governance

First, IGA decides what sort of access should exist, and why. A role and policy engine (RoPE) evaluates who should have access based on rules, such as job function, department, project, or regulatory requirement, not just whatever the last provisioning request happened to say. This is particularly important when all of these systems are prone to change, as is the case in complex enterprise environments.

Seamless Adaptability

Second, IGA executes that decision through whatever mechanism is available, adapting to whatever connection exists between existing systems. This can refer to a two-way connection that can both read and write (using a protocol like SCIM), a one-way connection for systems that will hand over data but won’t accept anything back, or a manual process, such as a CSV import or a logged provisioning task, for systems with no usable API at all. All three count the same way to the platform.

The IGA platform’s job is making sure the instruction was correct, regardless of how it was sent or received. Omada leverages flexible connectors within its Configurable Connectivity Framework, with additional support for many other protocols, frameworks, and flexible connectors, enabling seamless connectivity across even the most complex enterprise systems.

Continuous Reconciliation

Third, IGA continuously reconciles what’s actually there against what should be there, regardless of how it got there. An account created by SCIM, a script, or by an admin who happens to work around both, gets evaluated the same way, on every import cycle, not just during a periodic audit.

Comprehensive Coverage

Fourth, IGA is able to evaluate complex enterprise environments. SoD conflicts get flagged and routed to a manager for a documented decision rather than being silently allowed or blocked, and access sits in a queue, allowing for periodic recertification. This includes the manager or resource owner having to actively confirm that a user still needs what they hold rather than having that access persist by default.

Where SCIM and SAML Stop

SAML can start or end a session, and SCIM can activate or deactivate an account inside whichever applications are wired up to receive that instruction. Neither one reaches API keys the identity generated while active, group memberships in systems that were never connected via SCIM, entitlements entered manually because a target system has no usable API, or accounts an admin created outside the automated path. None of that is a flaw in either standard, but rather a scope boundary. Unfortunately, this boundary is exactly where potential governance failures live.

Where Identity Governance Picks Up

An IGA platform authenticates through whichever IdP a customer already runs, and puts its own effort into the governance layer above it. It evaluates a group membership the same way regardless of whether it arrived through SCIM, a custom REST connector, or a manually logged approval, and its SoD checks run across connected systems. An unmeasured, often lengthy gap between access and discovery is the outcome these gaps produce when nothing reconciles what an identity should hold against what it actually holds, no matter which protocol moved the data.

Ready to close the gap between what your protocols report and what your identities actually hold? Schedule a demo to see how Omada Identity Cloud can seamlessly connect to and manage identities within complex enterprise environments.