## TL;DR
The IdP could not kill the app session, usually because the app's session API errored or the connector broke. Revoke the user's sessions directly in the app's admin console or API, then return to the IdP and retry the revocation.

```text
"failed to revoke SSO session" after deprovision
```

## Use this when
- The deprovision log shows a session-revocation failure for a specific app.
- The user is deprovisioned but sessions remain.
- The IdP retry keeps failing.

## Not for this skill when
- The account was never deprovisioned. Fix the account step first.
- Sessions are already gone. Then the log entry is stale.
- The failure is on license removal. That is a separate step.

## Steps
1. Note which app failed in the deprovision log. Verify: you know the exact app and user.
2. Revoke the user's sessions in the app's admin console or API. Verify: the app shows no active sessions.
3. Return to the IdP and retry the session revocation step. Verify: it reports success.
4. Verify no sessions show for the user in either system. Verify: both lists are empty.
5. Document the manual step for that app in the offboarding runbook. Verify: the next offboarding covers it.

## Variant phrasings
### SSO session revoke failed
The action-first phrasing.
### sessions survive deprovision
The state-first search.
### revoke tokens failed
The mechanism-first phrasing.

Compatibility: Any IdP with per-app session revocation; app session APIs vary.

## Why it happens
Session revocation depends on each app's integration. A broken connector, a changed API, or an app-side outage leaves the IdP's revocation call failing while the session lives on.

## Edge cases / pitfalls
- Apps without a session-revoke API: disable the account and wait for token expiry, and document the window.
- Revocation succeeding but the UI caching the old state; re-query before concluding it failed.
- Refresh tokens surviving session revocation on some apps; revoke those separately.
- The connector fixed later, making the manual step unnecessary; keep the runbook current.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_zwTwagpCuql9T-ywl5moUg