SCIM vs SAML: What Each Does and When You Need Both

SAML and SCIM are not competing protocols. SAML authenticates a user at login and enables single sign-on (SSO). SCIM creates, updates and deactivates user accounts and group memberships in the background, whether or not the user ever signs in. Most organizations need both: SAML for access, SCIM for the account lifecycle. WorkOS describes them the same way: different parts of the same enterprise identity problem.

This guide compares the two protocols, explains where SAML-only provisioning breaks down, and shows how the pair works with Google Workspace as the source directory.

TL;DR

• SAML is an authentication protocol. It runs at the moment of login and produces a session.
• SCIM is a provisioning protocol. It keeps accounts, attributes and groups in sync across apps, independent of login activity.
• SAML-based just-in-time (JIT) provisioning creates accounts at first login but cannot reliably remove access when someone leaves.
• SCIM pushes deprovisioning events to each app, which closes the "zombie account" gap.
• With Google Workspace as your directory, AnySCIM syncs users and groups to any SCIM 2.0 app using read-only access.

Table of Contents

• SCIM vs SAML at a glance
• What SAML does
• What SCIM does
• Why SAML alone is not enough for provisioning
• When you need SAML, SCIM or both
• The Google Workspace case
• How to set up SAML and SCIM together
• Where AnySCIM fits
• Our perspective
• FAQ
• Sources

SCIM vs SAML at a glance

The rest of this article explains each row.

What SAML does

The OASIS Security Assertion Markup Language defines an XML-based framework for exchanging security information between online business partners. In practice, an identity provider (IdP) vouches for a user, and a service provider (SP), the application, accepts that statement and starts a session.

The flow in a typical SP-initiated login:

1. The user opens the application.
2. The application redirects the browser to the IdP.
3. The user authenticates at the IdP, with MFA if your policy requires it.
4. The IdP returns a signed SAML assertion to the application.
5. The application validates the signature and creates a session.

According to the OASIS technical overview, SAML was designed as a vendor-independent approach to multi-domain SSO. Before it, organizations passed authentication state between DNS domains with proprietary cookies and workarounds. SAML replaced those with a standard.

Two points about SAML are often misunderstood:

• SSO is an experience, not a protocol. SAML and OIDC are protocols that deliver SSO.
• A SAML certificate is not an SSL certificate. A SAML certificate signs (and optionally encrypts) the assertions exchanged between IdP and SP. A TLS/SSL certificate encrypts the HTTPS connection between browser and server. One protects the identity claim, the other protects the channel it travels through. Both are described in the OASIS SAML technical overview.

SAML is also not LDAP. LDAP is a protocol for reading and maintaining directory information, typically inside one internal network. SAML is for federated authentication across domains and cloud services.

What SCIM does

The System for Cross-domain Identity Management is an HTTP-based protocol that makes managing identities across multiple domains easier through a standardized service. A SCIM implementation is a REST API that exchanges JSON. The core schema is defined in RFC 7643 and the protocol in RFC 7644.

SCIM covers the full account lifecycle:

• Create a user when they join.
• Update attributes such as name, title, manager or department when they change.
• Add or remove group memberships.
• Deactivate or delete the account when the person leaves.

The key property is that this happens independently of authentication. RFC 7642 notes that SCIM provisions and deprovisions resources in a separate context from authentication, unlike the just-in-time approach used by some other protocols, including SAML 2 Web SSO.

The standard schema is also what makes SCIM operationally useful. Once an app exposes a SCIM 2.0 endpoint, you connect it with a repeatable process instead of a vendor-specific script that someone has to maintain.

Why SAML alone is not enough for provisioning

SAML can create accounts. Many apps support SAML auto-provisioning, usually implemented as JIT provisioning: the first time a user logs in, the app creates an account from the attributes in the assertion. Tesseral's comparison confirms this overlap with SCIM, and also states it is not a substitute for SCIM.

The limits show up in four places.

1. Deprovisioning

JIT provisioning acts only on a login event. If you suspend a user in your directory, nothing is sent to the application. The user may keep an active session, or the account may stay active in the app, until the session expires or someone removes the account by hand. WorkOS identifies this as the main security gap of relying on SAML alone: revoked access at the source is not enforced at the application until a session ends or a new login is attempted.

This is the "zombie account" problem. A former employee's accounts survive in SaaS apps because no one closed each one during offboarding. SCIM removes the dependency on manual cleanup because the deactivation is pushed to the app.

2. Accounts that never log in

JIT creates an account only when someone signs in. You cannot pre-create accounts for a new hire, assign them to the right groups before day one, or license seats in advance. SCIM can provision the account before the first login.

3. Attribute and group drift

SAML attributes are refreshed at login. If a user moves from Sales to Support, the app sees the change only at the next sign-in, and only if the app reads and applies that attribute. With SCIM, a change to a group or attribute in the directory is propagated as an update.

4. Audit and reconciliation

With JIT, the list of accounts in each app is a side effect of who happened to log in. With SCIM, the directory is the source of truth, and you can compare what each app holds against what the directory says it should hold.

When you need SAML, SCIM or both

A common pattern is SAML for the login and SCIM for everything around it. SCIM does not set a password on the account it creates, so the user still needs a way to authenticate. SAML supplies that.

The Google Workspace case

Google Workspace is the identity source for many organizations, and it is a good example of where the SAML/SCIM split matters.

Google Workspace can act as a SAML IdP for third-party apps, so SSO is covered. For provisioning, Google offers automated user provisioning for a catalog of supported applications. Per Google's help page, users sync every few hours, and Business Starter and Frontline Starter customers can configure up to 3 apps, while the other editions listed there can configure up to 100.

