When Someone Leaves

Read as far as you need. Each part adds detail, and every part leads to the same conclusion.

The keys to your building

Picture your company as a building. People come and go: staff, contractors, partners, customers.

Now picture how most companies hand out keys. Every door has its own key cabinet with its own keeper, and each keeper decides for themselves who gets a key and keeps their own list. It works, until someone leaves. Then someone has to remember every cabinet. Miss one, and a contractor’s key still opens the stockroom two months after they left.

The fix is not better cabinets. It is one front desk that decides who may open which door, and takes a key away the moment it should no longer work. Every door asks the front desk. Nobody else decides.

Two different questions

Letting someone in involves two questions, and they belong to two different places:

Are you who you say you are? That is a passport office. It checks identity, and nothing else. It has no idea which floors you may enter — and you would not want it to.
What may you do, right now? That is the front desk. It knows every rule and every badge, and it can take a badge away at any moment.

In technology, the passport office is an identity provider — Microsoft Entra, Okta, Google, LinkedIn or your own directory. The front desk is an authorisation server: Apiway.

What a person may do — which customer they act for, which teams they are in, what they have been granted, what their plan allows — lives in Apiway and nowhere else. None of it is handed to an identity provider, so no identity provider learns anything about your system: not your APIs, not your teams, not who may reach what. That is also why you can use as many identity providers as you like — staff with Entra, a partner’s people with Okta, contractors with Google — all governed by one permission model.

Why copying the rules everywhere fails

The common alternative is to let the passport office send its lists to every door, and let each door turn them into its own rules. Each door then keeps a copy.

A copy is right on the day it is made. After that it drifts: someone edits one door by hand, another misses an update, and there are many versions of the truth, each with its own keeper. Call the one place that is meant to be right the golden source; every copy that also decides is a silver source. Silver sources are how access outlives the people it was granted to. With more than one passport office it gets worse: each sends its own lists, there is no single answer to “who can get in where”, and every passport office has to know your floor plan.

In technology, this copying is usually done with SCIM: the identity provider creates accounts in each product and pushes group memberships into it, and the product turns groups into permissions. Running GitHub Enterprise with managed users is a familiar example. It works with one provider and one product, and it means:

The identity provider becomes your permission model, so it has to know your teams, projects and customers as groups.
One provider per product. Partners and contractors who sign in elsewhere end up as guests.
A connector per product, each with its own group mapping kept in step by hand.

Apiway does not work that way, on purpose. It only asks the identity provider whether the person is who they say they are. There is no directory synchronisation to set up, because there is nothing to synchronise.

Disabled in their identity provider

A person disabled in their identity provider can no longer authenticate, so they cannot sign in again — whichever provider they used.

Ended in Apiway

Everything a person may do is decided in Apiway, on every request, against what is in force at that moment. So whatever you change takes effect on their next call:

You change	Their next call
Their customer (tenant) is disabled	`401`
The subscription they call through is disabled or revoked	`401`
Their identity is disabled	`401`
They are moved out of a team, or a grant is withdrawn	`403` for every operation it covered

Disabling an identity is one call you can make from your own offboarding, so a leaver process in your HR or identity tooling can end their Apiway access in the same step: a JSON Patch on the identity in the Identities API (PATCH /v1/{principalId}) that sets its state to disabled.

There is no cache of permissions to wait out and no token to hunt down: the grant is checked again on every request, for delegated tokens, machine tokens and API keys alike. See Revocation & Token Lifetime for how that resolution works.

The bounds that remain

Stated plainly, so you can decide what to do about each:

Tokens already issued. Someone disabled only in their identity provider keeps the access token they hold until it expires — 3600 seconds by default — and an application holding a refresh token on their behalf can renew it without signing in again. Coming: on renewal, Apiway checks with their identity provider, so leaving it ends everything within one token lifetime. Until then, one action covers it: disable their identity in Apiway, and every token they hold, on every API, stops working on its next use.
Credentials they handled. Client credentials belong to a subscription, not to a person, so a person leaving does not end them. If the person who left had seen a secret, rotate it — the new credentials take over without downtime — or revoke it at the standard endpoint (/oauth2/v2/revoke).