SCIM 2.0 User Provisioning for Enterprise AI Tools
TL;DR — SCIM 2.0 automates user lifecycle management for enterprise AI platforms. When a user joins, changes roles, or leaves, the identity provider (Okta, Entra ID) automatically provisions, updates, or deactivates the account in the AI platform via SCIM API calls. SCIM complements SSO: SSO handles authentication, SCIM handles account lifecycle. AI platforms must implement /Users and /Groups endpoints with filtering, pagination, and deactivation support. Without SCIM, enterprise customers must manually manage accounts — a process that fails security audits and blocks enterprise sales.
Enterprise customers do not manually create accounts for every employee who needs access to an AI platform. They use SCIM 2.0 to automate the entire user lifecycle — from onboarding to offboarding — through their identity provider (IdP).
SCIM (System for Cross-domain Identity Management) is an open standard (RFC 7643 and 7644) that defines a common API for user and group management. When integrated with SSO, it provides end-to-end identity management: SSO handles who can sign in, SCIM handles which accounts exist (Clerk 2026).
This post covers the SCIM 2.0 protocol, endpoints, implementation patterns, and integration with SSO for enterprise AI platforms. For AI platform security, SCIM is the identity management layer.
What Is SCIM 2.0?
SCIM 2.0 is a standardized REST API for managing user identities across systems. It defines:
- Resource schemas (User, Group) with standard attributes
- REST endpoints for CRUD operations
- Filtering, sorting, and pagination for large datasets
- PATCH operations for partial updates
- Bulk operations for batch processing
| SCIM component | What it does |
|---|---|
| /Users endpoint | Create, read, update, delete, list users |
| /Groups endpoint | Create, read, update, delete, list groups and memberships |
| /ServiceProviderConfig | Describe SCIM capabilities (filter, patch, bulk, changePassword) |
| /ResourceTypes | Describe available resource types and schemas |
| /Schemas | Describe attribute definitions for each resource type |
SCIM and SSO: Complementary Protocols
Okta, Entra ID, Google] end subgraph "SCIM (Lifecycle)" Users -->|provision/deprovision| AIPlatform[AI Platform] end subgraph "SSO (Authentication)" User[User] -->|SAML/OIDC| IdP2[IdP] IdP2 -->|assertion/token| AIPlatform end
| Protocol | What it handles | When it runs |
|---|---|---|
| SSO (SAML/OIDC) | Authentication — who can sign in | At login time |
| SCIM 2.0 | Lifecycle — which accounts exist | When users join, change roles, or leave |
SSO and SCIM work together: SCIM creates the account before the user's first login, SSO authenticates the user at login time, and SCIM deactivates the account when the user leaves (1Kosmos 2026).
SCIM 2.0 Endpoints for AI Platforms
/Users endpoint
| Operation | HTTP method | SCIM path | What it does |
|---|---|---|---|
| Create user | POST | /Users | Create a new user account |
| Get user | GET | /Users/{id} | Retrieve user details |
| List users | GET | /Users?filter=... | List users with filtering |
| Update user | PUT | /Users/{id} | Replace all attributes |
| Patch user | PATCH | /Users/{id} | Update specific attributes (e.g., active=false) |
| Delete user | DELETE | /Users/{id} | Remove user account |
/Groups endpoint
| Operation | HTTP method | SCIM path | What it does |
|---|---|---|---|
| Create group | POST | /Groups | Create a new group (e.g., "AI-Admins") |
| Add member | PATCH | /Groups/{id} | Add user to group |
| Remove member | PATCH | /Groups/{id} | Remove user from group |
| List groups | GET | /Groups?filter=... | List groups with filtering |
Standard user attributes
| Attribute | Description | Required |
|---|---|---|
| userName | Unique login identifier | Yes |
| displayName | Full name for display | Yes |
| emails | Email addresses (work, home) | Yes |
| active | Account active/inactive | Yes |
| name.givenName | First name | No |
| name.familyName | Last name | No |
| title | Job title | No |
| groups | Group memberships | No |
User Lifecycle Management
| Lifecycle event | IdP action | SCIM call | AI platform response |
|---|---|---|---|
| User joins | IdP creates user | POST /Users | Create account, assign default role |
| Role change | IdP updates groups | PATCH /Groups/{id} | Update permissions, access level |
| User leaves | IdP deactivates | PATCH /Users/{id} (active=false) | Deactivate account, revoke sessions |
| User deleted | IdP removes user | DELETE /Users/{id} | Remove account, delete data per policy |
The critical event is deactivation. When an employee leaves, the IdP sends PATCH /Users/{id} with active=false. The AI platform must immediately:
- Deactivate the account
- Revoke all active sessions and tokens
- Disable API access
- Retain data per retention policy (do not delete immediately — may need for audit)
Implementation Best Practices
| Practice | Why it matters |
|---|---|
| Support filtering (filter=userName eq "john") | IdPs use filtering to find existing users before creating |
| Implement pagination (startIndex, count) | Enterprise directories can have thousands of users |
| Handle PATCH correctly | Partial updates are the most common SCIM operation |
| Return proper SCIM error responses | IdPs rely on error codes for retry logic |
| Support both PUT and PATCH | Some IdPs use PUT, others use PATCH — support both |
| Validate SCIM tokens | SCIM endpoints must authenticate the IdP, not end users |
| Log all SCIM operations | Audit trail for compliance |
| Handle rate limiting | IdPs may send burst updates during directory sync |
| Support group membership changes | Role-based access depends on group sync |
| Implement deactivation, not deletion | Deactivation preserves audit trail; deletion loses it |
SCIM Authentication
SCIM endpoints are called by the IdP, not by end users. Authentication options:
| Method | How it works | Use case |
|---|---|---|
| Bearer token | IdP sends a pre-shared token in Authorization header | Simple, common |
| OAuth 2.0 client credentials | IdP gets an access token from the AI platform | More secure, token rotation |
| Mutual TLS | Both sides present certificates | Highest security, enterprise requirement |
The SCIM token must be separate from user authentication tokens. It is a service-to-service credential that should be encrypted at rest and rotated regularly.
Enterprise Onboarding With SCIM
When an enterprise customer onboards to an AI platform with SCIM:
- Admin configures SSO: Connects IdP (Okta, Entra ID) to AI platform via SAML or OIDC
- Admin configures SCIM: Enters SCIM endpoint URL and bearer token in IdP
- IdP syncs users: IdP sends all assigned users to AI platform via POST /Users
- IdP syncs groups: IdP sends group memberships via POST /Groups and PATCH
- Users can sign in: SSO authentication works because accounts already exist
- Ongoing sync: IdP sends updates as users join, change roles, or leave
This eliminates manual account creation. The IT admin assigns users to the AI platform app in the IdP, and SCIM handles the rest (WorkOS 2026).
FAQ
What is SCIM 2.0 and why do AI platforms need it?
SCIM 2.0 (System for Cross-domain Identity Management) is an open standard that automates user provisioning between identity providers (Okta, Entra ID) and applications. AI platforms need SCIM because enterprise customers require automated user lifecycle management — creating, updating, and deactivating accounts without manual IT intervention.
How does SCIM work with SSO for AI platforms?
SCIM and SSO are complementary. SSO (SAML or OIDC) handles authentication — who can sign in. SCIM handles the account lifecycle — which accounts exist, what groups they belong to, and when they are deactivated. SSO decides who may sign in now; SCIM decides which accounts exist and keeps them in sync.
What SCIM endpoints must an AI platform implement?
An AI platform must implement /Users (create, read, update, delete, list) and /Groups (create, read, update, delete, list, add/remove members). The platform must also support filtering (e.g., filter=userName eq 'john'), pagination, and SCIM schema attributes (userName, emails, displayName, active).
How does SCIM handle user deactivation in AI platforms?
When a user leaves the company, the IdP sends a SCIM PATCH or PUT request setting active=false. The AI platform must immediately deactivate the account, revoke active sessions, and disable API access. This ensures departing employees cannot access AI tools after offboarding.
Is SCIM 2.0 required for enterprise AI platform sales?
SCIM 2.0 is not legally required but is a hard requirement for most enterprise customers. Without SCIM, IT teams must manually create and deactivate accounts, which fails security audits. Enterprise customers typically require both SSO and SCIM before purchasing.
Want a self-hosted AI company brain that does all of this out of the box?
Book a demo →