SCIM deprovisioning: make account disablement remove every usable authority

SSO answers how a login assertion is accepted; provisioning manages the resource lifecycle. An employee leaving a directory must lose usable application authority even if they never attempt another login. A connector can correctly update a User resource while a cached session, API credential or queued export keeps working. Test those paths directly.

Draw the authority inventory before implementing the connector: browser sessions, refresh grants, personal tokens, resource grants, role caches, delegated jobs and service-owned credentials. Label which are user-bound and which are independently owned service identities. Do not destroy a shared service identity merely because its creator leaves; require an accountable ownership transfer instead.

SCIM id is assigned by the service provider; externalId is supplied by the provisioning client and scoped to its provisioning domain. The User active attribute describes administrative status; its concrete effect is defined by the provider. Users.groups is read-only; membership changes belong in the relevant Group resource’s members attribute.

For this application, a connector credential selects Acme before resource lookup. Map that connector and the stable external user identity to the provider’s immutable user ID. Email/userName changes must not transfer another person’s resources or select a different tenant. Two organizations may legitimately use the same email or externalId. Store and test their mappings independently.

Scope connector permissions to the enrolled tenant and required lifecycle operations. Protect and rotate its secret, bound directory queries and returned attributes, and record its actor identity for changes. Reject requests attempting to override the tenant in request content. Connector authentication should not reuse an ordinary end-user login session.

SCIM PATCH uses application/scim+json and the PatchOp schema. Apply its Operations in order and atomically for the target resource; a failed operation must not leave a partial resource update. Discover supported features through ServiceProviderConfig. When versioning is supported, use the resource ETag and If-Match to detect concurrent modification; treat versions as opaque validators, not sortable counters.

A User active=false replacement and a Group member removal are separate resource changes. SCIM does not make that pair one cross-resource transaction. Nor does a protocol success automatically revoke a product’s existing sessions or remote jobs. Document which application effects are synchronous, which are pending, and how their completion is observed.

The minimal request below illustrates a resource update only. Authentication credentials and real resource IDs come from the configured connector; no runnable server is supplied by this snippet.

PATCH /scim/v2/Users/u-acme-42 HTTP/1.1
Host: app.example
Content-Type: application/scim+json
If-Match: W/"user-version-17"

{"schemas":["urn:ietf:params:scim:api:messages:2.0:PatchOp"],"Operations":[{"op":"replace","path":"active","value":false}]}

In the accompanying model, one local transaction changes active state, advances an authorization epoch, replaces local grants, revokes credentials and cancels pending user jobs. The event receipt commits with that transition. An interruption before commit leaves the previous complete state, so a retry can safely try again. A half-disabled account is not an acceptable success state.

At request time, compare credential epoch with the current user epoch and check the current grant needed for the action. At job execution, check again rather than trusting authority captured at enqueue time. Cancellation is useful cleanup, but the worker’s effect-time check is an independent defense if cancellation delivery is missed.

Re-enabling a user is a new explicit transition. It must not revive an old bearer credential, refresh grant or pending job. Restore only approved present-day grants, issue new credentials through the normal flow, and retain the prior revocation history. An effect completed before disable is historical fact; disable does not automatically reverse it.

The epoch only helps if every enforcement point reads it. Session middleware, API token validation, GraphQL resolvers, exports and background workers must all compare the credential’s epoch with the user’s current one, or call a shared function that does. The session guide at /domains/identity-crypto/authentication/session-lifecycle/ shows the same version check for browser sessions.

A local disable does not reach sessions held by other applications. The OpenID Shared Signals Framework and the Continuous Access Evaluation Profile (CAEP), both final specifications since August 2025, let an identity provider push signed Security Event Tokens (SETs) such as session-revoked and credential-change to every service that subscribed to a stream. Your application can be a receiver, ending its own sessions when the identity provider says so, and a transmitter, telling downstream services when it disables a user.

For OAuth tokens your application holds at other services, such as integration refresh tokens stored for the departing user, call each authorization server’s revocation endpoint (RFC 7009). If your application issues tokens, give resource servers a way to learn about revocation, such as short access-token lifetimes plus token introspection (RFC 7662), because a self-contained JWT stays valid until it expires; the JWT guide at /domains/identity-crypto/authentication/jwt-attacks/ covers access-token lifetimes.

The receiver below verifies each SET against the transmitter’s keys, refuses anything that is not explicitly typed as a security event, acts once per jti because deliveries are retried, and revokes sessions for the subject named in sub_id. It was tested with jose 6.2.12 on Node.js 26: a session-revoked event revokes once even when delivered twice, and a forged signature, a plain JWT type, another issuer and another audience are rejected before any revocation.

