Coarse-Grained vs Fine-Grained Authorization

One role, one quiet mistake

The support console at the cashback company was simple when Daniel built it. Anyone with the support-agent role could open any customer’s account, because support agents needed to help any customer who called. One role, one check, nothing to model. Two years later the company signs a contract with a large retail partner whose customers must only be handled by a dedicated team, and an auditor asks a direct question: can an agent outside that team open one of those accounts? The honest answer is yes. Nothing broke and nothing logged an error. The check simply never asked which account it was looking at.

The last two articles both assumed you already knew what kind of question you were asking. Policy as code assumed a flat rule over attributes was the right shape and covered how to write, test and ship it. Fine-grained authorization assumed a graph question was the right shape and covered how to model and query it. Neither asked the question that comes first, on every feature you build: how much does this decision need to know about the specific resource involved, for this specific caller, before it can be trusted?

The answer runs from “nothing at all” to “everything about a specific relationship between this exact user and this exact resource”, and where a decision falls on that range is what this article calls granularity. Miss in one direction and you overbuild: a relationship graph and a Check call for a decision that was always going to be “any logged-in employee, yes.” Miss in the other and you underbuild, which is what happened to Daniel’s console: a single role guarding something that was supposed to differ per customer. Both mistakes are common, and both are avoidable once granularity is something you choose on purpose instead of something you inherit.

A spectrum, not two boxes

“Coarse-grained” and “fine-grained” sound like two boxes, but real systems make authorization decisions at several layers, and each one answers a different kind of question at a different cost.

The perimeter is network ACLs, an API gateway checking that a key or bearer token is valid, a WAF rule. Its question is whether this caller may talk to the system at all. It knows nothing about resources, roles or relationships, and it shouldn’t.

The module or role layer asks things like “is this user an admin” or “can support agents see the billing module”, and it’s where feature flags live too. This is classic RBAC: the decision depends on who the caller is, their role or group, but not on which specific resource they’re asking about. A Casbin matcher checking role == "admin" lives here, and so does a boolean claim in a JWT.

The resource layer asks “does this user own this invoice” or “is this document still a draft, and did this user create it”. Now the decision depends on attributes of one specific instance, compared with the caller. This is where the XACML PDP, OPA and Cedar earn their keep, matching subject, resource, action and environment against policy.

The relationship layer asks “was this document shared with this user, directly or through a group or a folder, at any depth”. The decision depends on a specific edge or path between this exact subject and this exact object, which is the whole reason Zanzibar and OpenFGA exist.

It’s tempting to read that list as “the perimeter uses a gateway, the module uses RBAC, the resource uses OPA, the relationship uses OpenFGA”, as if the tool picked the layer. It works the other way round. The shape of the question puts you at a layer, and the tool follows. You could use OpenFGA to answer a question that never depended on a relationship, and it would work, but it would be far more machinery than a role check that already gave the right answer.

What coarse-grained buys you, and what it costs

A coarse check is fast, because it’s a claim lookup or an in-memory role comparison with no external data to fetch. It’s simple to model, because the list of roles or flags is short and you can write it down. And it’s simple to audit, because “who has the admin role” is one query. A large share of any application’s authorization is legitimately coarse: internal tools used only by employees, admin panels, feature gating, anything where “can this user do X” really has the same answer for every instance of the resource.

The cost shows up when a coarse check is asked to do a fine job, which is Daniel’s story. “Any agent can see any account” was correct when it was written. Once the policy became “agents see only accounts assigned to their team”, the role check stopped being imprecise and started being wrong: it grants access the real policy says shouldn’t exist. That’s the central risk of coarse authorization. It doesn’t fail loudly when it’s too broad. It quietly over-permissions, and nobody notices until an audit, an incident or a customer does.

What fine-grained buys you, and what it costs

A fine check, at the resource or relationship layer, closes exactly that gap. It evaluates the specific instance, so “can Sara view account #4471” and “can Sara view account #9902” can have different answers even though Sara’s role never changed. That’s what least privilege and need-to-know really mean in a system that holds other people’s data, and it’s what most compliance regimes end up asking for once you read past the headline requirement. HIPAA, SOC 2 and the GDPR’s data-minimization principle all get there eventually.

