When we connect a client's applications to one identity provider, the same line shows up early in the plan: "and we will also need SCIM 2.0". It sounds like part of single sign-on. It is not, and in many integrations you can leave it out. In one of our projects we dropped SCIM and built a joiner, mover, leaver (JML) mechanism instead; more on that below.
Two different jobs
SSO answers one question: who is this user, right now? The application sends the user to the identity provider (IdP), the IdP authenticates them and returns a signed answer, an OpenID Connect ID token or a SAML assertion, and the application checks it and logs the user in.
SCIM 2.0 (RFC 7643 and RFC 7644) answers a different one: which accounts should exist in this application, with which attributes and groups? The IdP calls an API in the application to create, update, and deactivate users, whether or not they ever log in.
| Aspect | SSO (OIDC or SAML) | SCIM 2.0 |
|---|---|---|
| Question | Who is logging in? | Which accounts exist? |
| When it runs | At every login | When a user changes in the IdP |
| Who calls whom | Browser redirects, plus the application's call to the IdP's token endpoint (OIDC) | The IdP calls the application's API |
| What you build | A login flow and token validation | A /scim/v2 endpoint, operated for years |
What SSO alone covers
Without SCIM, an application can still keep its accounts close to the IdP:
- Create on first login. Just-in-time provisioning creates the account from the claims in the token the first time the person signs in.
- Update on every login. Name, e-mail, and group claims are read again each time, so roles follow the IdP from one login to the next. Check that the IdP actually sends groups: some omit them by default or stop listing them above a size limit.
- Link by a stable identifier. Store the issuer and subject (
issandsub, or a persistent SAML NameID), never the e-mail address, which can change or be reused after someone leaves. - Stop leavers at the door. Once the IdP account is disabled, no new login succeeds.
For a group of systems where people log in every day, that is usually enough, and it saves building and running a SCIM endpoint in every application.
What it does not cover
SSO only sees a user when they log in. Plan for the gaps instead of discovering them in an audit:
- A leaver's open sessions and refresh tokens stay valid until they expire. Keep them short, or use back-channel logout where the IdP supports it.
- API keys and personal access tokens never pass through the IdP. Tie them to the account and check that the account is still active, which works only together with the next point.
- An account exists only after the first login, so nobody can assign work or permissions to a new colleague in advance.
- Nobody tells the application that a person left, so the account stays in its database. A scheduled check against the directory, for example Microsoft Graph or LDAP, can disable it.
When SCIM is worth it
Add SCIM when one of these is a hard requirement: accounts must exist before the first login, access must be removed in every application soon after a termination without waiting for the person to log in, or an auditor expects each application's user list to be kept in sync with the IdP. Then SCIM is the standard way to do it, and the major IdPs support it. It is not the only way: a joiner, mover, leaver process of your own can cover the same needs. Neither ends open sessions by itself, so revoke them when an account is disabled.
What we did instead: a JML mechanism
In one of our projects we dropped SCIM and built a JML mechanism. SCIM would have meant a standard provisioning endpoint in every application, and revoking sessions and tokens would still have been our work. A JML mechanism handles the lifecycle of a person's access directly:
- Joiner. Accounts and starting roles are created when someone is hired, typically from the HR system, before their first login.
- Mover. A change of team or role adds the new access and removes the old, so rights do not pile up.
- Leaver. Accounts are disabled and sessions and tokens revoked, not just the next login blocked.
Like SCIM, it needs an integration point in each application; the difference is that you shape the lifecycle around your own systems instead of a standard protocol. SSO stays responsible for logging people in; JML decides what they can access and when that ends.
Tip
If none of these requirements applies, start with SSO alone: link accounts by subject, keep sessions short, and add SCIM or a JML process later if a requirement appears. From day one, also store an identifier the IdP can send over SCIM as externalId (in Microsoft Entra ID, the object ID), so provisioned and existing accounts match. Either way, provisioning extends the same accounts; it does not replace the login.