API Key and Token Service  ·  View 21 of 22  ·  Act 7 · Assurance

Identity and Access

Who proves what, to whom, before a credential exists at all.

Editable source SVG draw.io All views
Developer Platform IdP Console backend Issuance service Scope registry Credential store Audit store 1. OIDC sign-in 2. assertion: principal, tenant 3. create key with payments:write 4. step-up: scope escalation 5. re-authenticated 6. issue (mTLS, workload identity) 7. does the principal hold payments:write? 8. yes — grade: write 9. refuse if the principal lacks it 10. insert, tenant predicate enforced 11. actor, scopes, step-up evidence 12. the secret, once Identity and Access — who proves what, before anything is issued A principal can never issue a credential wider than itself. That single rule is what keeps key creation from being a privilege-escalation path. v 1.0 · owner Security Platform Architecture · date 2026-09

The rule

  • A principal can never issue a credential wider than itself. Checked against the principal's own held scopes at issuance, in the issuance service, not in the console.
  • Step-up authentication is required for scope escalation, constraint removal and bulk revocation — the three actions whose consequences a stolen session would most like to have.

Machine callers

  • Workload identity and mTLS between every plane; no long-lived bootstrap credential exists anywhere in the deployment. A service that needed one would be a credential service that could not solve its own problem.

Audit

  • The step-up evidence is written to audit alongside the issuance, so "who authorised this scope" has an answer years later.
◀  Security Trust Zones All views Failure Modes  ▶
Solution Architecture v1.0 · Google Cloud with open-source edge components · Security Platform Architecture · 2026-0921-identity-and-access