Authorization-Aware Caching

Authorization-aware caching means the cache design understands that visibility depends on identity and policy, not just on resource ID. A response may be correct for one requester and forbidden for another. If the cache ignores the authorization context, it can serve an answer that was valid for someone else but is unsafe for the current caller.

This is especially tricky because authorization can change over time. A user may lose a role, move tenants, or have a token revoked. Cached responses that were safe a minute ago may no longer be safe now.

    sequenceDiagram
	    participant UserA
	    participant UserB
	    participant App
	    participant Cache
	    participant Policy
	
	    UserA->>App: Request document 42
	    App->>Policy: evaluate permissions
	    Policy-->>App: allow
	    App->>Cache: store response with auth scope
	    UserB->>App: Request document 42
	    App->>Cache: check scoped key
	    Note over App,Cache: Response is safe only if scope matches UserB's permissions

Why It Matters

Authorization mistakes in caches are often harder than simple user scoping because two users may share some permissions but not others. The key question becomes whether responses are safe to share across an authorization bucket or whether they must be cached per actor.

Useful patterns include:

• cache only public or fully policy-agnostic content in shared layers
• partition by role or permission bucket only when those buckets are well defined and stable
• cache the result of policy evaluation separately from the resource only if invalidation is also modeled
• prefer per-user or per-session caching when access rules are highly individualized

Example

This example scopes a document response by tenant and a coarse permission bucket rather than by path alone.

1function documentCacheKey(
2  documentId: string,
3  tenantId: string,
4  permissionBucket: "viewer" | "editor" | "admin"
5) {
6  return `document:${documentId}:tenant:${tenantId}:scope:${permissionBucket}`;
7}

What to notice:

• coarse buckets can improve reuse, but only if the policy model actually supports them
• some systems should avoid shared caching entirely for permission-sensitive responses
• revocation and role changes still need invalidation or short TTL handling

Trade-Offs

Authorization-aware caching trades off reuse against safety.

• Finer scope improves safety but reduces hit rate.
• Coarser permission buckets improve reuse but increase the risk of unsafe sharing if the buckets are not exact enough.
• Per-user caching is safer but can be more expensive and less memory efficient.
• Policy-result caching can help performance, but it becomes another invalidation target when permissions change.

The safer default is to under-share rather than over-share.

Common Mistakes

• assuming one allowed response is shareable by all allowed users
• caching authorization decisions longer than the underlying role or entitlement model remains stable
• building keys from path and tenant but not from policy scope
• forgetting revocation and privilege downgrade scenarios

Design Review Question

When is it safe to share a cached response across more than one user?

The stronger answer is that sharing is safe only when the system can prove the response is identical in content and visibility for the whole sharing group, and when changes to that group’s permissions are reflected quickly enough. If that proof is weak, per-user or very narrow scoping is the safer design.

Quiz Time