import {createRemoteJWKSet, jwtVerify} from 'jose';

const SESSION_REVOKED = 'https://schemas.openid.net/secevent/caep/event-type/session-revoked';
const CREDENTIAL_CHANGE = 'https://schemas.openid.net/secevent/caep/event-type/credential-change';
// The transmitter's issuer and JWKS come from its SSF configuration, set up when the stream was created.
const transmitterKeys = createRemoteJWKSet(new URL('https://idp.example/ssf/jwks'));

// POST /ssf/events (RFC 8935 push delivery, Content-Type: application/secevent+jwt).
// Answer 202 when this resolves; 400 when it throws.
export async function receiveSet(token, {seenJti, revokeSessions}) {
  const {payload} = await jwtVerify(token, transmitterKeys, {
    issuer: 'https://idp.example/',
    audience: 'https://app.example/ssf',
    typ: 'secevent+jwt', // SSF requires explicit typing, so an ID or access token is refused
    algorithms: ['RS256', 'ES256'],
  });
  if (!(await seenJti.add(payload.jti))) return 'duplicate'; // deliveries are retried: act once per jti
  const [[type, event]] = Object.entries(payload.events); // SSF: one event per SET
  if (type === SESSION_REVOKED || type === CREDENTIAL_CHANGE) {
    // sub_id names the subject, for example {format: 'iss_sub', iss, sub}; map it within the tenant.
    await revokeSessions(payload.sub_id, event.event_timestamp);
  }
  return 'accepted';
}

For repeated delivery, distinguish the same change from a conflicting reuse of an operation identifier. The model uses adapter-assigned event IDs plus monotonically ordered source versions; those are declared model assumptions, not SCIM-defined event fields. A real connector needs a supported source snapshot/version or reconciliation strategy before it can claim stale updates cannot reactivate users. RFC 9967 (May 2026) adds an optional SCIM profile for Security Event Tokens that a provider can use to signal changes asynchronously; check that your directory supports it before relying on it.

After an ambiguous network result, read current resource state and reconcile deliberately. Do not blindly resend a stale full-resource replacement that restores removed grants. Measure the time from authoritative disable to denial at each enforcement point, alert on stalled propagation, and retain enough identifiers to prove which tenant and identity were affected.

Keep the old session, token and queued job alive in the test environment before sending a lifecycle update. Try each after the change and after an application restart. Also test an unrelated tenant with a colliding email/identifier; broad accidental revocation is a defect too.

The identity-lifecycle downloadable project uses Python 3.11 or later and SQLite. Run python3 -m unittest -v test_lifecycle.py. Repair exercise.py, then compare reference.py after recording the failing boundaries. All 18 reference tests execute real local transactions, credentials and grants, and job-effect records.

The model uses normalized in-process provisioning snapshots and opaque credential IDs. It does not implement SCIM HTTP parsing, actual signed token verification or an external revocation service. Those limitations identify the next integration tests; they do not turn the local transaction tests into protocol compliance evidence.

Sources & further reading

The standards, specifications and documentation behind the guidance above. Each is the evidence for a claim on this page; consult it for detail beyond the defaults and versions listed here.

1. RFC 7643 — SCIM Core Schema, identifiers, active and groups. September 2015; updated by RFC 9865 and RFC 9967.
2. RFC 7644 — SCIM PATCH, versioning and multi-tenancy. September 2015; updated by RFC 9865 and RFC 9967.
3. RFC 7642 — provisioning and deprovisioning concepts. September 2015.
4. SQLite — transaction behavior used by the runnable model
5. OpenID Shared Signals Framework 1.0. Final, 29 August 2025.
6. OpenID Continuous Access Evaluation Profile (CAEP) 1.0. Final, 29 August 2025.
7. RFC 7009: OAuth 2.0 Token Revocation. August 2013.
8. RFC 8935: Push-based Security Event Token delivery. November 2020.
9. RFC 9967: SCIM profile for Security Event Tokens. May 2026.

Reference information

SCIM 2.0 RFC 7643/7644; the SQLite project models normalized events and is not a SCIM HTTP server.

Tags

SAML, SCIM and enterprise SSO

SDLC phase

Development

Role

Developers

ASVS 5.0.0 requirements

v5.0.0-7.4.2 · v5.0.0-8.3.2 · v5.0.0-8.4.1

Download this guide as Markdown

Continue exploring