The SCIM primer

SCIM (System for Cross-domain Identity Management) moves identity data between systems over HTTP. RFC 7642, the concepts document, positions provisioning in a separate context from authentication: a user's account in an application is created, updated, and removed by a provisioning flow that runs whether or not that user is signing in (RFC 7642 Sections 1 and 2.2, retrieved 2026-11-01). Single sign-on answers "may this session start"; provisioning answers "which accounts exist, with which attributes, and in which state".

The contrast that matters in practice is just-in-time (JIT) provisioning. Under SAML or OIDC JIT, the identity provider's assertion or ID token creates the account at first sign-in, and the account's attributes are whatever that one assertion carried. Three consequences follow. No account exists before the first sign-in, so group membership and application-level state cannot be prepared in advance. No flow removes the account, so deprovisioning depends on whatever account-lifecycle machinery the application grew on its own. Every sign-in rewrites attributes from the assertion; attribute authority therefore alternates between the assertion and whatever else writes to the store. SCIM's push model exists to make those three things explicit, pre-arrival, and reversible.

"Directory sync" is the product-shaped name for the same push idea. A directory sync offering continuously exports the directory (or a scoped subset of it) to the application and translates lifecycle events into the application's own concepts. SCIM is the IETF protocol form of that push: RFC 7642 Section 2.2.3 defines push and pull modes, and Section 2.3 enumerates the flows a provider-to-provider push covers (create, update, and delete push; SSO push; SSO pull; password reset). RFC 7642 is deliberately small; its breakdown page on this lab-site carries the section detail.

On the wire, three parties do the work. The SCIM client is the identity provider's provisioning service: Entra's provisioning engine, Okta's provisioning integration, Google Workspace auto-provisioning, or an HR-driven system such as Rippling. The SCIM service provider is the application's endpoint: the /Users and /Groups resources (plus the discovery endpoints) that accept the pushed data and apply it to the application's own identity store. The subject is the user (or, since RFC 9944, the device) that the records describe. RFC 7642 Section 2.2.2 models the actors behind those roles in its Figure 1; the wire contract itself lives in RFC 7644.

The push model has one property that shapes everything else on this lab-site: the client initiates every state change, and each client implements the protocol in its own dialect. The server that wants to be provisioned by four providers is not conforming to four readings of one RFC by accident; it is engineering for the differences on purpose. The provider quirks almanac on this site documents those differences with dated citations, and the architecture guide covers what the service provider sits on top of.

RFC 7643 Section 3.1 assigns authorship of the two identifiers, and the assignment is absolute.id is server-issued: case-exact, read-only, always returned, and MUST NOT be specified by the client. externalId is client-issued: optional, case-exact, read-write, and the server MUST treat it as scoped to the provisioning domain. The client never picks the server's identifier and the server never second-guesses the client's own.

Correlation between the two sides is the client's problem to solve, and every provider solves it with a matching (or joining) attribute: the attribute it filters on when it looks for an existing resource before creating or updating one. The providers' documented allowlists differ sharply:

The choice precedes everything else. A matching key that the source directory can rename is a key that turns a rename into a duplicate create on the next correlation pass, or into a deletion when the client treats "no match" as "gone". GitHub's EMU contract makes the coupling explicit: the Entra objectidclaim MUST equal the SCIM externalId, or the SAML and SCIM identity links fail. The lifecycle guide follows this theme through the deactivation and deletion flows, where the same wrong choice ends in destroyed data, and the testing guide carries it as the validator's joining property.