You cannot un-issue a signature

Why is it so hard to withdraw permission you have already granted in writing?

You click "revoke access" and the interface says the permission is gone. Ask an engineer when it is really gone and you may get an awkward answer: within the hour, probably.

That gap deserves an explanation rather than an apology, because it is not sloppiness. It is a direct consequence of the property that made the credential attractive in the first place, and the two cannot be separated by trying harder. Something about signing a statement makes unsigning it impossible, and it is worth seeing exactly where the impossibility sits.

Ask what a service does when a self-contained token arrives. It verifies the signature with the issuer's public key, reads the claims, checks the expiry, and decides. Now notice the striking omission: it asks nobody anything. No database, no call to the issuer, no shared state. That is the point of the design — verification is local, so it costs microseconds and works under any load, in any region, even while the issuer is down.

Now try to revoke. You want a token that was valid a moment ago to stop being accepted. What would you change? The signature is still correct; mathematics does not take instructions. The claims are inside the signed payload and cannot be edited without breaking it. And the verifying service consults nothing you control.

So the difficulty is not a missing feature. Revocation requires the verifier to learn something new at verification time, and the whole design consists of arranging that it never has to. You cannot both refuse to ask and expect to hear the answer.

Which means every real approach is a way of putting some asking back, and they differ only in how much and where.

The cheapest is to stop revoking and start expiring. Issue tokens that live five or fifteen minutes, and let revocation take effect by not renewing. Nothing is withdrawn; the grant simply is not extended. The stale window equals the token's remaining life, so the shorter the token, the tighter the bound — at the cost of more traffic to the issuer, which is the state you were trying to avoid, now paid in refreshes instead of lookups.

Then there is an explicit denylist: a list of revoked identifiers, distributed to verifiers. This works, and it is worth being honest about what it costs. You now have shared, freshness-sensitive state on the verification path. The token is no longer self-contained; it is self-contained plus a lookup, and if the lookup fails you must choose between denying good requests and honouring revoked ones. A middle version, cheaper because it is one value per user rather than one per token, is a "not valid before" timestamp: revoke everything issued to this subject before now, which is how "sign out of all devices" is usually built.

The heaviest option is introspection — ask the issuer about every token, as RFC 7662 defines. Revocation becomes immediate and the design has come full circle: you have a session lookup again, with a signature wrapped round it.

There is a nuclear option too, rotating the signing key, but it invalidates every token from that issuer at once. It is an incident response, not a revocation mechanism.

The honest summary is that there is no option that is both stateless and promptly revocable, and that is not a gap waiting to be filled. Stateless validation means the verifier does not consult a mutable record; revocation means changing a mutable record the verifier consults. What you are choosing is where the state lives and how stale it may be.

This is not peculiar to tokens. Certificate revocation has the same shape and the same unsatisfying menu: revocation lists that are large and stale, an online status protocol that reintroduces a per-check round trip and a privacy leak, and stapling as the compromise. Decades of effort, same structural bind.

Three refinements.

First, this is not an argument against self-contained tokens. It is an argument for matching the credential to the stakes: short lifetimes for anything that touches real authority, and accepting a lookup where prompt withdrawal genuinely matters.

Second, "revoked" in most product interfaces means the refresh path was cut, not that outstanding access tokens died. That is usually a reasonable design and an unreasonable thing to leave unexplained, because a user who reads "access removed" after a security scare deserves to know whether the window is zero or an hour.

Third, beware the halfway build. Adding a denylist to only some verifiers, or caching it with a long refresh interval, produces a system that looks revocable and is not — and worse, one whose actual revocation latency nobody has measured. If you are paying for state, verify that you are getting the promptness you paid for.

• How certificate revocation lists, OCSP and stapling made the same trade, and what stapling actually bought.
• Whether a "not valid before" timestamp per subject is the best value for money in revocation design.
• Measuring real revocation latency end to end, rather than assuming the configured lifetime is the answer.

Every term the collection defines is gathered in the glossary.