KemalIdentity::Authz::Cache

A short-lived cache of one account's grants.

docs/06-roadmap.md: role and permission lists are not copied into long-lived tokens or sessions, and if membership changes must take effect immediately they are read from the store "or a short-lived versioned cache". This is that cache, and everything about it is about keeping short-lived true.

The TTL is the revocation delay, and it is capped

Whatever the TTL is, that is how long somebody keeps access after it is taken away, in the worst case, in every process that had cached them. Five seconds by default and a hard ceiling of one minute — not because a longer one would not perform better, but because a ten-minute cache is a ten-minute window in which a compromised account keeps working after somebody has already noticed and revoked it. An application that wants no window at all passes no cache; it is off by default.

Invalidation helps one process, and the TTL is what actually bounds this

#invalidate drops an account's entries, and RBAC calls it on every grant and revoke it performs. Behind several processes or several machines, that only clears the cache of the process that made the change; the others wait out the TTL. This is stated plainly rather than papered over with a pub/sub mechanism that would be one more thing to run and one more thing to be silently broken — if the invalidation channel fails, the TTL is what is still keeping the promise, so the TTL had better be short enough to be the whole answer on its own.

It is bounded, and it drops everything when it fills

The key includes the tenant asked about, and anybody signed in can ask about a tenant that does not exist, so an unbounded map is an unbounded map an attacker fills. At the limit the whole cache is cleared rather than evicted one entry at a time: no LRU bookkeeping on the hot path, and the failure mode of a stampede is "the cache stops helping", not "the process runs out of memory".