The price comes in three parts. The first is latency: a resource check usually means fetching attributes, through XACML’s PIP or its equivalent, and a relationship check means walking a graph. Both are more work than comparing a role string that’s already sitting in a JWT. The second is modeling effort: someone has to decide which attributes matter, or which relationships and rewrite rules exist, and keep that model right as the product changes. It isn’t a one-off cost; it grows with the product. The third is operational surface: a PDP, a PIP or a relationship store is one more thing to deploy, monitor, keep available and reason about for consistency, none of which a role claim in a JWT ever needs.

So fine-grained is a cost you take on for a reason, not a default. Treating it as the more sophisticated and therefore more correct choice leads to overbuilt systems. A relationship graph deciding which employees can read which internal wiki pages, when the real rule is “any employee”, is pure overhead with no security gain.

Layered authorization

Production systems rarely pick one layer and stop. They stack several, cheapest first, so most invalid requests are turned away before they reach the expensive check.

flowchart LR
  accTitle: A layered authorization path that rejects cheaply first
  accDescr: The diagram shows a request flowing left to right through four stages. First, the client sends a request to an API gateway, which performs a perimeter check verifying the token or API key is valid, rejecting immediately if not. Second, the request reaches a service, which performs a module or role check verifying the caller's role permits this action type at all, rejecting if not. Third, only requests that passed both cheap checks reach a fine-grained check, either a resource attribute evaluation through a policy decision point or a relationship check through a graph engine, which is the most expensive step. Fourth, if all checks pass, the service performs the requested operation. Each layer is cheaper and rejects a larger share of invalid traffic than the layer after it.
  Client([Client request]) --> Gateway[API Gateway<br/>perimeter: valid token?]
  Gateway -- rejected --> Deny1[["Deny (401/403)"]]
  Gateway -- valid --> Service[Service<br/>module: role permits action type?]
  Service -- rejected --> Deny2[["Deny (403)"]]
  Service -- permitted --> Fine[Fine-grained check<br/>resource attrs or relationship graph]
  Fine -- denied --> Deny3[["Deny (403)"]]
  Fine -- allowed --> Op[Perform operation]

It’s the same lesson the XACML article gave about where to put the PDP, a trade-off and not a fixed answer, applied this time to which check runs rather than where. The gateway’s check and the service’s role check exist largely to protect the expensive layer from load it doesn’t need. Rejecting a request with a bad token at the gateway costs one signature verification. Rejecting the same request at a relationship Check would cost a graph traversal for nothing. Layering cheap-first is a performance pattern with a security side effect: most of the invalid traffic an attacker or a bug produces never reaches the part of the system where slowness would hurt.

The N+1 authorization problem

Granularity choices don’t only affect single requests. They compound badly in code that renders lists, in a pattern anyone who has chased a slow page caused by an N+1 database query will recognize.

sequenceDiagram
  accTitle: The N+1 authorization problem and its bulk-API fix
  accDescr: The diagram contrasts two approaches to rendering a filtered list of fifty documents. In the naive approach, the application fetches the candidate documents once, then loops over them calling Check individually for each one, producing fifty separate authorization round-trips before the page can render, mirroring the classic N plus 1 database query problem. In the fixed approach, the application fetches the same candidates once and calls a single bulk lookup, ListObjects, which returns every allowed document ID in one round-trip instead of fifty.
  App->>App: naive: N+1 calls
  App->>DB: fetch 50 documents
  loop each document
    App->>AuthZ: Check(user, doc)
    AuthZ-->>App: allow / deny
  end
  App->>App: fixed: one bulk call
  App->>DB: fetch 50 documents
  App->>AuthZ: ListObjects(user, doc type)
  AuthZ-->>App: allowed IDs

The fix is the database fix. Don’t ask “is this one allowed” in a loop; ask “which of these can I see” once. OpenFGA’s ListObjects and ListUsers exist for exactly this. With a resource-attribute engine, the equivalent is usually pushing the filter into the query itself, something like WHERE owner_id = :user_id OR :user_id IN (SELECT ...), instead of fetching everything and calling the PDP once per row in application code. The loop isn’t just slow. It’s a sign that you’re asking the engine the wrong question: “which of N things” is a different and cheaper question than “is this one thing”, even if it looks like N copies of the same check.

Choosing a layer per feature

Given a feature, three questions in order are usually enough, and you stop at the first one that settles it.

The common mistake is answering this once, at design time, and choosing a single tool for the whole application. Real systems are layered and mixed at the same time: the admin panel gate is a role check, invoice editing is a resource check on ownership and status, and “share this report with my team” is a relationship check, all in the same product. Ask again whenever a feature’s requirements change. “Agents can view any account” turning into “agents can view accounts on their team” is exactly the jump from module to resource that Daniel’s console missed.

