SCIM vs SAML: What Each Does and How To Use Them Together

If you’re implementing authentication or user provisioning for the first time, chances are you’ll see two acronyms appear again and again: SCIM and SAML.

These are not competing protocols. Instead, they help developers implement a full, enterprise-grade authentication solution and manage the full life cycle (create/update/delete)  of a user account. Each protocol handles different parts of the full solution.

In this article, we’ll explain what each standard does, how you can use them together, what security considerations you’ll need to bear in mind and of course — provide you with what you need to get started on implementing each.

What is SCIM?

SCIM, or System for Cross-Domain Identity Management, is an open standard which allows identity platforms to control which users are able to access a service provider (i.e. a SaaS app like yours).

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

• SCIM is a RESTful protocol, functioning just like a normal API.
• 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: Users, which are used to store identity and profile information about each user, and Groups, which are used to define the particular access group(s) a user belongs to and which level of authorization they grant.

When a user is “provisioned” onto an app (the user is “created”, or “added”), the identity provider will exchange key attributes about that user, such as their name, a stable unique identifier for the user, and their email address. The stable identifier must be a unique ID that never changes over a resource’s lifetime, not an email address as that might change. Data is exchanged in the same way when a user is deprovisioned (removed) or updated.

The main feature of SCIM is that it makes it incredibly easy for IT administrators to bulk-provision users onto specific apps, or to programmatically provision/de-provision users - for example, when an employee changes their name, email, or when a new employee is on-boarded or off-boarded.

As a startup, implementing SCIM significantly boosts your odds of landing your first—and possibly largest—enterprise customer since you’ll be reducing the administration overheads for your prospective customers’ IT team and removing another reason to say no.

In fact, because you’re making it smooth and easy to onboard hundreds or thousands of users to your app at once, it’s likely that SCIM will have a huge effect on increasing your revenue.

Read more about SCIM:

• What is SCIM Provisioning
• Every SCIM Attribute Explained
• The Top 3 SCIM Providers for 2024

What is SAML?

Whereas SCIM is focused on ensuring two systems (the service provider and the identity provider) are synced at any point in time on which users can access a service and what level of permissions they have inside that service, SAML is focused on the actual SSO login process.

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

The XML documents used to exchange this data are called assertions, and include information, or “claims”, on the specific user being authenticated, details on the time and method of authentication, and a digital signature which allows your app to validate the integrity and authenticity of the assertion it receives.

The main use case of SAML is to provide an industry standard, secure way to authenticate users. This protocol is over 20 years old and as a result, enjoys support from almost every single identity provider and SSO solution on the market. SAML is particularly optimized for web-based SSO.

SAML is primarily useful when your enterprise customers want their employees to log in once, and then access multiple services or apps. If you want the user to sign in with a 3rd-party account, like their Google login or Facebook login, a delegated-access standard like OAuth is more appropriate.

Read more about SAML:

• What is SAML and How Does it Work?

Do you need SCIM and SAML?

SCIM and SAML are not competing standards and enable different capabilities, so most developers will implement both protocols when working on their app’s enterprise readiness.

SAML will typically be implemented to handle everything which happens at the time of login. In other words, SAML handles the primary authentication duties of the app. It’s specifically designed for SSO however some of your customers might use SAML assertions to send authorization data while others might prefer SCIM, which is a more robust solution for this.

SCIM is best used 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 making sure your app always has correct and up-to-date information for each user your customer wants to allow to use your platform. In addition, once a SAML-brokered login has taken place, your SCIM implementation is what makes sure you have up-to-date information of when a user is added, and most importantly, when they are removed.

Security best practice when using SCIM and SAML

If you’re already familiar with SAML, you might know that the above isn’t the whole truth - In fact, 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.

Since SAML assertions are only passed to your app on a login event, a user can log in and then subsequently have their authorizations revoked by their IT admin. The problem is, that 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 bring all kinds of security implications. For example, your customer might need to remove a compromised user account urgently from a system and, 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.

SCIM solves this by providing real-time, synced access data from your customer’s IdP or directory provider.

This means that whenever a user requests access to a resource or takes an action during a session, you can have reliable, up-to-date authorization data available in your database to decide whether access should be granted or not. 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.

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

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

How to implement SCIM and SAML

Like with any feature you add to your product, there’s a Build vs Buy question to be answered. Here are the two ways developers implement authentication with SCIM and SAML:

Do it yourself

Being open standards, both SAML and SCIM can be implemented manually. Beyond the obvious 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 similarly-custom implementation for.
• SAML isn’t a nice, easy REST API:  While SCIM is RESTful, SAML is an XML-based monstrosity last updated in 2005, that’s hard to set up and maintain.

To start with, you have to deal with XML, which is not only hard to form but also hard to read and write thanks to its strict syntax and verbose nature. This combined with the detailed and comprehensive nature of the SAML specification, with it’s numerous protocols, bindings, and need for digital signatures significantly contributes to a steep learning curve.

Not to mention, you’ll also need to make sure you properly validate and process the SAML responses from your customer’s IdPs, check that the response is actually intended for your app and validate every signature, including the entire SAML response and every assertions, otherwise you risk a huge security breach.

• Webhooks aren’t enough: Receiving SCIM provisioning updates by webhooks is great but like with any webhook implementation, it’s not unusual for webhooks to delay requests, send them out-of-sequence or drop them entirely. While this is a problem for any feature, it’s a particularly dangerous issue with SCIM as you can end up with a failed deprovisioning request from your customer’s IdP, but your system won’t realize and neither will theirs without manual intervention. And unlike with SAML assertions, a re-log won’t fix it!Additionally, webhooks operate on a “fire and forget” basis - once the webhooks send the data, it doesn’t concern itself with how you process it 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 and 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 do things like 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, as well as the FastFed configuration standard are on the horizon  

Have it done for you with 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 take this further by supporting HRIS systems too like Workday, Rippling and BambooHR.
• Normalized Attributes: Often, auth-as-a-service providers will 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, handled properly: While almost every homegrown directory syncing solution relies on webhooks, csv files, custom database connections, etc. dedicated providers are able to invest in better integrations with IdPs.As a result, you’ll have provisioning requests which are provided in real-time, always delivered in 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 make sure everything from attribute mapping to X.509 certificates is self-serviceable, and that admin portals 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 you need it.
• Easy Integration: Despite all of these features, you can expect a dedicated provider to 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.

Next steps

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.