Skip to content

Revocation & Token Lifetime

“How fast can you cut someone off?” is the question every security review asks, and most platforms answer it with a token lifetime — wait for expiry, or accept a window.

Apiway answers it differently, because authorisation is not decided when a credential is issued. Every request asks two live questions: is this caller still allowed, and what may they reach right now.

Withdrawing access is effective on the caller’s next request — no waiting for a token to expire, no propagation delay, nothing to flush.

You withdrawEffect
A scope from an entitlementNext request
An entitlement from a consumerNext request
A subscription (revoked or suspended)Next request — there is no active subscription to authorise against
A credentialNext request

This holds across every credential type. A machine-to-machine token, a delegated (on-behalf-of) token and an API key are authorised the same way: the credential establishes who is calling, and what they may do is resolved at that moment from the entitlement service. The scope claim baked into a token at issuance is not authoritative, and neither is the set stamped at the last deployment — either of those would let a scope revoked since then keep working until the token expired.

Separately from entitlements, a token can be revoked directly at the standard endpoint (/oauth2/v2/revoke, RFC 7009) — for the case where the credential is compromised rather than the grant being wrong. See Standards & Conformance.

In practice the entitlement route is the one that matters. If a person leaves or a partner relationship ends, you withdraw what they may reach; every credential they hold stops working on its next use, whether or not you know how many tokens are outstanding.

Access tokens carry expires_in of 3600 seconds by default. Because authorisation is re-resolved per request, that lifetime is not the bound on how long stale access survives — it is how long a client can go before asking for a new token.

The behaviour here is deliberate and worth stating plainly, because it is the question a security architect asks next.

Fail-safe, not fail-open. A clean answer is authoritative even when it is empty — an empty set means the grant was withdrawn, and the request is denied. Only a genuine transport failure, where no answer is obtained at all, falls back to the last known set.

See also: Security · Scopes & Entitlements · Standards & Conformance · Identity Providers