A signature does not query current state
An operator leaves the team, but the access token has not expired. Its signature remains mathematically valid: disabling the account does not change already signed bytes. If the resource checks only signature and time, it may continue accepting the token until expiry. Architecture needs an explicit state-change strategy proportionate to risk and required availability. It can combine short-lived tokens, state queries, revocation and event distribution. None should be assumed merely because SSO exists. Identify where decisions are enforced, which information they use, how long it may remain stale and who confirms propagation when access is removed.
See the difference between identifier and mechanism
The lab includes jti but accepts the same token twice while it satisfies the rules. An identifier does not automatically create a replay cache or revocation list. When the exercise adds the issuer and jti pair to its denylist, the same token is denied. An older list copy still accepts it. This demonstrates a logical consequence of stale information without measuring distributed infrastructure. The resource also denies a subject no longer active in consulted state. Keep token identifier, account, grant and signing key separate: changing one can have different effects on credentials already issued.
Choose freshness with known impact
Introspection lets a resource query token information but adds a dependency. Caching responses reduces traffic and latency while creating a window in which state may change without the decision reflecting it. RFC 7662 requires a response containing exp not to be cached beyond that instant. A cache lifetime below exp can still be too long for service risk. Also define behavior when the query fails. In this exercise, missing required state produces denial; that does not establish that business continuity is solved. The operational plan needs observability, diagnosis, dependency recovery and any exception procedure with explicit scope and authority.
Separate planned rotation from compromise response
The exercise starts with old in the trusted key set. Tokens signed by new are rejected until that key is published in the local set. During overlap both are accepted; after old is removed, old tokens are rejected even if exp remains in the future. This lab performs no remote JWKS retrieval. During planned rotation, coordinate issuance, trust distribution, caches and existing credential validity. During compromise, extending old-key trust may extend the ability to produce accepted tokens. Decisions need to account for exposure and interruption with defined owners and criteria. Do not confuse deleting an issuer’s private key with removing trust from every validator.
Prepare diagnostics without exposing credentials
The synthetic event records request identifier, action, resource, decision and policy version. It includes no bearer, private key or complete claims set. In production, apply classification and retention to metadata itself, which can also reveal sensitive activity. A denial spike after rotation may indicate an undistributed key; after configuration change it may indicate mismatched audience or scope. Correlate failure category with the change before disabling controls. At handover, provide procedures for expiration, clock drift, unavailable state and urgent revocation, including escalation criteria. The 51 local checks are evidence about the model; they do not establish propagation SLA, identity-provider security or replay resistance of an actual API.
# Compare current and stale authorization state using the same synthetic token.
# A valid signature does not query revocation or subject status.
# No remote identity provider or introspection endpoint is used.The updated denylist denies the token; the old copy accepts it. Removing old key trust also denies it despite future expiration.
Common pitfalls
Jti as automatic replay prevention; logout as universal revocation; deleting an issuer key as trust removal; unbounded caching.
Related topics: Trust boundaries · API authorization · Revocation and operations
Access removal needs mechanisms, propagation and evidence at decision points.
Reference: OAuth 2.0 Token Introspection · CAS-005 / SecurityX V5; objectives 3.0; launched 2024-12-17