SCIM lets enterprise IT push users, groups, and role changes from their identity provider (Okta, Entra, Google) into your product automatically.
SCIM (System for Cross-domain Identity Management) is the standard protocol identity providers use to sync users, groups, and role assignments into downstream applications. When an IT admin at a 5,000-person customer adds a new employee to your app's group in Okta, SCIM creates the user in your product; when they disable the employee, SCIM deprovisions. Without SCIM, the customer's IT team is manually mirroring changes across 100+ apps and yours becomes the one they escalate about. With SCIM, they stop thinking about your product — which is what you want.
Four core operations on Users and Groups: Create, Read/Search, Update (partial via PATCH), Delete (or soft-delete via active=false). The identity provider (Okta, Microsoft Entra, Google Workspace, JumpCloud, OneLogin) is the source of truth; your app is the downstream consumer. IdP pushes changes on a schedule (typically every 40 minutes) or on event. Attributes carried: userName, emails, name, active status, groups. Extended schemas support custom attributes (department, cost center, employee ID) that your app may map to roles or tenants.
Implement SCIM 2.0 (RFC 7643/7644), not SCIM 1.1. Endpoints your service must expose under a tenant-scoped base URL (e.g., /scim/v2/{tenant_id}): GET/POST /Users, GET/PUT/PATCH/DELETE /Users/{id}, GET/POST /Groups, GET/PUT/PATCH/DELETE /Groups/{id}, GET /Schemas, GET /ResourceTypes, GET /ServiceProviderConfig. Auth: OAuth 2.0 bearer token, one token per tenant, revocable. Return proper SCIM error responses (structured JSON with schemas, status, detail) — Okta and Entra will surface these directly to the admin.
The hardest part of SCIM is not the protocol; it is deciding how identity provider groups map to your app's roles and permissions. Options: (1) Group name convention — 'ProductX-Admins' in Okta maps to admin role in your app. Simple, error-prone. (2) Group ID mapping table — admin UI in your product where the customer explicitly maps IdP group IDs to your roles. More flexible, more UI to build. (3) SCIM enterprise extension attributes — customer maps their department/role attribute to your role. Pick one and document it clearly. Mixing approaches confuses everyone.
The single most important SCIM operation is disable. When an employee is terminated, IT expects that within minutes their access to your product is gone — sessions revoked, API tokens invalidated, in-flight webhooks halted. Implementation: on PATCH with active=false or DELETE, immediately revoke all sessions for that user, invalidate API keys they own, remove from all groups. Test this end-to-end in every environment. Enterprise security questionnaires ask about it explicitly; broken deprovisioning is an audit finding and a headline waiting to happen.
Test against real IdPs, not just the RFC. Okta's Integration Network (OIN) and Microsoft Entra's Gallery both offer SCIM testing tools; publish an app in each once tested. Handle the specific quirks each IdP has (Okta sends PATCH with 'replace' operations, Azure sends a mix of add/replace/remove, Google Workspace has its own attribute mapping). Publish integration docs for each supported IdP with screenshots of the admin's setup flow. Support these three IdPs (Okta, Entra, Google) covers 90%+ of enterprise buyers.
Investor directory · Fundraising library · Articles A–Z · Company funding database