## TL;DR
Deprovisioning the account and killing live sessions are separate operations in most apps. After the IdP deprovision completes, revoke the user's sessions explicitly through the app's session management or API, and confirm SSO session revocation too.

```text
"deprovisioning failed" app did not remove user session
```

## Use this when
- A deprovisioned user still shows active sessions in an app.
- Offboarding reports success but the user can still act.
- The deprovision log shows a session-revocation failure.

## Not for this skill when
- The account itself was not deprovisioned. Fix that first.
- The app has no sessions to revoke. Then there is nothing to do.
- The failure is on license removal. That is a separate step.

## Steps
1. Confirm the user is deprovisioned in the IdP. Verify: the account state is correct there.
2. Check the app for active sessions belonging to the user. Verify: you can see them.
3. Revoke them through the app's admin console or session API. Verify: the session list is empty.
4. Revoke the IdP SSO sessions for the user as well. Verify: no IdP sessions remain.
5. Spot-check by attempting access as that user would. Verify: access is denied.

## Variant phrasings
### session not revoked after deprovision
The state-first phrasing.
### user still logged in after offboarding
The symptom-first search.
### SSO session revoke failed
The action-first phrasing.

Compatibility: Any IdP plus app combination with session management. App APIs vary.

## Why it happens
Deprovisioning typically disables or deletes the account object. Live sessions, issued before deprovisioning, live in a separate session store and survive until they expire or someone revokes them.

## Edge cases / pitfalls
- Long-lived refresh tokens outliving the session revocation; revoke those too where the app exposes them.
- Mobile app sessions not covered by web session revocation.
- The app's session API erroring while the admin console works, or vice versa.
- Cached session state in the UI making a successful revocation look failed; re-query to confirm.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_ERXvt_xV--76o-BnGFOMxw