Freshness and speed pull in opposite directions
An authorization check that consults live, current state — the user's current roles, the resource's current sensitivity, any conditions attached right now — gives the most accurate answer, at the cost of the time that lookup takes. For a high-frequency operation, checking on every single call can add latency that's disproportionate to the action itself, especially if the check involves a network round-trip to a separate policy service.
Caching the decision, or the underlying attributes it depends on, removes that latency on repeated calls. But a cached decision reflects the state of the world at the moment it was cached, not the moment it's used — and authorization is exactly the kind of decision where that gap matters, because the whole point of a revocation is that it should take effect immediately, not after a cache expires.
Scoping the cache to what the decision actually depends on
A workable middle ground usually means caching selectively: a short time-to-live for anything tied to access that might need to be revoked quickly, invalidating the cache explicitly on events that should immediately change the answer (a role removal, an account suspension), and reserving zero-cache, always-live checks for the highest-stakes actions specifically, rather than applying one caching policy uniformly across everything the system authorizes.
Getting this wrong in the direction of over-caching is the more dangerous failure: it looks like a performance optimization until an incident reveals that a revoked identity kept acting for as long as the stale cache entry lived.