Directory-led provisioning with SCIM 2.0

SCIM, the System for Cross-domain Identity Management, moves user and group records between systems over a plain REST API. SenseCrypt is the service provider and your identity platform is the client that pushes every change. Nothing here polls your directory, and your joiner and leaver process is not duplicated on this side.

The base path sits on the tenant's own issuer host, and every request carries a bearer token scoped to that one tenant, which fails closed against any other. Two credential types work: an opaque token minted in the console, which is the shape most provisioning connectors expect, or a machine-to-machine access token whose role carries the SCIM capabilities.

The three discovery routes, the service provider configuration, the resource types and the schemas, are static metadata and are anonymous. Every route that touches data requires the token.

This is the part of the integration that surprises teams, so it comes early. A SCIM-created user is a pending shell: a profile carrying the attributes and group memberships your directory owns, with no face binding at all. A shell cannot sign in, because the token grant requires an enrolled user.

The person supplies the missing half the first time they open the Authenticator app. The app claims the shell in place, which preserves the subject identifier your directory provisioned, the attributes it set and the memberships it granted. A device cannot overwrite values your identity platform owns.

For you that means one step to place in the onboarding plan. For the user it means one action on their own phone, and there is no separate enrollment system for anyone to operate.

Automatic provisioning is usually sold on the time saved creating accounts. The value is on the other side of the lifecycle. Orphaned accounts are what manual deprovisioning leaves behind, and each one is a way in that nobody is looking at.

Setting a user inactive is a reversible suspend that runs the eager revocation path at once: device keys revoked, refresh token families killed. Re-activating restores the account but not the credentials, so the person enrolls their device again. A delete is permanent, with the same revocation behind it.

Removing someone from a group does the same thing. Access is severed immediately rather than left to expire, and a user who is still in other groups simply re-authenticates. This is why lifecycle changes here land on the next token or refresh instead of at the end of a token lifetime.

Keeping those two apart makes a project much easier to scope. SCIM is a management API your directory calls on its own schedule. OIDC and SAML are what happen when a person arrives at an application. You want both, and they are configured separately.

Group membership is what connects the two. The groups your directory pushes are what the default-closed access gate reads, and a role conferred on a group reaches every member of it, including the members your directory adds next month. That is usually cleaner than assigning roles person by person.

In practice the sequence is short: your directory creates the account and its groups, the person enrolls a device on first use, and from then on every sign-in is a live face ceremony that ends in a standard token or assertion.