SCIM provisioning for SaaS: automate user access and deprovisioning
Implement SCIM user and group provisioning with tenant-scoped identities, safe updates, timely deactivation, reconciliation and secure client access.
In this guide
What is SCIM provisioning?
The System for Cross-domain Identity Management (SCIM) is an HTTP-based protocol and schema for exchanging identity records between an organisation and a service provider. It can automate user and group creation, updates and deactivation. SCIM does not define your product's tenant model or decide a user's permissions; the service provider must apply its own authentication, authorization and privacy controls.
Choose the SCIM resources your product actually supports
RFC 7643 defines core User and Group schemas, and RFC 7644 defines operations such as create, read, update, patch and delete. Document supported attributes, filters, groups and behaviors, including unsupported fields. Publish a capability guide so an IdP administrator can configure the connector without guessing.
Keep every SCIM client and record inside an explicit tenant
Authenticate the provisioning client and bind it to one configured customer tenant. RFC 7644 does not define a universal multitenancy scheme, so your service must make tenant association explicit and enforce it on every request. A user ID or externalId from one customer must not resolve to a record in another.
Use stable identifiers and a defined attribute map
Store a provider-supplied externalId in the scope of its tenant and keep your own immutable resource ID. Define which side controls display name, email, active status and groups. Do not let an untrusted or conflicting attribute silently transfer ownership of an existing account.
| SCIM attribute / operation | Tenant and identity key | Source of truth | Validation and error response | Deactivation behavior |
|---|---|---|---|---|
| User create / update | ||||
| Group membership | ||||
| User inactive / delete |
How do you implement SCIM endpoints safely?
Require TLS and narrowly scoped client authentication
SCIM carries sensitive identity information. Use HTTPS, protect bearer tokens, scope a provisioning credential to its tenant and supported operations, and rotate it through an administrator-controlled process. Avoid putting credentials in URLs or logs, and reject anonymous requests to private provisioning resources.
Validate requests and make retries safe
Check required fields, schema, value lengths, filters and tenant ownership before changing an account. Apply updates atomically where appropriate and return protocol-compatible errors. A connector may retry after a timeout, so handle repeated creates or patches predictably and avoid duplicating users, groups or invitations.
Map groups to product roles through customer-approved policy
A group name is an external input, not an authorization decision. Let an authorised tenant administrator map allowed IdP groups to product roles, make the mapping visible and reject unknown privileged groups by default. Keep group membership changes within the same tenant and audit role-impacting updates.
What should happen when SCIM deprovisions a user?
Define whether inactive and deleted mean different things
Many integrations use an active=false update to suspend an identity; DELETE may have a separate meaning in the service. Document the behavior and prefer an auditable deactivation that preserves necessary business records while immediately preventing new sign-in. Do not assume every IdP sends the same event sequence.
Revoke sessions and credentials when access is removed
On deactivation, block future authentication, revoke active sessions and product-issued tokens, remove relevant group grants and stop queued privileged work where feasible. Propagate the change promptly across caches and regions. SCIM delivery is not a substitute for enforcing membership at sign-in and during sensitive actions.
Reconcile drift and investigate failed syncs
Track last successful sync, rejected changes, disabled users and stale groups. Provide a tenant-scoped status page and an administrator replay path. Periodically compare the IdP's intended state with the SaaS account state, while avoiding a bulk overwrite that could reinstate an account removed for an incident.
SCIM provisioning questions
Does SCIM replace SSO?
No. SSO handles authentication; SCIM manages identity records and lifecycle changes. A customer can use either one without the other, but using both requires linking the same stable identity and tenant safely.
Does SCIM define how SaaS tenants work?
No. RFC 7644 says multitenancy is optional and does not specify the provider's tenant-association scheme. Your service must authenticate each provisioning client and enforce the tenant boundary itself.
Should deactivation delete a user's data?
Usually these are separate decisions. Deactivation should stop access promptly; data deletion follows the service's retention, contract and legal process. Document each action so an IdP change does not erase records the customer still needs or leave an inactive account able to sign in.
How do you test an IdP's SCIM integration?
Test the supported operations, repeated requests, unknown attributes, duplicate emails, tenant crossover, group changes, deactivation, deletion and recovery from an outage. Use a sandbox tenant and confirm that failures are visible to the administrator without leaking another tenant's data.
Related practical guides
Related issue guides
Sources and publication record
Draft prepared 27 September 2026; engineering, security and editorial review pending · Sources checked .
- IETF RFC 7643: SCIM Core SchemaInternet Engineering Task Force
- IETF RFC 7644: SCIM ProtocolInternet Engineering Task Force
- OWASP Cheat Sheet: Secrets ManagementOWASP Foundation
- OWASP Cheat Sheet: AuthorizationOWASP Foundation
- AWS SaaS Lens: Preventing cross-tenant accessAmazon Web Services