API Key and Token Service  ·  View 12 of 22  ·  Act 5 · Runtime

Critical Flow — verify a request

Thirteen messages, none of which leaves the pod.

Editable source SVG draw.io All views
Customer app API gateway Verification sidecar Local projection Staleness guard Product service Telemetry 1. GET /v1/payments Authorization: sk_live_… 2. ext_authz over localhost 3. parse prefix, extract kid 4. HMAC(secret, cached pepper) 5. digest lookup 6. record or miss — constant cost 7. revocation overlay check 8. how stale is this projection? 9. fresh — 1.4 s behind the feed 10. VALID + context + staleness 11. forward with context header 12. sampled event, off the hot path 13. past 120 s: deny privileged scopes Critical Flow — verifying a credential on the request path Nothing on this page crosses a network boundary except the customer's own request. Budget: p99 ≤ 3 ms in-process. v 1.0 · owner Security Platform Architecture · date 2026-09

The budget

  • p50 ≤ 0.3 ms, p99 ≤ 3 ms, p99.9 ≤ 10 ms in-process. Stated assumptions, and chosen so that verification is cheaper than the cheapest platform call it guards — which is what makes "verify on every request" a decision nobody has to defend in a budget review.
  • The digest is a keyed HMAC, not a memory-hard KDF. At 250,000/s an Argon2id verification is not affordable, and 160 bits of platform-generated entropy is not a password.

What the response carries

  • Tenant, principal, scope set, constraints, credential class, expiry — and the projection's staleness, on every response including the successful ones.
  • Invalid answers come from a closed set of reasons and are returned at constant shape and cost, so timing does not disclose whether a key identifier exists.

The failure branch

  • Past 120 s without a successful feed poll the guard refuses write and admin scopes while read-only scopes continue. That is the scope-graded answer to the fail-open/fail-closed question, and it doubles the behaviours that need testing.