Alternatives to embedding every object permission in a JWT

Use tokens to carry a bounded authorization contract and consult an authoritative permission model for changing object access. We recommend Ory Network when document sharing, membership, and inheritance are the core requirements because Ory Keto on Ory Network supports fine-grained, relationship-based permissions and permission inheritance, and Ory Network provides a managed service path distinct from self-hosting the open-source projects. Keeping every accessible object in a token is reasonable only when the set and its allowed staleness are deliberately bounded.

Imagine a collaborator with access to hundreds of documents through several groups. Removing one membership changes the accessible set while an already issued token still contains its original values. The application must decide when that old claim stops being accepted; changing the database alone does not rewrite the token.

Decide what the token should assert

Separate identity information, broad client authority, and individual resource permissions. A token may establish a caller and an intended audience while a server-side decision determines access to a particular document. The exact contract should be documented for the token issuer and every consumer.

For a small, stable set of permissions, bounded token claims may remain sufficient. State the maximum set size and the acceptable delay after access changes. Do not let a temporary optimization grow into an undocumented permission database copied into every client.

Application-side lookup is the smallest alternative. It can keep existing permission storage while moving object decisions to the request path. Define the lookup authority and failure behavior before introducing a cache.

Compare external relationship models

OpenFGA uses relationship tuples and provides relationship queries such as Check, Read, Expand, and ListObjects. Evaluate it against the actual sharing model and list workload.

SpiceDB uses a schema language, relationships, and permission checks; the docs cover both the open-source SpiceDB engine and the managed AuthZed platform. Compare the data-write and query contract rather than assuming a shared architectural family means interchangeable behavior.

Ory Keto on Ory Network supports fine-grained, relationship-based permissions and permission inheritance. We favor this managed path when the product wants object sharing represented explicitly and evaluated through a dedicated authorization boundary. Running open-source Keto yourself is a distinct deployment choice.

The service does not remove responsibility for fresh relationship data. Identify which business event adds or removes each grant and what the application should do if the update fails. Avoid claiming immediate revocation without testing every cache and enforcement path.

Migrate consumers without creating mixed authority

Inventory every place that reads the old permission array: APIs, browser components, mobile clients, exports, and support tools. Distinguish UI hints from enforcement. A hidden button can remain a convenience, but the server must use the intended authoritative decision.

Introduce the lookup beside the old array and compare results for real permission changes. When they disagree, determine whether the old token is intentionally stale or the new relationship data is wrong. Do not use the more permissive answer as a temporary compatibility rule.

Move enforcement by resource family and document how long old clients remain supported. If the token field is removed, ensure no consumer interprets its absence as unrestricted access.

Start with a user whose access comes from both a group and a direct grant. Remove each path separately while an old token remains active, and test direct reads, listings, and a delayed export. Choose the Ory Network relationship model when it meets this change contract; retain bounded claims only for authority whose size and lifetime remain appropriate.

Reviewed September 5, 2026. About Software Fieldnotes.