SCIM vs SAML: What each does and how to use them together

SCIM and SAML aren’t competing protocols. Instead, they help developers implement a full, enterprise-grade authentication solution and manage a user account's full life cycle (create/update/delete). Each protocol handles different parts of the full solution.

In this article, we will cover:

• How do SCIM vs SAML compare, and what role each play
• How you can use them together
• What security considerations you’ll need to bear in mind
• What you need to get started on implementing each

What is SCIM?

SCIM, or System for Cross-Domain Identity Management, is an open standard designed to simplify how organizations manage user access across various apps and services. By enabling automated user provisioning and deprovisioning, SCIM helps identity providers (like Okta, Microsoft Entra ID, or OneLogin) communicate user data to service providers (such as your SaaS app) with minimal manual intervention.

While SCIM implementations vary slightly between providers, you can always expect the basics to stay the same:

• SCIM is a RESTful protocol tailored for identity and access management. It leverages REST principles to synchronize user data efficiently.
• Individual pieces of SCIM user data are referred to as attributes and are stored as name/value pairs in a JSON object, again similar to any other REST API.
• SCIM exposes two main resources: some text
  • Users: Used to store identity and profile information about each user
  • Groups: Used to define the particular access group(s) a user belongs to and which authorization level they grant.

How SCIM works

When a user is provisioned onto an app (created or added), the identity provider exchanges key attributes such as the user’s name, a stable unique identifier, and their email address. This identifier must remain unchanged throughout the user’s lifetime. Similar data is exchanged during updates or deprovisioning (removal).

What’s great about SCIM is that it’s proactive. Unlike Just-In-Time (JIT) provisioning, which only creates accounts during login, SCIM handles everything ahead of time. It’s perfect for IT teams managing many users — they can bulk-provision people or automatically onboard and offboard employees.

For startups, SCIM is a feature that can help you land bigger clients and grow your revenue since you’ll be reducing the administration overheads for your prospective customers’ IT team and making it smooth and easy to onboard hundreds or thousands of users to your app at once.

Read more about SCIM:

• What is SCIM Provisioning
• SCIM vs. LDAP: Key differences + Which to use
• The Top 3 SCIM Providers for 2024

What is SAML?

Security Assertion Markup Language(SAML) is an XML-based standard for exchanging authentication and authorization data at login.

While SCIM focuses on keeping the service provider and identity provider in sync about which users can access the service and their permissions, SAML concentrates on the SSO login process.

How SAML works

When a user tries to access an app, the app (service provider) redirects them to the identity provider (IdP) for authentication. The user logs in to the IdP, which verifies their credentials and generates a SAML assertion — a structured XML document containing:

• User details (e.g., name, email).
• Authentication details (e.g., time of login, method of authentication).
• A digital signature is needed to ensure the assertion's integrity and prevent tampering.

The IdP then sends the SAML assertion back to the app. The app validates the assertion, and if it's valid, it creates a session for the user, granting them access.

The main goal of SAML is to provide a secure, standardized way to authenticate users across services, especially in web-based SSO scenarios. With over 20 years of adoption, SAML has become a widely supported standard, integrated by nearly every identity provider and SSO solution. It is primarily useful when your enterprise customers want their employees to log in once and then access multiple services or apps.

SCIM vs SAML: Do you need both?

SAML and SCIM are not competing standards; they serve different purposes and are often used together to create an enterprise-ready authentication and provisioning setup.

SAML will typically be implemented to handle everything that happens at the time of login. In other words, SAML handles the app's primary authentication duties. It’s specifically designed for SSO. 

Some of your customers might implement SAML provisioning, using assertions to send authorization data. Others might use JIT provisioning combined with SAML to allow on-the-fly provisioning at login. These two approaches, however, lack real-time syncing for ongoing changes like access revocation. SCIM is an excellent choice for keeping your app in sync at all times with your customer’s directory provider. 

