Token Revocation

Token revocation is the withdrawal of an access grant before it expires on its own. It happens for ordinary reasons: a user clicks remove access in their account settings, an administrator sweeps the third-party applications connected to a workspace, a provider invalidates tokens after a security event, or a password reset or an offboarding cascades through every session and grant attached to that person. For anyone building an integration, the fact underneath all of these is the same — the grant was never yours. It lives in somebody else's account behind a button, and the person pressing it usually does not know your product is downstream of it. What revocation looks like in your logs is initially indistinguishable from an expired token: authorization errors on calls that worked yesterday. The distinguishing test is the refresh. An expired access token is replaced by a refresh that succeeds; a revoked grant is one where the refresh fails too, and that failure is the actual signal. Code that treats every authorization error as a transient problem will retry a revoked connection indefinitely, which accomplishes nothing and, with some providers, counts against abuse limits. Handle it as a state, not an error. Mark the connection broken rather than deleting it, so the customer's field mappings, identifiers and history survive a reconnection instead of being rebuilt from scratch. Notify a human through a channel somebody reads, remembering that the account which lost access may belong to a person who has left the company. And stop serving the copied data as though it were current — an integration that quietly keeps showing yesterday's records after the connection died is the version of this failure that costs trust rather than merely service. The other half is your own. Being able to revoke a credential you issued, for one customer, without a deploy, is the first capability asked for during a security incident and an uncomfortable thing to discover you lack while one is in progress.