SCIM deprovisioning must revoke identity, group, and application access together
Removing a user from an identity provider is not the end of access removal. The account may still exist in a SaaS application, the application may cache group membership, and a service account created from the user's role may still hold credentials. SCIM provides a standard way to propagate identity changes, but the receiving application decides which data it deletes, disables, or retains.
RFC 7644 defines the SCIM protocol for provisioning and managing users and groups. A client can create or update resources over HTTP, and can remove them with DELETE when the service provider supports deletion. Many enterprise deployments instead send an active: false patch so audit records and references remain available. Either approach can be valid, provided application authorization is tied to the resulting account state.
The identity record and the authorization record are different
A SCIM user resource can contain attributes, groups, and enterprise extensions. An application often copies or transforms those values into local roles, team memberships, or project grants. The copy creates a second state that can survive a correct SCIM update. If the user becomes inactive but a local project grant remains active, the next login or token refresh may still receive access.
Group removal needs the same treatment. Removing a user from a group in the identity provider should eventually remove the access inherited from that group. If the application stores group identifiers only at the time of login, existing sessions can keep the old decision. Long-lived access tokens and API keys need an expiry or revocation path that does not depend on the next interactive sign-in.
Application-specific objects create another dependency. A user may be the only owner of a project, the creator of a report, or the holder of an API key. Disabling the identity should not silently delete business data. It should prevent the identity from acting, while assigning any required ownership transfer or administrative cleanup to a documented process.
Treat deprovisioning as a state machine
Use explicit states such as active, login disabled, tokens revoked, resources reassigned, and deletion eligible. A SCIM deactivation moves the user to login disabled and starts the remaining steps. The application should expose a verifiable final state rather than reporting success as soon as the profile update is stored.
Idempotency matters because identity integrations retry. A repeated DELETE or inactive patch must not create a new user, duplicate an audit record, or reopen a disabled account. If the integration receives an unknown error, it should reconcile by reading the user's state before sending another mutation. Blind retries can race an owner transfer or a manual recovery.
Bulk operations add scale and urgency. A group change affecting hundreds of users can produce many partial failures. The application should return per-resource results where the protocol allows it and preserve the failed subset for retry. A successful HTTP response for the bulk request does not prove that every member lost the intended access.
Test the paths that leave authority behind
Start with an account that has a personal token, a shared project membership, and a session in a browser. Deactivate the account through SCIM and then test each path separately. The password login should fail, the existing session should be rejected or expire within the defined window, the personal token should be revoked, and the project should no longer accept the identity.
Repeat the test after removing the user from a group without disabling the account. The user should immediately lose group-derived application permissions while retaining any direct permission granted independently. This separates user-level deprovisioning from group-level entitlement removal. It also reveals applications that flatten both concepts into a single local role.
Compare logs across the identity provider and the application. The identity provider should show the exact SCIM request and response. The application should show the resulting account state and the authorization decision for the test request. Store correlation identifiers so an operator can connect the two records without exposing credentials.
Keep a small verification record
For each critical application, document the supported SCIM operations, the deactivation representation, session and token behavior, owner-transfer process, and maximum time allowed for access removal. Recheck that record after upgrades. A change to an authentication library or a role mapping can break a control that worked during the last audit.
The defensive test is straightforward: deprovision a test identity and try to use every access path it held. Access should fail for the correct reason, and any surviving object should belong to a documented recovery or ownership process. SCIM handles the message. The application must complete the security outcome.
Top comments (0)