Three features in the cashback app

Look at three features of the same cashback app side by side, because the contrast is the lesson.

Whether a user can open the rewards dashboard at all depends only on whether the account is active, which is true or false for the whole account. It’s coarse: a status claim checked at the perimeter or module layer, with no PDP call.

Whether a support agent can view a specific customer’s transaction history depends on the agent’s role and on attributes of this customer: is there an open ticket for this account assigned to this agent, is it during business hours, does the account belong to the retail partner’s dedicated team. That’s the resource layer, a PDP shaped like the XACML one evaluating subject, resource and environment on every request. It’s also where Daniel’s console should have ended up.

Whether a user can view a savings report a teammate shared with their team depends on a chain: is the user in the team, was the report shared with the team, through how many folders. That’s the relationship layer, an OpenFGA Check walking membership and sharing tuples, just like Sara’s board summary in the previous article.

Three features, three layers, one application, and each is modeled correctly at its own layer. Forcing all three onto one tool would either waste effort, with a relationship graph guarding the dashboard, or quietly under-model the rule, with a role check guarding the shared report.

Testing and running a layered system

Tests have to cover the layering, not only each layer on its own. A request should be tested against the combination it will actually go through: does the gateway reject it before the role check runs, does the role check reject it before the expensive call, and, separately, does the fine check give the right answer for cases that pass both gates. A frequent gap is testing each layer’s logic carefully and never testing that a request denied at layer two never reaches layer three. That matters for correctness and for cost, because a bug that lets denied requests fall through to the expensive layer quietly wipes out the performance benefit that layering was for.

In production, the number worth watching is where requests are being rejected. In a healthy system the vast majority of invalid traffic is turned away at the perimeter and module layers, cheaply, and only a small remainder reaches the fine layer, which is the most expensive to run and the most important to get right. If that ratio flips and most rejections happen at the relationship graph, either the coarse layers are misconfigured and letting through traffic they should have caught, or a feature has quietly become one that needed a coarse pre-filter it never got.

Recap

Granularity is a question every authorization decision answers before any tool is chosen. Decisions sit on a spectrum, perimeter, module or role, resource and relationship, and each layer has a real component behind it: a gateway, an RBAC claim, a XACML, OPA or Cedar PDP, a Zanzibar-style graph. Coarse checks are fast and simple, but when they’re too broad they don’t fail, they over-permission in silence, which is what happened to Daniel’s support console. Fine checks close that gap at a real price in latency, ongoing modeling work and operational surface, worth paying when the decision truly depends on the specific resource or relationship. Layered systems combine both, cheapest first, so the expensive layer only sees the traffic that needs it. Checking items one by one in a loop is the N+1 authorization problem, fixed the same way as the database version, with one bulk or reverse-lookup call. And the question gets asked per feature, not once for the whole system, because most real applications rightly use all four layers.

Three questions to test yourself

1. A feature starts as “any logged-in employee can view the internal wiki” and later gains a requirement that some pages are visible only to specific teams. Using the granularity spectrum, explain which layer the feature started at and which layer it needs to move to, and why simply adding more roles would eventually break down.
2. Explain the N+1 authorization problem in your own words, and describe why a loop of individual Check calls is not just slower but a sign of asking the decision engine the wrong question.
3. A system checks authorization only at a central resource-layer PDP for every request, including ones an API gateway could reject for an invalid token alone. What does adding a perimeter check upstream actually save, given that the PDP would reject the same request anyway?

Hands-on exercises

1. Classify five real decisions. For an application you use or are building, list five distinct authorization decisions it makes (a page gate, a button visibility check, a data filter, a sharing feature, an admin action) and place each on the spectrum using the three questions above. Note which are currently over-modeled or under-modeled compared with your classification.
2. Design a layered path for one feature. Pick one fine-grained decision from the first exercise and design its full request path: what the perimeter check rejects, what the role check rejects and what the fine check evaluates. Estimate roughly what share of invalid requests each layer should catch.
3. Find (or create) an N+1 authorization bug. In a codebase you can access, look for a list-rendering path that calls an authorization check inside a loop. If you find one, sketch how you’d replace it with a bulk or reverse-lookup call. If you don’t, write a small example, pseudocode is fine, that shows the pattern and its fix.