How do I handle SSO user provisioning and deprovisioning?

A good way to handle SSO user provisioning and deprovisioning is to treat authentication and lifecycle management as separate concerns:

• SSO answers: “Who is this user?”
• Provisioning/deprovisioning answers: “What access should this user have right now?”

Recommended approach

1. Use Just-in-Time (JIT) provisioning for first login

When a user signs in via SSO for the first time:

• Verify the SSO assertion/token
• Create a local user record if one doesn’t exist
• Map key identity fields:
  • external IdP user ID / subject
  • email
  • name
  • organization/tenant
  • groups/roles if available
• Assign a default role or access policy

This avoids manual account creation.

2. Keep a stable external identity link

Do not rely on email alone as the unique identifier. Instead, store the IdP’s immutable user identifier, such as:

• SAML NameID or a specific attribute
• OIDC sub
• SCIM externalId

Emails can change; the external subject usually should not.

3. Use SCIM or directory sync for lifecycle management

For reliable provisioning and deprovisioning, support SCIM 2.0 if possible.

With SCIM, the IdP can:

• create users
• update attributes
• disable/deactivate users
• remove group memberships

This is the cleanest approach for enterprise SSO.

4. Deprovision by deactivating, not deleting immediately

When a user leaves or loses access:

• mark the account as disabled/inactive
• revoke sessions/tokens
• remove application access
• retain audit history and ownership of resources

Delete later only if your retention policy requires it.

5. Reconcile on login if SCIM is not available

If you only have SSO but not SCIM:

• On each login, check whether the user is still allowed
• Validate group/role claims if present
• Suspend access if claims indicate removal
• Optionally perform periodic sync against the IdP/directory

This is less reliable than SCIM, but workable.

Practical lifecycle model

A simple model is:

• Pending: not yet logged in
• Active: authenticated and allowed
• Suspended/Disabled: blocked from login, data retained
• Deleted: removed after retention period

Important security rules

• Re-check access on each login, not just on first provisioning
• Invalidate active sessions when user is deprovisioned
• Prefer short-lived tokens
• Sync group/role changes quickly if you use role-based access
• Log all provisioning/deprovisioning events

Common patterns

Enterprise SaaS

Best practice:

• SSO for authentication
• SCIM for provisioning/deprovisioning
• Group-based access control
• SAML or OIDC + SCIM

Smaller apps

If SCIM is too heavy:

• JIT create users on login
• Periodic background sync with the IdP
• Admin UI for manual disable/delete
• Session revocation on access changes

Example policy

• First SSO login creates the user
• Access is assigned based on IdP group membership
• SCIM disables the user when removed from the group
• Disabled users cannot log in, but their content remains preserved
• After 90 days, delete if required by policy

If you want, I can also give you:

1. a reference architecture for SSO + SCIM,
2. a database schema for user lifecycle states, or
3. an implementation flow for SAML/OIDC provisioning.