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

SCIM vs SAML comes down to account lifecycle versus login. SAML authenticates a user at login by passing a signed assertion through the browser. SCIM manages the account behind that login: it creates, updates, and deactivates user records server to server through a REST API, with no user present. They are not alternatives: SAML does not deprovision accounts when someone leaves, so enterprise deployments that need SAML SSO and automated offboarding need both. See the SAML browser SSO profile and Okta’s SCIM overview.

When an enterprise buyer asks whether you support single sign-on (SSO) and provisioning, you need to check two separate integrations. Passing a department or group at login does not give the directory a way to update that account after the person stops signing in.

Key takeaways

• SAML handles login, while SCIM handles account lifecycle.
• SAML attributes describe the user at login; SCIM updates records independently of login.
• SAML does not disable or delete application accounts.
• SCIM works without SAML and can accompany other login methods.
• When a buyer asks for SSO and provisioning, they are checking that you can remove access automatically, so treat deprovisioning as a security control rather than an admin convenience.

SCIM vs SAML at a glance

Provisioning is not necessarily immediate: delivery timing depends on the connector. Microsoft’s provisioning guide links to an explanation of initial and incremental synchronization cycles.

What SAML actually sends

Security Assertion Markup Language (SAML) supports browser-based SSO. In a common flow, the application, called the service provider (SP), redirects you to the identity provider (IdP), the system that authenticates you. You return carrying a signed XML document called an assertion. The OASIS SAML profiles describe this flow.

The assertion says who the user is and can carry attributes such as email, department and group memberships. The application must check the signature, intended audience and validity conditions before starting a session. This shortened example illustrates the attributes and time conditions defined in the SAML core specification; it omits the signature and other required elements.

<saml:Assertion IssueInstant="2026-08-04T09:14:22Z">
  <saml:Issuer>https://idp.example.com</saml:Issuer>
  <saml:Subject>
    <saml:NameID Format="...:emailAddress">dana@example.com</saml:NameID>
  </saml:Subject>
  <saml:Conditions NotBefore="2026-08-04T09:14:22Z"
                   NotOnOrAfter="2026-08-04T09:19:22Z"/>
  <saml:AttributeStatement>
    <saml:Attribute Name="department">
      <saml:AttributeValue>Engineering</saml:AttributeValue>
    </saml:Attribute>
  </saml:AttributeStatement>
</saml:Assertion>

Look at NotOnOrAfter. In this example, the assertion’s validity window ends at 09:19:22, five minutes after NotBefore. That limits when the assertion can be accepted, not how long the application’s account exists. The SAML conditions specification defines that expiry boundary; it does not define an account-disable operation.

The attributes in a login assertion describe the user at that moment. If their department changes later, that assertion will not tell the application about it. SAML also defines Single Logout for ending sessions, but ending a session is different from disabling or deleting the account. Our IdP-initiated versus SP-initiated SSO guide explains the different ways a login can start.

If you are implementing this half, our SSO implementation guide for developers covers the SAML and OIDC flows in depth, and the Keycloak SAML service provider guide walks through the configuration end to end.

What SCIM actually sends

System for Cross-domain Identity Management (SCIM) works without a browser or a user in the loop. Your provisioning system reads the source directory and sends changes directly to the receiving API. The schema lives in RFC 7643 and the protocol in RFC 7644.

The traffic uses HTTP requests with JSON bodies. A connector can create a new hire with POST /Users, update attributes with PATCH, and deactivate a departing employee by setting active: false. It can manage membership through /Groups. Here is an illustrative deactivation request using SCIM PATCH:

PATCH /scim/v2/Users/2819c223-7f76-453a-919d-413861904646
Content-Type: application/scim+json
Authorization: Bearer <token>

{
  "schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
  "Operations": [
    { "op": "replace", "path": "active", "value": false }
  ]
}

That request changes the account without waiting for another login. It is then up to your application to actually treat that user as locked out. The SCIM definition of active leaves the precise effect to the service provider.

One naming quirk helps when you read vendor documentation: the system sending SCIM requests is the client, and the system exposing the API is the service provider. In our Okta-to-Keycloak integration, Okta is the SCIM client and Keycloak is the SCIM service provider. Those names describe the API direction, independently of their SAML roles.

Is SAML required for SCIM?

No. SCIM does not require SAML or SSO. For a bearer-token integration, the client needs a reachable SCIM endpoint and an authorized bearer token. The standard allows other HTTP authentication methods too; SAML is not a prerequisite. RFC 7644’s authentication section explains those options.

