Home / Blog

SCIM vs SAML vs OIDC: what each one actually does

4 min read · Published 17 October 2026

People mix these three up all the time. Two of them handle login. One of them handles the account itself. Here is the difference, and why most companies end up using both kinds.

The three standards in one line each

SAML (Security Assertion Markup Language) is an open standard for passing authentication data between an identity provider and a service provider. It is XML based. SAML 2.0 was approved by the OASIS standards body in March 2005, according to its Wikipedia entry. It is still the usual choice for single sign-on in older business software.

OIDC (OpenID Connect) is described by its own specification as "a simple identity layer on top of the OAuth 2.0 protocol". The app receives an ID token, which is a signed JSON Web Token with claims about the person who logged in. The details are in the OpenID Connect Core spec.

SCIM (System for Cross-domain Identity Management) is an HTTP protocol and a data model for managing accounts. It is defined in RFC 7643 (the schema) and RFC 7644 (the protocol), both published in September 2015. If you want the short tour, start with What is SCIM on the home page.

A new hire and a leaver

The easiest way to see the split is to follow one person through a company.

On Monday a new designer joins. HR adds her to the directory, which is usually Okta or Microsoft Entra ID. SCIM then creates her accounts in the chat tool, the code host and the CRM, with the right groups. When she opens the chat tool, SAML or OIDC sends her to the company login page, and the app trusts the result. SCIM made the account. SAML or OIDC let her in.

A year later she leaves. IT disables her in the directory. Her next login fails, because the identity provider refuses her. But the account inside each app can still be there, along with any tokens or API keys she created. Whether it gets disabled depends on whether SCIM, or an equivalent, is wired up for that app.

That second half is the reason SCIM exists. Login control alone does not clean up accounts.

Side by side

What "disabled" means in SCIM

SCIM has a User attribute called active. RFC 7643 describes it as the user's administrative status. A value of true typically means the user can log in. false typically means the account is suspended. The same document adds that the exact meaning is decided by the service provider, so two apps can react differently to the same value.

Okta's documentation says that when an admin deprovisions a user, the user resource in the SCIM app is updated with active=false. It also says that deleting an already deactivated user in Okta does not send a delete request to the app. So "removed from the directory" and "deleted in the app" are not always the same event. Read the Okta SCIM concepts page for the details.

Timing matters too. Microsoft's SCIM tutorial for Entra ID says its provisioning sync runs about every 40 minutes once the first, longer cycle has finished. If your offboarding process assumes access disappears instantly, check the sync interval of your own setup.

Do you need all three?

Not always. A team of eight with four apps can live without SCIM and fix accounts by hand. The cost shows up as headcount and app count grow, and as the number of "who still has access to what" questions grows with them.

• You need SAML or OIDC when you want one login for many apps.
• You need SCIM when you want accounts to appear, change and disappear without someone doing it by hand in each app.
• You usually want both, since they cover different halves of the same problem.

Where AI agents fit

Agents get accounts, roles and access to real systems, just like people do. They are not employees, so nobody runs a leaving process for them. The IETF is working on an extension to SCIM to describe agents, and you can read how that looks so far in SCIM for AI agents: what the IETF draft says. If you would rather click than read, the interactive demo on the home page shows one SCIM request switching an agent off in four apps.

Sources

• RFC 7643: SCIM Core Schema (September 2015)
• RFC 7644: SCIM Protocol (September 2015)
• OpenID Connect Core 1.0
• Security Assertion Markup Language, Wikipedia
• Okta Developer: SCIM concepts
• Microsoft Learn: Develop a SCIM endpoint for Microsoft Entra ID

Keep reading

This is an independent page. It is not affiliated with the IETF, Okta or Microsoft. Standards and drafts change, so check the linked sources for the current state.