Distributed authorization needs a central policy model

At a glance

What this is: This is an analysis of why authorization gets harder when a monolith is split into services, and why centralizing permission checks can reduce drift and duplication.

Why it matters: IAM and security teams need this because service-to-service authorization quickly becomes a governance problem, not just an engineering problem, once permissions span domains and identities.

👉 Read Authzed's analysis of distributed authorization approaches

Context

Distributed authorization is the problem of deciding who can do what when the data needed to answer that question lives across multiple services. In a monolith, a single database query can often resolve access and object ownership together, but once file, user, and gateway logic split apart, the authorization model itself becomes fragmented.

That fragmentation matters for IAM, NHI, and application security because permission decisions start to drift across services, tokens get overloaded with scopes, and policy changes require coordinated updates. For teams building distributed systems, the real question is no longer whether access is enforced, but where the source of truth for that decision lives.

Key questions

Q: How should security teams handle authorization across multiple services?

A: Security teams should centralize fine-grained authorization when access decisions depend on relationships that span service boundaries. A shared authorization service gives each application component a consistent answer while reducing duplicated policy code, service coupling, and drift between implementations. The goal is not to move every decision to one place, but to keep the source of truth for policy coherent.

Q: Why do JWT scopes become a problem in distributed systems?

A: JWT scopes work well for coarse roles, but they become unwieldy when a user needs access to many individual resources. The token grows in size, issuance logic becomes harder to maintain, and the system starts depending on prediction about which scopes each request will need. That is a scaling limit, not just a formatting issue.

Q: What breaks when each service implements its own authorization logic?

A: Each service can end up answering the same permission question differently because it only sees part of the relationship graph. That creates duplicated logic, more bugs, and the risk of silent authorization drift across services. In distributed systems, inconsistent answers are often worse than slower answers because they undermine trust in the access model.

Q: What is the difference between gateway authorization and centralized authorization?

A: Gateway authorization decides access at the edge and often encodes the result into a token, while centralized authorization keeps the policy decision in a dedicated service that domain services query at runtime. Gateway models are simpler for coarse access, but centralized models handle fine-grained permissions more consistently across service boundaries.

Technical breakdown

Why distributed authorization breaks local decision logic

In a monolithic system, authorization can be evaluated against one datastore and one set of application rules. Once services split, each service sees only part of the identity and resource graph, so local checks either become incomplete or depend on calling other services at runtime. That creates latency, tight coupling, and a growing risk that two services will answer the same permission question differently. In practice, the problem is not just where policy is stored, but where the truth needed to evaluate policy is assembled.

Practical implication: treat cross-service authorization as a shared system concern, not a per-service coding pattern.

Why JWT scopes and gateway authorization stop scaling

Gateway authorization pushes access decisions to the edge and encodes them into tokens, often as OAuth 2.0 scopes. That works when permissions are coarse and stable, but it becomes brittle when users can access many objects, because the token must carry a long and rapidly changing list of resource-level entitlements. The result is larger tokens, heavier sync logic, and more operational fragility. The model also shifts complexity into whatever system mints or refreshes the token, which now has to predict what each downstream service will need.

Practical implication: reserve token-embedded authorization for coarse-grained access, not high-cardinality resource permissions.

How centralized authorization services reduce policy drift

A centralized authorization service separates policy evaluation from business services. Domain services ask a simple question, such as whether a user can view a resource, while the authorization engine holds the relationship graph and evaluates the rule consistently. This reduces duplicate authorization code and makes policy changes easier to manage, but it also introduces a dependency on relationship-sync accuracy and service availability. In a distributed system, that tradeoff is often acceptable because the alternative is multiple inconsistent authorization implementations.

Practical implication: centralize authorization when you need consistent fine-grained decisions across many services.

NHI Mgmt Group analysis

Distributed authorization is a governance problem before it is an implementation problem. Once access decisions cross service boundaries, the system needs a single place where identity, object relationships, and policy meet. Without that, each service becomes a partial authority, and partial authorities create drift. The important point for practitioners is that authorization sprawl is not a coding inconvenience, it is a control failure waiting to happen.

Token inflation is the hidden cost of pushing authorization too far to the edge. Resource-level scopes can work for coarse roles, but they do not scale cleanly when entitlements become user- and object-specific. The more permissions you embed into JWTs, the more you trade runtime simplicity for token bloat, sync complexity, and brittle issuance logic. Practitioners should read that as a boundary condition, not a tuning problem.

