How do I set up automatic user deprovisioning when a customer removes access in their IdP?

To automate user deprovisioning when a customer removes access in their IdP, you generally want to support SCIM 2.0 for lifecycle management.

Recommended setup

1) Use SCIM for provisioning and deprovisioning

Have the customer’s IdP send SCIM requests to your app:

• POST /Users → create user
• PATCH /Users/{id} → update user attributes
• DELETE /Users/{id} or active:false → deactivate user

For deprovisioning, most IdPs prefer disabling a user rather than hard-deleting them.

2) Treat deprovisioning as “inactive”

When a user is removed from the customer’s IdP:

• mark the user as inactive / suspended / deactivated
• revoke sessions and tokens
• block login
• keep account data for audit/compliance unless the customer explicitly requests deletion

This is safer than immediate deletion.

3) Map IdP identifiers to your user record

Store stable identifiers from the IdP, such as:

• SCIM userName
• SCIM id
• enterprise externalId
• tenant/customer org ID

This lets you match the same user reliably even if their email changes.

4) Revoke access immediately

On deprovision:

• invalidate active sessions
• revoke refresh tokens / API keys
• remove org memberships / roles
• stop background jobs or integrations tied to that user

5) Support group-driven access removal if needed

Some customers remove access via:

• removing the user from an assigned app group
• disabling the user in the IdP
• moving them out of a synced department/team

Your SCIM implementation should handle both:

• user disable
• membership changes that remove app access

6) Add a fallback if SCIM isn’t available

If a customer’s IdP doesn’t support SCIM, alternatives are:

• SAML SSO + Just-in-Time provisioning with periodic reconciliation
• directory sync via an admin API
• scheduled jobs to compare IdP membership against your app and deactivate missing users

But SCIM is the cleanest and most standard approach.

Practical deprovisioning flow

1. Customer admin removes user access in IdP.
2. IdP sends SCIM PATCH active=false or DELETE.
3. Your app receives webhook/API call.
4. Your system:
   • marks user inactive
   • revokes sessions/tokens
   • removes org/app permissions
5. User can no longer sign in.

Security and operational tips

• Make deprovisioning idempotent
• Log the source and timestamp of lifecycle changes
• Verify SCIM requests with bearer tokens or another auth method
• Rate-limit and validate inbound provisioning calls
• Decide whether to preserve or delete historical data

If you want, I can also give you:

• a SCIM endpoint design
• a database model for deprovisioning
• or examples for Okta, Azure AD, and Google Workspace.