IntegrAuth Academy
Identity, security and practical AI — free, from zero. Byte-sized lessons, real diagrams, hands-on labs, zero fluff. Two programs, each with its own exam and certificate.
English is hard? Your browser can translate this page into Tamil, Telugu, Kannada, Malayalam or Hindi. Tech words stay in English so you learn the real names.
How?
- Chrome on phone: ⋮ menu → Translate
- Chrome on computer: right-click → Translate to …
- Edge: the translate icon in the address bar
SCIM provisioning
Priya joins the company. Her account should exist before her first login. When she leaves, it should stop working at once. This is provisioning, and its shared language is SCIM. Your goal: explain how SCIM adds and removes accounts on time.
- SCIM pushes accounts into apps. It does not wait for a login.
- A leaver is one request that sets
active:false. - Requests can arrive twice, so the app must handle repeats.
- Keep the SCIM token on the server only.
Priya's last day is 30 June. The expenses app only makes accounts when people sign in. It never hears that she left. On 30 July her account still works. Anyone who knows her password can file claims in her name. Nobody is watching.
Push, don't wait
Most apps make an account the first time someone signs in. That is fine for a shopper. It is wrong for staff. You want Priya's account ready on day 1 and blocked on her last day.
The fix is inbound provisioning. A system upstream pushes accounts into your app. That system is the source of truth. For example, it is the HR directory that feeds your IdP (identity provider). When HR hires someone, it sends a create. When HR offboards someone, it sends a deactivate.
SCIM stands for System for Cross-domain Identity Management. It is a standard REST shape for users and groups. So any directory can talk to any app. A joiner is a POST /Users with active:true. A leaver is a PATCH that sets active:false. Nobody has to sign in first.
SCIM or JIT
The other style is JIT provisioning (just-in-time). The app makes the account at the first login. It is easy, but it reacts late. A leaver's account stays until someone remembers to remove it.
With SCIM, active:false usually makes the app block new sign-ins the moment HR offboards. This ends the Joiner–Mover–Leaver lifecycle well. One gap remains. Sessions and tokens already issued keep working until they expire. So also revoke live sessions.
| Dimension | SCIM (proactive) | JIT (reactive) |
|---|---|---|
| Timing | Account exists before the first login | Account is made at the first login |
| Removal | active:false blocks new sign-ins at once (in most apps) | Stays until someone removes it by hand |
Groups become roles
The directory also sends groups. A mapping turns the SCIM group Store-Managers into a role in your app. So Sam gets the right access on arrival and does not file a ticket. A change of group membership travels as its own request to /Groups. This is how personas stay in sync.
A hotel front desk. The guest list arrives before check-in, so the room is ready. At check-out, the key card is turned off. Nobody waits for the guest to come back.
Directories retry when they get no reply. Treat every delivery as at-least-once: it can arrive twice. Your endpoint must be idempotent. That means a repeat does no extra harm, like pressing a lift button twice: the lift still comes once. Use a stable id, so a retried create does not make a second account. The bearer token that allows these writes is powerful. Keep it on the server and limit it to one connection. Rotate it. It must never reach a browser.
active:false for the leaver. The user never signs in first.Go deeper: SCIM details
SCIM version 2 is defined in RFC 7643 and RFC 7644. A second create for the same userName must get a 409 (conflict) answer.
The meaning of active is set by each app. The RFC says true usually means "can log in" and false means "suspended". Test that your app really blocks sign-in.
A DELETE answers 204. The app may keep a hidden copy, but it must answer 404 for that user from then on. Many directories deactivate a leaver instead of deleting.
Go deeper: Ending sessions that are already open
SCIM changes the account. It does not tell other apps to drop a session that is already open. For that, apps can listen for signals. The OpenID Shared Signals Framework 1.0 and CAEP 1.0 became Final specifications in September 2025. CAEP defines a "session revoked" event. An app that gets this event ends the session.
You can also revoke refresh tokens and sessions with your IdP's own tools. Plan for it. A leaver's open sessions are the part SCIM does not fix.
🧪 Interactive lab — enable JavaScript to play with this one.
Designing joiner, mover and leaver flows for a real directory? Talk to our team about SCIM and lifecycle automation.