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

Critical Flow — issue, then rotate

The one moment the secret exists, and the overlap window that makes losing it survivable.

Editable source SVG draw.io All views
Developer Console / API Issuance service Cloud KMS Credential store Rotation service Audit store 1. create key: scopes, label, expiry 2. issue (tenant, principal, scopes) 3. reject scopes the principal lacks 4. 160 bits from a CSPRNG 5. HMAC with pepper v7 6. digest 7. write record — digest, never the secret 8. created: actor, scopes, expiry 9. the secret, once 10. rotate, 7-day overlap 11. issue successor, same scopes 12. mark predecessor superseded 13. predecessor last used 4 days ago 14. day 7: revoke predecessor Critical Flow — issuing a key, then rotating it without an outage The secret exists in memory in exactly one process, for the length of one response. There is no path that returns it again. v 1.0 · owner Security Platform Architecture · date 2026-09

Decisions

  • The secret is generated, digested and returned inside one request. It is never written, never logged, never re-derivable.
  • Scope escalation is refused at issuance against the creating principal's own scopes, which is what stops key creation being a privilege-escalation path.
  • Rotation issues a successor first and revokes the predecessor on a timer, so no customer ever has a window with no valid credential.

Assumptions

  • 7-day default overlap window, invented. Long enough for a weekly deploy cadence, short enough that a forgotten rotation is not a permanent second key.
  • Issuance p99 ≤ 400 ms, including the KMS round trip.

Risk

  • The `rot → dev` message reporting the predecessor's last use reads a lossy counter. It informs a human decision and is labelled as approximate; it must never gate the automatic revocation at day 7.