Skip to main content

Command Palette

Search for a command to run...

Your permission cache key needs the tenant in it

Updated
•2 min read•View as Markdown
A
Practical lessons on auth, authorization, and access control.

A common speedup is caching the answer to "can this user do this action" for a minute or two. The trouble starts when the cache key is only user ID plus action. Someone who belongs to two workspaces gets checked as an admin in the first one, that result is cached, and their next request to the second workspace reads the cached "allowed" without ever looking at their role there.

Role changes cause a similar gap. If you demote someone, the cached result keeps saying yes until the entry expires. With a long TTL that can be a while.

Put the tenant ID and the resource ID (or the resource type, if you cache coarser checks) in the key. Also keep a version number per user or per tenant that you bump whenever roles or memberships change, and include it in the key, so old entries become unreachable the moment something changes.

To test it, make a user an admin in workspace A and a viewer in workspace B. Call an admin-only endpoint in A, then the same endpoint in B within the TTL. B should return 403. Then demote the user in A and call it again. That request should already fail.