Revocation
How access stops existing without synchronizing user lifecycle with the IdP.
When someone leaves the company, the IdP disables the account. Many systems copy that event into themselves, with webhooks or SCIM, and cut access locally. Xokepoint does not. Each IdP has a different event mechanism, with different authentication, delivery and retries, and maintaining that integration for each one only shortens a revocation that already happens on its own.
It happens on its own because no access lasts longer than a short token:
Revocation does not need to be instant, but it must happen without anyone stepping in. Each path has its own delay:
| What is revoked | Where | When it applies |
|---|---|---|
| User in the IdP, headless | Customer IdP | On the next exchange, within 5 minutes |
| User in the IdP or group membership, interactive | Customer IdP | Not by itself: after 24 hours without use or at the end of the consent. Block the person to cut at once |
| Person blocked on the agent | Publication in the Admin | Consents and machines at once; on the next call |
| Machine or consent revoked | Harness sessions in the Admin | On the next call |
| Refresh token or code used twice | Automatic | The machine at once; on the next call |
| Harness login off in the connection | Admin | On the next refresh; access tokens expire within 5 min |
| Delegation, capability or resource | Publication in the Admin | On the next call |
| Expiration of a relation | Condition in OpenFGA | On the first call after the date |
| Agent disabled (kill switch) | Admin | On the next call and the next exchange |
| Agent key replaced | Admin | On the next exchange; tokens already issued expire within 5 min |
| Identity connection | Admin | On the next call and the next exchange |
Relations apply on the next call because the PDP queries them on every decision, including the delegation that the token exchange already checked. The short token covers what Xokepoint does not see, and the per-call query covers what it sees.
The interactive mode
A coding harness renews its token with a refresh token, and a refresh does not reach the IdP. Group membership is read only at login. So a person disabled in the IdP, or removed from an eligible group, keeps a logged-in machine until 24 hours pass without use or the consent ends. When access must end now, block the person on the agent: publishing the block revokes their consents and machines, and they cannot log in again (Who can delegate).
Each login is a grant of one machine, and the token carries its grant_id. The PEP checks on every call that the grant and the consent are still active, so revoking one machine stops it on its next call without touching the other machines of the person.
Where it becomes visible
The issuance record is where revocation in the IdP becomes visible: the exchange fails with the reason and the subject, and becomes a signal in the Inbox (Observability).