Unlike SAML, SCIM does not support authentication or SSO. Instead, SCIM complements your SAML implementation by ensuring your app always has correct and up-to-date information for each user your customer wants to use your platform. In addition, once a SAML-brokered login has taken place, your SCIM implementation ensures you have up-to-date information on when a user is added and, most importantly, when they are removed.

Challenges of only implementing SAML

SAML, by itself, usually isn’t enough for secure provisioning. This is why, if you’re already familiar with SAML, you might know that the previous sections aren’t the whole truth. 

SAML can leverage a concept called “SSO Profiles,” whereby attributes like a user’s email, name, or even profile picture URL are stored on your customer’s identity provider and then passed to your app as part of the SAML assertion.

In theory, this cuts out the core need for SCIM. But there’s a reason SCIM is still the industry standard for storing and syncing user information.

Security risks of outdated sessions

Since SAML assertions are only passed to your app during login events, a user can log in and then subsequently have their authorizations revoked by their IT admin. Your app won’t know this because the latest session available is only from the user’s most recent login. This session can easily be hours or even days out of date.

This can have all kinds of security implications. For example, your customer might need to urgently remove a compromised user account from a system. While they can revoke this access at their identity provider level, this user would still have access to sensitive data or actions for the duration of their session.

How SCIM solves real-time provisioning

SCIM solves this by reflecting changes as quickly as the identity provider syncs updates to service providers.

This means that whenever a user requests access to a resource or takes action during a session, you can have reliable, up-to-date authorization data available in your database to decide whether access should be granted. For example, once you receive a deprovisioning event, you can immediately end a user’s active session.

With SAML, users end up in your app “out of nowhere” in an IdP-initiated flow, or you redirect the user to the IdP in a "SP-initiated" flow, which is different from SCIM, which you can think of as a special class of webhook (or event streaming) — you receive updates the moment they’re available in your customer’s IdP.

SCIM vs SAML: Which is right for you? 

While you may want to stick to SAML for simplicity’s sake, the choice isn’t always yours.

Suppose your prospective customer’s IT team is already heavily invested in using a SCIM-powered directory solution to manage access across their estate. In that case, they’ll likely mandate that you support SCIM in working with them. Otherwise, they might just go with a SCIM-equipped competitor instead. 

Challenges of building SCIM and SAML from scratch

Being open standards, both SAML and SCIM can be implemented manually. Beyond the apparent hurdles of taking the time to implement, test, and secure your own auth stack with SAML and SCIM, there are a few lesser-known headaches you’re likely to run into.

Implementations can vary across every supplier

While both SCIM and SAML are open, mature, and well-defined standards, individual identity providers often use attributes in slightly different ways from each other, treat suspended users differently, or rely heavily on custom attributes which you’ll need to build a similar custom implementation for.

SAML isn’t a nice, easy REST API

While SCIM is RESTful, SAML is an XML-based protocol, with its latest version (SAML 2.0) finalized in 2005, making it a mature standard for authentication and authorization.

First, you have to deal with XML, which is hard to form, read, and write due to its strict syntax and rambling nature. This, combined with the detailed and comprehensive nature of the SAML specification, with its numerous protocols, bindings, and need for digital signatures, significantly contributes to a steep learning curve.

You’ll also need to properly validate and process the SAML responses from your customers' IdPs, check that the response is actually intended for your app, and validate every signature, including the entire SAML response and every assertion. Otherwise, you risk a huge security breach.

Webhooks aren’t enough

Using webhooks to receive SCIM provisioning updates sounds ideal, but webhooks can be unreliable in practice. They may arrive out-of-sequence, delayed, or even fail to arrive. 

While this is a problem for any feature, it’s a particularly dangerous issue with SCIM. For example, you could miss a deprovisioning request from a customer’s IdP, your system won’t realize it, and neither will theirs without manual intervention. And unlike with SAML assertions, a re-log won’t fix it! 

