API Gateway Platform  ·  View 15 of 21  ·  Runtime

Revoking a Leaked Credential

A push with a measured coverage figure, not a lookup with a consistency guarantee.

Editable source SVG draw.io All views
Security engineer Config API Credential store Revocation bus Proxy fleet Edge denylist Audit ledger 1. revoke cred_id 2. set revoked_at, strong write 3. committed 4. who, what, when 5. accepted, propagating 6. revocation event 7. fan out, every region 8. insert, no restart 9. ack with version 10. coverage: 100% at 11 s 11. next call with that key: 401 12. denial recorded 13. if coverage < 100% at 60 s: page Revoking a Leaked Credential in Under Thirty Seconds Revocation is a push with a measured coverage figure, not a lookup with a consistency guarantee. The coverage number is what makes the 30 s SLO falsifiable. v 1.0 · owner Integration Platform Architecture · date 2026-09

Why it is shaped like this

  • ADR-01 forbids a synchronous revocation check on the request path, so revocation has to be pushed. That converts a consistency guarantee into a propagation SLO, and an SLO needs evidence.
  • Every proxy acknowledges with its denylist version, so coverage is a number rather than a hope. Below 100% at 60 s, someone is paged.
  • The operator is told "accepted, propagating" — never "revoked" — because the second word would be a claim the platform cannot yet make.

Numbers

  • Revocation effective globally within 30 s (assumption). The 11 s figure on the diagram is illustrative, not a target.
  • Token lifetime is chosen against this SLO: a long-lived signed token that is not on the denylist is a credential nobody can recall.

Risks

  • The denylist grows without bound unless entries expire with the credential they name. Entries are retained to not_after and no longer — which means a non-expiring API key needs a permanent entry, and is an argument for expiring keys.