How do I add SCIM provisioning alongside SSO?

To add SCIM provisioning alongside SSO, you typically need to configure two separate integrations with your Identity Provider (IdP):

1. SSO for authentication
2. SCIM for user/group provisioning

They’re related, but they do different jobs:

• SSO = lets users sign in with the IdP
• SCIM = automatically creates, updates, and deactivates users/groups in your app

High-level steps

1) Set up SSO first

In your IdP and app:

• Create the SSO app/integration
• Configure:
  • ACS/Reply URL
  • Entity ID / Audience
  • SAML certificate or OIDC client credentials
• Test login works for at least one user

2) Enable SCIM in your app

Your app needs to expose a SCIM endpoint, usually:

• POST /scim/v2/Users
• PATCH /scim/v2/Users/{id}
• DELETE /scim/v2/Users/{id} or deprovision via active=false
• Optional group endpoints:
  • POST /scim/v2/Groups
  • PATCH /scim/v2/Groups/{id}

You’ll also need:

• A SCIM base URL
• A bearer token or API token for the IdP to authenticate to your SCIM API
• Support for SCIM resources like:
  • User
  • Group
  • active, userName, name, emails

3) Configure SCIM in the IdP

In the IdP admin console, enable provisioning for the same app or a separate provisioning integration.

You’ll usually enter:

• SCIM base URL: https://yourapp.com/scim/v2
• Authentication token
• Optional:
  • attribute mappings
  • group mappings
  • deprovisioning behavior

4) Map attributes

Make sure IdP fields map to your app fields, commonly:

• userName → email or username
• name.givenName
• name.familyName
• emails[type eq "work"].value
• active
• externalId

If you support groups:

• group name
• members
• role/entitlement mappings

5) Decide on identity matching

You need a stable way to link SCIM users to existing accounts. Common approaches:

• Match by userName/email
• Store SCIM externalId
• Store IdP id in your user record

Important: don’t rely only on email if users might change addresses.

6) Test lifecycle flows

Verify these cases:

• User created in IdP → created in app
• User updated in IdP → updated in app
• User disabled in IdP → deactivated in app
• User added/removed from group → group membership updates

Common implementation pattern

If you already have SSO and user accounts, SCIM usually works like this:

• SSO login creates/links the user on first sign-in if needed
• SCIM pre-provisions users before first login
• SCIM keeps user profile and access in sync
• SSO remains the authentication source
• SCIM becomes the provisioning source

Things to watch for

• Duplicate accounts: use a consistent matching key
• Deprovisioning: prefer soft-delete or active=false
• Groups: not all IdPs send groups the same way
• Delayed sync: SCIM is often near-real-time but not instant
• Security: protect SCIM endpoints with strong auth and TLS

If you’re using a specific IdP

The setup differs slightly for:

• Okta
• Microsoft Entra ID / Azure AD
• Google Workspace
• JumpCloud
• OneLogin

If you want, I can give you a step-by-step guide for a specific IdP or help you design the SCIM API endpoints and data model for your app.