Another issue with webhooks is that they operate on a “fire and forget” basis—once they are sent, the sender doesn’t care how you process them on your end.

Webhooks are also highly variable between different IdPs. Each IdP might send data in different formats or trigger webhooks for different SCIM events, making it quite difficult to create a unified syncing process that works for all your customer’s providers.

Support is hard to come by

Being completely open and decentralized standards, there is no particular person or organization you can call when you run into issues with SCIM and SAML. Like with any open technology, there is always a helpful stranger on a forum somewhere who might reply this week, but that won’t be much consolation when your SSO is down. Your startup is rapidly breaching its SLA agreement with your customers.

Onboarding customers is a painful process

Implementing both protocols requires a fair amount of configuring between you and every client you bring on. You’ll need to map all of their attributes to the user model in your database, deal with x.509 certificates and OAuth, and share configuration details from both sides.

You'll need to keep up with emerging standards

Your customers will be asking you to implement new standards as they arrive. Things like cursor-based pagination for SCIM, signal-sharing APIs like CAEP and RISC, and the FastFed configuration standard are on the horizon.

Benefits of buying a dedicated provider

If the above section isn’t exactly your idea of fun, you’ll be glad to hear that various providers like WorkOS can give you SAML and SCIM support out of the box.

Here are some of the reasons you’ll want to buy rather than build your SCIM and SAML integration:

Support for any vendor out of the box

The core value any all-in-one solution provides is to support all of the major corporate IdPs and directory providers — like Okta, Microsoft Entra, Google Workspace, and more — out of the box.

Some providers like WorkOS support HRIS systems, such as Workday, Rippling, and BambooHR.

Normalized attributes

Often, auth-as-a-service providers automatically normalize attributes and naming conventions in the background before providing a single, unified data model you can work with. This often extends beyond just SAML and SCIM—the same implementation will be able to handle other authentication standards like OAuth and OIDC.

Provisioning events are handled properly

While almost every homegrown directory syncing solution relies on webhooks, CSV files, custom database connections, etc., dedicated providers can invest in better integrations with IdPs.

As a result, you’ll have provisioning requests that are provided in real time, always delivered in the proper sequence, and ensure delivery even under heavy load.

Self-service onboarding

To avoid the back-and-forth, SSO providers often create shareable “Admin Portals,” which your customers’ IT team can use to self-service their SSO and SCIM configurations.

The best providers will ensure everything from attribute mapping to X.509 certificates is self-serviceable and that the admin portal can be programmatically generated and shared for a fully hands-off experience.

On-demand support

Unsurprisingly, dedicated SAML and SCIM providers (like Okta and Microsoft Entra) will have support options. While the support levels can vary, these providers understand the importance of the infrastructure they support and offer strong SLAs.

The best providers go beyond phone and email support, often allowing you to create a shared Slack channel for real-time support whenever needed.

Easy integration

Despite all of these features, a dedicated provider will be much easier to integrate into your app than vanilla SAML or SCIM.

Look for a provider with a REST-based API for authentication, SDKs for your platform of choice, and accessible, clear docs.

Explore: Our Top 5 Recommended SSO Providers and Our Top 3 Recommended SCIM Providers.

Get started with SCIM and SAML using WorkOS

Don’t want to spend days researching providers?

WorkOS allows you to quickly enable SAML-based SSO and SCIM provisioning from all major corporate identity providers with a straightforward, API-based integration. You can get up and running for free using a production-mirror sandbox environment.

• Get started fast: With SDKs for every popular platform and Slack-based support, you can implement SSO and Directory Sync in minutes rather than weeks.
• Events-based processing: While webhooks are also supported, WorkOS’ unique Events API means every SCIM request is processed in order and in real-time. You’ll never miss a provisioning request again.
• Pricing that makes sense: Unlike competitors who price by monthly active users, WorkOS charges a flat rate for each company you onboard — whether they’re syncing 10 or 10,000 users with your app.

Explore WorkOS.

‍