Chapter 12: User Lifecycle Management — Provisioning, SCIM, and the De-Provisioning Problem

This is Part 12 of a chapter-by-chapter walkthrough of my book OpenID: Modern Identity for Developers and Architects. In the previous chapter we covered MFA and step-up. Chapter 12 is about what happens to accounts between the moment they're created and the moment they should no longer exist.

12.1 — Provisioning (JIT, Bulk, and the Hybrid Reality)

Just-in-time (JIT) provisioning creates accounts on first login: a user authenticates via their corporate IdP, the application sees claims it hasn't seen before, and creates a record. Fast, low-friction, great for "click to get in." The tradeoff is that the application has whatever attributes the IdP happened to include — no more, no less.

Bulk provisioning uploads a known user list ahead of time (CSV, API import). Higher friction but lets you pre-seed groups, permissions, and approvals. Required when compliance demands that every account be reviewed before it exists.

Real enterprises use both. Bulk for initial migration and audited populations; incremental sync (via SCIM) for ongoing changes.

12.2 — SCIM: The Standard API for User Sync

SCIM (System for Cross-domain Identity Management, RFC 7643/7644) is a REST protocol for provisioning users and groups across systems. Rather than every SaaS app implementing its own provisioning API, SCIM gives a common vocabulary: POST /Users, PATCH /Users/{id}, DELETE /Users/{id}, with a standard schema for common attributes.

If your enterprise IdP is Entra ID or Okta and your SaaS vendor says "we support SCIM," you get automatic provisioning and de-provisioning of users and groups in minutes rather than in a bespoke integration project. Chapter 12 walks through the typical deployment pattern, push vs. pull, and the attributes you should push vs. leave alone.

12.3 — De-Provisioning: The Part That's Always Broken

Creating accounts is exciting. Removing them is tedious, so it's the part most teams get wrong. When an employee leaves, you need to: disable credentials at the IdP, revoke all refresh tokens, invalidate active sessions in every application, remove group memberships, revoke API keys, and audit for anything the user personally owned.

The nasty corner is orphaned access: the user is removed from the directory, but some application's SCIM sync hasn't run, or the sync skipped that user for some reason, or a personal OAuth grant to a third-party app persists. These are the ghost accounts that appear in every incident response post-mortem.

12.4 — Role Mapping

Roles and groups flow from IdP to application via claims (typically groups or a custom claim). The application reads these and maps them to its own permission model. Simple in theory; full of sharp edges in practice: group naming collisions across IdPs, role explosion as teams reorganize, stale group memberships that grant access long after the project ended.

The principle that keeps this under control: your application's permission model should be small and stable; your role-to-permission mapping is where you absorb organizational complexity.

12.5 — Identity Architecture for SaaS

Multi-tenant SaaS adds a dimension. Each tenant brings their own IdP, their own groups, their own provisioning rules. The chapter walks through the choices: shared vs. isolated identity stores, the tenant bootstrapping problem ("how does the admin log in before federation is configured?"), BYOI (Bring Your Own IdP) federation, and the token-audience discipline that keeps one tenant's tokens from ever being valid at another tenant's endpoints.

What Chapter 12 Sets Up

After Chapter 12 you should know which provisioning model fits which deployment, when SCIM is worth implementing yourself vs. relying on your vendor, and how to design a de-provisioning process that actually works when a laptop has to be wiped at 5 PM on a Friday.

Next up — Chapter 13: Threat Modeling OpenID Systems. We enter Part V and start thinking like attackers: token theft, replay attacks, CSRF on the state parameter, redirect abuse and mix-up attacks. The shift from "how does it work" to "how does it break."