{"id":6952,"date":"2026-09-24T05:26:14","date_gmt":"2026-09-24T05:26:14","guid":{"rendered":"https:\/\/areeblog.com\/?p=6952"},"modified":"2026-09-24T05:26:14","modified_gmt":"2026-09-24T05:26:14","slug":"why-sso-works-but-scim-deprovisioning-fails","status":"publish","type":"post","link":"https:\/\/areeblog.com\/why-sso-works-but-scim-deprovisioning-fails\/","title":{"rendered":"Why SSO Works but SCIM Deprovisioning Fails"},"content":{"rendered":"

\"Why<\/p>\n

The most dangerous SCIM incident can begin with a green SSO test. A user can authenticate successfully through SAML or OIDC while the same employee remains active inside the application because the provisioning path is broken. SSO proves that authentication<\/a> works; it does not prove that identity lifecycle management works.<\/p>\n

SCIM runs through a separate API connection between an identity provider and the application. Its job is to create users, update their attributes, and change their lifecycle state. Microsoft Entra, for example, can disable a SCIM user by setting active=false<\/code>, while Okta uses the same soft-deactivation model rather than simply deleting the account. (Microsoft Learn<\/a>, Okta Developer<\/a>)<\/p>\n

That distinction explains a large class of \u201cSCIM is working, but offboarding is not\u201d incidents. In practice, the failure can sit in the trigger, scope, credentials, identity matching, request format, target API, or the application’s own session and authorization logic.<\/p>\n

SSO and SCIM are two different control paths<\/h2>\n

A typical login looks roughly like this:<\/p>\n

User \u2192 IdP \u2192 SAML\/OIDC \u2192 Application \u2192 Authentication<\/code><\/pre>\n
Deprovisioning is different:<\/p>\n
Directory \u2192 IdP \u2192 SCIM client \u2192 SCIM API \u2192 Application user state<\/code><\/pre>\n
A certificate, SAML configuration, OIDC client, or login claim can therefore be perfectly healthy while a SCIM bearer token has expired or the SCIM endpoint rejects requests.<\/p>\n
This is why \u201cthe user can still log in\u201d is not enough evidence to diagnose a provisioning problem. The two paths have to be tested independently.<\/p>\n