You can provision accounts into an application that uses OpenID Connect (OIDC) or local sign-in. A vendor may put provisioning settings inside an SSO integration, but that does not make the protocols dependent on each other.

Does SAML just-in-time account creation replace SCIM?

No. Just-in-time (JIT) provisioning creates an account when the person first signs in; it does not provide background offboarding. It is behavior the application adds around login, rather than a SAML account-management operation. Okta’s JIT documentation, for example, describes creating an account automatically the first time someone signs in through an external identity provider.

JIT can save you manual onboarding, but someone who has left does not return to trigger an update. If you use JIT alongside SCIM, decide how both paths match the same person and which system owns each attribute. Otherwise, login may create a second account or overwrite directory-managed data. For more background on account lifecycle, read our user provisioning guide. For the deeper treatment of this question, read our JIT provisioning versus SCIM comparison, which covers when first-login account creation is enough and when it is not.

What breaks when you only have one

SAML without SCIM. You have company login, but account lifecycle needs another process. Accounts may be created manually or at first login, and SAML will not remove them. Disabling a person at the IdP can block future authentication there, while their application account remains active. Check local login routes rather than assuming that disabling the IdP account removes every way to access the app.

SCIM without SAML. You can synchronize accounts, but SCIM does not define how users sign in. You still need authentication, which might be OIDC, local passwords or another method. Missing SAML is not a problem if another protocol meets the buyer’s SSO requirement.

Neither. You need another way to manage login and lifecycle, and someone must own offboarding. A spreadsheet can track the task, but it cannot disable an account by itself.

Do you actually need both?

You need both when you want SAML-based company login and automated account lifecycle management. For a small internal tool, manual offboarding may be workable if someone owns it and checks that access was removed.

We would prioritize SCIM when one of these applies:

• Your buyer requires provisioning. Confirm whether they need account creation, updates, group membership and deactivation, rather than answering only the SSO part.
• You need evidence of access removal. Keep provisioning results and check failed deactivation requests so you can show what happened to each account.
• Headcount moves fast. Contractors, seasonal staff and reorganizations can create more lifecycle changes than your manual process handles reliably.
• Access costs money. If your application charges for active seats, reconcile billable accounts with the directory as well as disabling access.

If login is the immediate requirement, starting with SAML is reasonable. Before adding SCIM later, plan how you will match existing application accounts to directory users so provisioning does not create duplicates.

How the two run together

With SAML and SCIM configured, the lifecycle can look like this. Okta’s SCIM overview describes account creation, profile updates and deactivation:

1. HR marks a new hire as active in the directory.
2. The provisioning client sends POST /Users to assigned applications, so accounts can exist before the first login.
3. The new hire opens the application, authenticates through SAML, and uses the provisioned account.
4. They move teams. The connector updates attributes or group membership, and the receiving application applies its access rules without another login.
5. They leave, and the connector sends active: false to deactivate their account.

Account creation, updates and deactivation happen with no user present. That is why passing groups in a login assertion does not replace provisioning.

Deactivation and deletion are separate operations. Keeping an inactive user record can help you retain a link to past activity, but SCIM does not decide your application’s data-retention policy. The SCIM User schema defines active, while the receiving service determines its effect.

SCIM vs SAML in Keycloak

Keycloak supports SAML 2.0 clients for registered applications and can broker SAML v2.0 identity providers, so it can sit on either side of a SAML login. We explain these roles in the difference between an SP and an IdP.

Keycloak 26.8 promotes its native SCIM API from preview to supported. The 26.8 release notes say that “In this release, the SCIM API is promoted from preview to supported.” The 26.8 upgrading guide adds that the scim-api feature “is now enabled by default” and that if you previously enabled it with --features=scim-api, “that configuration is no longer required.” For more on this release, read our Keycloak 26.8 SCIM API guide.

The 26.8 release notes describe the SCIM API as an interface for managing realm users and groups that integrates with identity management systems and SCIM-compatible applications. In SCIM terms, Keycloak is the service provider, and the records it manages are the realm’s users and groups.

If Active Directory or OpenLDAP is your source of truth, review our Keycloak LDAP integration guide before adding another synchronization path.

SAML and SCIM together in Keycloak

In this setup, Okta or Entra provisions users into Keycloak over SCIM and authenticates them through SAML, while your application uses Keycloak for login. Use a disposable realm to check account matching before applying the setup to real users. Every Keycloak step below follows the 26.8 server administration guide, which is linked at each step.

