This practitioner worksheet translates a security architecture concern into a short, repeatable decision process. It is deliberately vendor-neutral and should be adapted to local operational constraints.
Purpose and scope
Use this review when deciding whether a control protects the boundary between Issuer and protected signing key and Cloud API and revocation path. The goal is a documented, testable decision rather than a checklist completed for its own sake. Confirm asset ownership and process impact before changing a production environment.
Five decision checks
- Identify token issuer, owning team, application and intended audience.
- Record where signing keys and refresh tokens are held and who rotates them.
- Differentiate bearer tokens from sender-constrained mechanisms where available.
- Document token expiry, audience checks and emergency disablement separately for each provider.
- Test revocation propagation and keep evidence of residual accepted sessions.
Evidence to retain
Keep an inventory entry, a named business or technical owner, a documented authorization decision, and a record of test results. Capture evidence for Audience, lifetime and key custody checks and demonstrate that stolen bearer token presented outside intended trust is either prevented, detected or constrained. If a system cannot be tested safely, note that limitation and obtain an operational risk decision rather than treating absence of evidence as success.
Escalation and exception rule
Escalate when the chosen control could interrupt critical services, expose sensitive data or depend on unverified assumptions. A valid exception specifies affected assets, compensating monitoring, owner, expiry and the action that closes it. The principal trade-off is token portability versus proof-of-possession assurance; neither side should be treated as automatically dominant.
Suggested review cadence
At implementation, capture the baseline and the intended authorization boundary. At the first operational checkpoint, verify access logs and unexpected denials. At the next change window, re-evaluate exceptions and re-run the negative test. These are review prompts rather than universal intervals or service-level guarantees.
Sources and confidence
Primary source: NIST IR 8587, Protecting Tokens and Assertions from Forgery, Theft, and Misuse. These sources support the attributed signal. All architecture controls, comparisons and proposed review timelines are independent analytical recommendations, not claims that the cited organization implemented them.
Practical architecture worksheet; it is not a claim of measured outcomes, an incident advisory or a substitute for local engineering validation.