SSO vs. SCIM in workforce identity: Sign-in and provisioning

retained text

SSO vs. SCIM in workforce identity: Sign-in and provisioning
SSO handles employee sign-in, and SCIM keeps app accounts and groups in sync with your directory. Learn where offboarding gaps appear and what to ask vendors.
Single sign-on (SSO) answers one question at sign-in: is this person who they say they are? SCIM (System for Cross-domain Identity Management) answers a different one in the background: who should exist in this app, and which groups are they in? Neither decides what a signed-in employee may do inside the app. That is up to the application's own authorization model.
Rollouts get into trouble when these are collapsed into one word, access. An employee signs in successfully and still cannot open the project they were hired to work on. A contractor is marked inactive in the directory on Friday and still has a live session on Monday. The first is an authorization problem. The second is a revocation problem: the directory change can reach the app, but ending the session is the app's job.
The four things people call access
Authentication is the sign-in event. The employee proves their identity to the identity provider (IdP), and the IdP passes the result to the application. SAML, OpenID Connect (OIDC), and WS-Federation are common standards for carrying that result.
Provisioning keeps the app's users and groups in step with the directory. SCIM is an application-level HTTP protocol for provisioning and managing identity data across domains, such as from an enterprise directory to a cloud application. Its core resources are Users and Groups, at the /Users and /Groups endpoints, and it also supports custom resources and extensions.
Authorization is what the app allows once someone is inside: seats, roles, record-level permissions. A synced group may grant a role in the app, or it may only record membership that an admin still has to bind to permissions.
Sessions and revocation cover what the app has already issued, such as session cookies, refresh tokens, and API keys. Ending them is up to the app, as the deactivation section below explains.
How SSO, SCIM, and app authorization compare
The layers fail independently. An app can have working SSO and correct SCIM and still give a new analyst a finance admin's permissions, because neither protocol decides roles.
Do you need both SSO and SCIM?
If you want the IdP to control sign-in and you want directory changes to update app accounts, you need SSO plus a provisioning integration. SCIM is a common choice for provisioning, though other integrations can fill that role.
With SSO alone, accounts still need to be created through just-in-time (JIT) provisioning at first sign-in, an invitation, or another process. They also need a removal process: an account can stay active in the app after the person loses the ability to sign in through the IdP. SCIM without SSO updates account records but leaves authentication to the app's other sign-in methods.
Following one employee: joiner, mover, leaver
One employee record moving through four systems: HR, the directory or IdP, the provisioning client, and the destination app. Each hop is a separate integration that can succeed or fail on its own.
Joiner. HR creates the employment record. The directory or IdP creates the user and adds them to groups. The provisioning client (whichever system sends the SCIM requests) calls POST /Users on each connected app, which creates the account. In apps that support it, having the account in advance lets colleagues assign work before the employee first signs in. The SCIM and JIT guide gives document-review assignment as an example.
Mover. The employee changes teams. The IdP updates group membership, and the provisioning client sends a PATCH with the change. If the app maps groups to roles through SCIM, the new role can apply without the user signing out and back in. Confirm the mapping and when it takes effect in each app.
Leaver. Rehearse this one before you need it. A deprovisioning request may set the SCIM active attribute to false rather than delete the user. An Okta deactivation request, for example, looks like this:
{
  "schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
  "Operations": [
    { "op": "replace", "value": { "active": false } }
  ]
}
Everything after that, including whether existing sessions end, is the receiving app's decision.
Just-in-time provisioning versus SCIM pre-provisioning
Just-in-time (JIT) provisioning creates the account during the user's first SSO login, so nobody has to pre-provision it. Without JIT, an app that supports SSO needs the account to exist before the user signs in. JIT saves that setup, but it has two costs worth planning around. First, it does not delete or suspend accounts, so the app account can stay active after the person leaves unless another process removes it. Second, the app learns only what arrives at sign-in, such as the attributes in a SAML assertion. SCIM delivers identity updates on a separate channel, and its schema can be extended with custom attributes.
A JIT account exists because someone authenticated. Whether that person should hold a licensed seat, or belong to the group that grants approval rights, is a separate decision the app makes from whatever data it received.
Deactivation is not proof of revocation
Flipping one attribute in a user record changes a database field. Sessions, refresh tokens, and API keys issued earlier are separate objects that can remain usable until they expire or are revoked.
Setting active to false changes the app's record of the user. Whether anything else changes depends on the app, so check each one for three gaps.
Sessions and refresh tokens issued before the deactivation can remain usable until they expire or the app invalidates them. If API keys or personal access tokens are not tied to the SCIM user's status, they need to be revoked separately. Timing is the third gap: with polling-based sync, a terminated employee stays active in the app until the next sync runs, and push-based SCIM shrinks that window without closing it.
SSO on its own has a related gap. SAML sign-in, for example, does not by itself provide a complete offboarding process. Removing a user in the IdP blocks their next SSO sign-in, but someone who already holds a session may not need to sign in again for some time. The app needs a way to learn about access changes and apply them to credentials it has already issued.
Ask each vendor what their deactivation handler revokes, and test it with an account you control before you rely on it. For the application side of the problem, our engineering write-up SCIM deprovisioning is a promise your app probably breaks walks through what a correct handler does.
What to ask each app vendor before you sign
Coverage
- Which SCIM operations do you support, and does that include PATCH? A service provider that does not implement an operation is expected to answer 501, and the specification names PATCH as one such case. PUT replaces existing attributes, while PATCH changes only what the request specifies. If the app accepts only PUT, confirm that your IdP sends full replacements rather than PATCH requests. Ask for the app's /ServiceProviderConfig response, which describes the SCIM features the app supports.
- Which user attributes do you read, and which do you ignore?
- When a synced group changes, does it map to a role in the app, or only to membership?
Failure visibility
- Where can I see the requests my IdP sent and your responses? SCIM errors are returned as JSON with a status, an optional scimType keyword, and an optional human-readable detail.
- Which errors should I expect to triage myself? A uniqueness error means a value is already in use or reserved, and a mutability error means the change conflicts with the attribute's mutability or current state. A 409 from POST /Users can mean the person already exists under a different external ID. Check your IdP configuration before treating it as an app bug.
- How long is that history retained, and can I filter it? For developers using WorkOS Directory Sync, SCIM directories include provisioning logs covering the last 30 days of requests, with payloads and failure details. The logs can be filtered by fields including email, status, and time range. Ask the app vendor what visibility its customer admins get.
Sync and offboarding
- Is sync push-based or polling-based, and at what interval?
- When you receive active: false, do you end existing sessions and revoke refresh tokens, or only update the record?
- What happens to API keys and service credentials the user created?
- If JIT is enabled, what role does a new account get by default?
If you are building the app
Every question in the previous section is a product decision for the team that builds the app. SCIM delivers the state change, and your code decides whether that change revokes anything. Test how your handlers apply changes from each provider you support.
WorkOS offers SSO and Directory Sync as developer products for that integration work. For implementation details, how to add SSO to your B2B SaaS app with AuthKit covers organization setup and sign-in. The WorkOS access model explains how directory sync, JIT, and invitations resolve into membership. Our guide to SCIM vs SSO and how they work together covers the same comparison from the builder's side.

document fetched 2026-10-24 11:27