1. Enable SCIM for the realm. Under Realm settings, General, turn SCIM API on and save, following Enabling SCIM for a realm. The SCIM API base URL for the example realm is https://identity.example.com/realms/demo/scim/v2.
2. Create a confidential client for the connector. Enable Client authentication and Service accounts roles for client credentials tokens, following Setting up a service account client.
3. Assign permissions in two places. In Client scopes, open the dedicated scope and its Scope tab, then turn Full Scope Allowed off. Assign realm-management role manage-users there and under Service account roles, as Assigning permissions requires both assignments.
4. Add the audience mapper. In the dedicated scope, add an Audience mapper with the realm’s SCIM base URL as Included Custom Audience and Add to access token enabled, following Configuring the token audience.
5. Point your directory at Keycloak. Both connectors need the base URL and authentication configured using the client credentials from step 2. Access tokens expire, so plan how the connector will get a fresh one before you rely on unattended provisioning.
   • If you use Okta, Okta’s SCIM integration instructions ask for the SCIM connector base URL, the field name of the unique identifier for your users (use userName, which the guide’s core user attribute table maps to Keycloak’s required username), the provisioning actions you want, and an authentication mode: prefer OAuth2 with Client Credentials and configure the token endpoint and client credentials. Use HTTP Header with a bearer token as a fallback, with a process to replace it before it expires. Our Okta-to-Keycloak walkthrough covers the connector configuration and testing in detail.
   • If you use Entra, Microsoft’s provisioning guide has you enter the SCIM endpoint as Tenant URL and the bearer token as Secret Token, then test the connection before the initial cycle runs.
6. Configure SAML and test with a provisioned user. Set up the SAML side using our Keycloak SAML service provider guide. Provision a test user over SCIM before their first login, then confirm that the SAML login lands on that account and does not create a second one. If Keycloak is brokering an external SAML identity provider, read the guide’s first login flow section before you choose automatic account linking. Automatic linking is risky if users can register arbitrary usernames or email addresses, so curate registration carefully.

Verify SCIM deactivation and a fresh login

Use a non-administrator test account for this. The guide documents protection of administrative users and groups from SCIM modification. Remove the user’s assignment in the source directory and inspect the connector’s request and result. For a controlled API test, send the earlier PATCH body to the provisioned user’s resource at this path, replacing USER_ID with its returned identifier:

https://identity.example.com/realms/demo/scim/v2/Users/USER_ID

The guide’s core user attribute table maps SCIM active to Keycloak’s enabled attribute. Read the user back, confirm active is false and Enabled is off in the Admin Console, then attempt a fresh login through your SAML integration. Treat access removal as verified only after this test fails as expected. Test an already-open application session separately, because disabling the account does not prove every downstream session has ended. Our SCIM endpoint implementation guide covers request validation and troubleshooting.

Frequently asked questions

Is SCIM a replacement for SAML?

No. SAML authenticates a person at login, while SCIM manages their account record. You need a login method and a lifecycle process, but you can pair SCIM with SAML, OIDC or local authentication.

Can you use SCIM without SSO?

Yes. SCIM works independently of user login. In a bearer-token integration, the provisioning client needs an endpoint and an authorized token, even if users sign in with local credentials. See SCIM authentication and authorization.

Does SAML handle deprovisioning?

No. SAML does not disable or delete application accounts. Blocking a user at the IdP can stop new SAML logins there, but account deactivation needs its own controls. The SAML profiles distinguish SSO from Single Logout.

Is SCIM more secure than SAML?

They handle different responsibilities, so neither replaces the other’s security controls. For SAML, validate signatures and assertion conditions. For SCIM, protect the endpoint with TLS and give its credential only the permissions it needs. The SCIM security considerations explain why the provisioning API needs careful access control.

What about OIDC instead of SAML?

OpenID Connect (OIDC) can handle user authentication while SCIM manages accounts independently. If your buyer supports OIDC, you do not need SAML just to add provisioning. Our SAML versus OIDC comparison covers the login choice, and Keycloak’s protocol comparison provides more context.

Which should we implement first?

Start with the buyer’s immediate requirement. If that is company login, implement SSO while documenting how you will handle account removal. If automated onboarding and offboarding are required from the start, plan SSO and SCIM together, including how both paths identify the same account.

What to do next

For the schema and endpoint reference, see what SCIM is and why it matters. The Skycloak SCIM tester provides a request builder, schema validator and cURL command generator you can use to prepare an endpoint test. For product and setup guidance, see the SCIM provisioning feature page, single sign-on feature page and Skycloak documentation.

If you are evaluating a managed deployment, Skycloak’s managed Keycloak hosting page describes its service for running upstream Keycloak, and you can see Skycloak pricing.