Relationship-based access control with an ABAC layer is the right abstraction when permissions are dynamic and graph-shaped. The article’s central point is that services should ask whether an action is allowed, not reconstruct the entire relationship graph themselves. That model aligns with distributed systems because it preserves a consistent policy view while keeping application services focused on business logic. The practitioner takeaway is to design around the permission graph, not around duplicated authorization code.

Centralizing authorization changes the failure mode from disagreement to dependency. That is a better failure mode for most enterprise systems because disagreement between services creates silent privilege errors. A central service can still fail, but it fails visibly and consistently, which is easier to govern than split-brain authorization logic. The practitioner conclusion is that consistency is usually the more valuable control objective than local autonomy.

Fine-grained authorization should be treated as an identity data problem as much as an access-control problem. The article shows that the hard part is keeping ownership, membership, and viewer relationships synchronized across services. That is why the design choice is really about lifecycle, synchronization, and trust in the authorization dataset. Practitioners should evaluate authorization platforms by how reliably they preserve that relationship state over time.

From our research:

• NHIs outnumber human identities by 25x to 50x in modern enterprises, according to Ultimate Guide to NHIs.
• Only 5.7% of organisations have full visibility into their service accounts, which means most identity programmes still struggle to maintain an accurate machine-identity inventory.
• The governance lesson carries forward into workload identity and service account lifecycle controls, which are covered in Ultimate Guide to NHIs , Key Challenges and Risks.

What this signals

Permission graphs will become a first-class governance object as systems continue to split across services. Teams that keep treating authorization as embedded application logic will accumulate drift faster than they can review it. The next maturity step is not more token claims, but clearer ownership of the relationship data that drives decisions.

Scope bloat is the warning signal that gateway authorization has crossed its useful boundary. Once tokens need to carry many per-resource entitlements, you are no longer simplifying the system. You are moving policy complexity into the issuance path, where it becomes harder to observe, harder to revoke cleanly, and easier to misalign with the underlying data model.

The practical signal for programme owners is whether policy can be refactored once and consumed everywhere, or whether every service still needs a bespoke permission implementation. If the latter is true, you do not have an authorization model, you have a collection of local exceptions.

For practitioners

• Centralize fine-grained access decisions Route cross-service permission checks to one authorization layer so services ask a simple yes or no question instead of rebuilding policy logic locally. This reduces drift between the File and User services and keeps the permission graph in one place.
• Limit JWT scopes to coarse-grained access Use token claims for broad roles or workspace-level access, not for large lists of per-resource entitlements. If scopes start resembling resource:id:role at scale, move the decision out of the token and into a shared policy service.
• Separate policy evaluation from business services Keep domain services focused on application behavior and let a dedicated authorization service own relationship resolution and permission logic. That makes authorization changes easier to refactor without touching every service.
• Design for relationship synchronization Treat updates such as ownership changes, sharing events, and deletions as part of the authorization lifecycle, not just application data updates. The accuracy of the relationship graph determines whether centralized authorization returns consistent answers.

Key takeaways

• Distributed systems expose the limits of local authorization logic because the data needed for a decision is no longer co-located with the service making it.
• JWT scope inflation is a scale signal, not a design success, because per-resource entitlements do not belong in tokens once they become numerous and volatile.
• Centralized authorization reduces drift by keeping the relationship graph and policy decision in one place, which is usually the better tradeoff for fine-grained access.

Key terms

• Distributed Authorization: Distributed authorization is the practice of deciding access when identity, resource, and relationship data live in different services. It requires a shared policy model or a reliable decision service so that access checks stay consistent as applications split apart and business logic crosses boundaries.
• Gateway Authorization: Gateway authorization evaluates access at the edge of a system and passes the result downstream, often through token claims or request annotations. It can work well for coarse permissions, but it becomes fragile when permissions are numerous, dynamic, or tied to individual resources.
• Relationship-Based Access Control: Relationship-based access control grants permissions based on how identities relate to objects and other identities, such as ownership, membership, or sharing. It is especially useful in distributed systems because it models real application relationships instead of flattening everything into static roles.
• Authorization Drift: Authorization drift is the divergence that occurs when different services implement or interpret access rules differently. Over time, the same user can be allowed or denied depending on which service answers the question, which is a governance problem as much as a technical one.

What's in the full article

Authzed's full article covers the operational detail this post intentionally leaves for the source:

• A deeper comparison of service-local authorization versus centralized authorization for distributed systems.
• Schema examples showing how relationship-based access rules are expressed and maintained.
• Tradeoffs involved in feeding relationship data into a central authorization service.
• A practical look at how authorization design changes when GraphQL or similar gateways sit in front of services.

👉 The full Authzed article covers service boundary tradeoffs, JWT scope limits, and centralized policy handling.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.