Notifications
Clear all
Topic starter
09/07/2026 3:25 pm
TL;DR: Authorization in distributed systems breaks the monolith assumption that one service can safely answer access questions with local data, according to Authzed. The practical takeaway is that fine-grained access control needs a coherent decision point, because duplicated logic, JWT scope bloat, and service coupling all grow faster than service boundaries.
NHIMG editorial — based on content published by Authzed: authorization approaches for distributed systems
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
- 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.
- 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.
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.
👉 Read Authzed's analysis of distributed authorization approaches →
Distributed authorization: when should teams centralize access decisions?
Explore further
09/07/2026 3:45 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Distributed authorization needs a central policy model
