Stale Authorization
Access that should be gone is still honored, because a token or cache hasn't caught up.
By the end of this lesson, reason about the revocation gap and shrink it for sensitive actions.
You revoke a permission, fire someone, or downgrade a role — but access continues for a while. Between the change and its enforcement is a revocation gap, caused by self-contained tokens valid until expiry, cached authorization decisions, or unsynced deprovisioning.
The revocation gap
- A permission is revoked at time T but only enforced after the token/cache TTL, leaving a window of continued access.
flowchart LR revoke[Permission revoked at T] --> gap[Gap: token/cache still valid] gap --> enforce[Enforced at T + TTL] gap --> risk[Access continues in between]
You trade freshness against load. Shorter token TTLs and shorter decision caches shrink the gap but increase issuance/PDP traffic. For high-impact actions, re-check authorization at the moment of the action (or use revocation events / push invalidation) rather than trusting a cached grant.
Stale authorization
- Trigger
- Revoked permissions remain in a valid token or a cached decision.
- Symptom
- A user retains access after it was removed.
- Blast radius
- Continued access during the revocation gap — worse if TTLs are long.
- Mitigation
- Short TTLs, revocation events/denylists, re-check on sensitive actions, SCIM deprovisioning.
Why not just make all tokens live 24 hours to reduce login friction?
It widens the revocation gap to 24 hours — a compromised or de-permissioned account keeps access that long. Balance TTL against the revocation risk.