The gap appears with apps outside that catalog. A SaaS tool may support SCIM 2.0 and SAML, yet have no Google-built provisioning connector. Teams then fall back on SAML JIT, a custom script against the Directory API, or manual account management. Each option reintroduces the offboarding and maintenance problems described above.

How to set up SAML and SCIM together

The order below works for most apps.

Requirements

• Admin access to your Google Workspace account.
• Admin access to the target app, on a plan that includes SSO and SCIM (many vendors gate SCIM behind a higher tier).
• The app's SCIM base URL and an API token, usually generated in the app's admin settings.
• A list of the groups and attributes you want to sync.

Steps

1. Configure SAML first. Set up the IdP metadata, the ACS URL and the entity ID. Confirm that a test user can sign in.
2. Match identifiers. The unique identifier in the SAML assertion (usually the email address or NameID) must match the userName that SCIM sends. A mismatch creates duplicate accounts or locked-out users.
3. Generate the SCIM token in the target app and note the SCIM base URL.
4. Map attributes and groups. Decide which Google Workspace fields go to which SCIM attributes, and which groups are provisioned.
5. Run a dry-run. Review what would be created, updated or removed before anything changes in the app.
6. Enable sync and check the audit log for errors.
7. Test offboarding. Suspend a test user in Google Workspace and confirm the account is deactivated in the app without that user logging in.

Step 7 is the one teams skip. It is also the one that proves SCIM is doing the job SAML cannot.

Common problems

• Duplicate users. Usually an identifier mismatch between SAML and SCIM.
• Users provisioned but cannot log in. SCIM creates the account but not a password. Check that SAML SSO is enabled for that user or domain.
• Groups not syncing. Confirm the app supports SCIM group resources, not only users.
• Role not applied. Some apps expect roles as a custom attribute. Check the vendor's SCIM documentation.

Where AnySCIM fits

AnySCIM is a cloud-based platform that synchronizes users and groups from Google Workspace to any SCIM 2.0 compatible app. It covers the provisioning half of the pair and leaves authentication to your SAML or OIDC setup.

What it does:

• Real-time sync. A change in Google Workspace, such as an employee departure, is reflected in connected apps without waiting for a login.
• Read-only access to Google Workspace. AnySCIM reads your directory and never writes to it.
• Audit logging. Detailed logs record what was synchronized, and they can be exported for compliance reviews.
• Customizable group and attribute mapping. You decide which groups and fields reach each app.
• Preconfigured templates and custom endpoints. Use a template for a known vendor, or point AnySCIM at any custom SCIM endpoint without writing scripts.

The typical connection takes under an hour. You can start with a 14-day free trial.

Published plans:

See the AnySCIM pricing page for plan details, or read how Google Workspace to SCIM 2.0 synchronization works.

Our perspective

We talk with IT and security teams about identity every day, and the same pattern repeats. SSO is configured early because users notice when login is broken. Provisioning is postponed because nobody notices when it is missing, until an audit or an offboarding incident exposes it.

We think the confusion between SAML and SCIM comes from the word "provisioning" appearing on both sides. SAML JIT does create accounts, so it looks like a complete answer. It is complete only for the first half of the account lifecycle. The second half, removal and change, needs a mechanism that does not wait for the user.

That is why we built AnySCIM around three decisions:

• Read-only access. A tool that syncs identity data does not need write access to your directory. Removing that permission shrinks the damage if something goes wrong, and makes the security review shorter.
• Audit logs you can export. Compliance teams ask which account existed, when it was changed and when it was removed. The log answers that.
• No scripts. A script written for one vendor becomes a liability when its author leaves. A standard protocol, a mapping and a template are easier to hand over.

If you must pick one place to start, test your offboarding. Suspend a test account and see how many apps still list it as active. The answer usually settles the SAML versus SCIM question.

— Nicolas

FAQ

Is SCIM part of SSO?

No. SSO is an experience delivered by authentication protocols such as SAML or OIDC. SCIM is a separate provisioning protocol that manages accounts and groups. The two are usually deployed together, but SCIM does not log anyone in.

Can SAML replace SCIM?

Only partly. SAML JIT can create an account at first login, but it cannot reliably deprovision users or update accounts that are not signing in, as Tesseral explains. If you need automated offboarding, you need SCIM or a manual process.

What is the difference between a SAML certificate and an SSL certificate?

A SAML certificate signs the assertions exchanged between an IdP and an SP, so the app can trust the identity claim. An SSL/TLS certificate encrypts the HTTPS connection between a browser and a server. They solve different problems and are not interchangeable.

What is the difference between LDAP and SSO?

LDAP is a protocol for querying and maintaining directory information, typically inside one network. SSO is the user experience of signing in once to reach many apps, delivered by protocols such as SAML or OIDC. A directory can be reachable over LDAP and also act as the identity source behind SSO.

Does SCIM set user passwords?

No. SCIM creates and manages the account, not the credential. Users authenticate through SSO, so SAML or OIDC should be enabled alongside SCIM.

Sources

• SCIM vs SAML: What each does and how to use them together, WorkOS
• SAML vs. SCIM: What's the Difference?, Tesseral Guides
• RFC 7644: SCIM Protocol
• RFC 7642: SCIM Definitions, Overview, Concepts, and Requirements
• SAML V2.0 Technical Overview, OASIS
• About automated user provisioning, Google Workspace Help
• Directory API Overview, Google for Developers

Made with BabyLoveGrowth to rank on Google and in AI search