Verify Membership Removal After SCIM

A SCIM deprovision event is a request to change identity state. It does not prove that every active app session, token, cache, or queued job has stopped. RFC 7644 defines the SCIM protocol operations, while the application decides how those changes affect its permissions.

Deprovision timeline

Record the time a user is disabled or removed at the identity provider. Then track these checkpoints in the application.

The product may have different rules for disabling a whole account and removing one group. Write those differences down. A user in two tenants may lose access to A but retain B. Do not delete the global user record if that would remove legitimate B access.

Test an owned sequence

Create two synthetic tenant memberships for one user. Start a session and queue a harmless A task. Send an approved SCIM disable or membership removal through a test IdP. Confirm the A grant changes, then test an A read, a B read, and the delayed task. Repeat with a duplicate SCIM event and an out-of-order update. The app should have a documented reconciliation path.

The OWASP Session Management Cheat Sheet supports server-side session controls. This timeline reveals the gap between IdP state and app authority. Do not claim instant revocation unless tests prove it for the configured provider and every relevant token type. Keep production user accounts out of this exercise.

Use the configured test IdP to capture two synthetic event shapes without real users: account disable and removal from A's mapped group. For each, record the provider request, connection ID, matched app user, A and B membership before and after, active-session decision, and delayed-job result. The group-removal fixture must not silently delete B's independent grant. The account-disable fixture follows the product's separately documented global-session rule. Repeat a duplicate delivery and reconcile out-of-order events; do not infer instant revocation from a successful SCIM response.