Authorization models for APIs and apps: OPA, Cedar, Zanzibar

At a glance

What this is: NHI Mgmt Group's analysis, drawing on Reva.AI's blog post: OPA, Cedar, and Zanzibar are compared as authorization models for modern systems, with the core finding that access control should be matched to the shape of the data and decision problem.

Why it matters: It matters because IAM teams increasingly need authorization patterns that work across human, workload, and application contexts without forcing every decision into one policy style.

Context

Modern authorization fails when teams treat access control as a single pattern instead of a fit-for-purpose design choice. APIs, applications, and shared data layers need different ways to reason about users, actions, relationships, and context in real time, especially when identity spans both people and non-human identities.

The article frames authorization as a choice between code, typed policy, and relationship graphs. That matters for authorisation models because the governance question is not only who can access what, but which decision model can be operated, audited, and kept consistent at enterprise scale.

Key questions

Q: How should security teams choose between code-based and graph-based authorization?

A: Start with the access problem, not the tool. Use code-based authorization when decisions depend on attributes, context, or computed logic. Use graph-based authorization when membership, sharing, and transitive relationships dominate. In many enterprises, the right answer is a layered model where each engine handles the kind of decision it expresses best.

Q: When does a single policy engine become the wrong design choice?

A: A single engine becomes the wrong choice when the organization has mixed authorization problems that need different decision types, different data shapes, or different scale characteristics. If one model forces awkward workarounds, duplicated logic, or weak explainability, the architecture is starting to carry governance debt.

Q: How do teams keep policy-based authorization auditable?

A: Keep policy ownership, versioning and test evidence in one governed process, and review changes alongside application and data changes. Decision logic should be explainable to auditors and reviewers, with clear linkage between policy intent, policy inputs and the final access outcome.

Q: What should IAM teams do when access data changes faster than policy code?

A: Treat data freshness as part of the authorization design. If attributes or relationships change frequently, the team needs clear synchronization, update ownership, and monitoring for stale decisions. Otherwise, the policy may be syntactically correct while the access outcome is operationally wrong.

Technical breakdown

Code-based authorization vs relationship-based authorization

Code-based authorization evaluates policy logic at decision time against runtime input. OPA and Cedar follow this model, so they are suited to attribute checks, contextual rules, and decisions that need computed conditions. Relationship-based authorization, as used by Zanzibar-style systems, resolves access by walking pre-existing tuples and memberships rather than executing policy code. That makes it strong for group membership and sharing models, but weaker where the decision depends on dynamic context. The architectural difference is not cosmetic: one model computes access from data and policy, the other resolves access from relationships already stored.

Practical implication: Choose the decision model that matches whether your access question is contextual, relational, or both.

Why explainability and scale pull in different directions

Typed policy languages make authorization easier to reason about because the schema constrains what can be expressed and analysed. That improves auditability and static analysis, but it also reduces flexibility. Relationship graphs scale well for large membership sets and transitive permissions, yet they can be harder to explain to security reviewers because the answer emerges from a graph traversal rather than a readable policy statement. In practice, organizations should not expect one engine to maximise both human readability and massive relationship throughput at the same time. The trade-off is architectural and should be explicit in design reviews.

Practical implication: Document whether your priority is policy readability, relationship scale, or a blend of both.

How freshness and synchronization shape authorization accuracy

Authorization decisions are only as current as the data they read. Rule-based and schema-based engines often rely on external data feeds, while graph-based engines depend on tuple consistency and synchronization pipelines. If attributes lag or relationships are stale, the engine can make a formally correct decision from operationally outdated data. That creates a governance problem, not just a technical one, because stale authorization state undermines trust in the policy layer. The real control question is whether your synchronization model matches how often relationships and attributes change in the business.

Practical implication: Treat policy data freshness as a governance requirement, not an implementation detail.

Threat narrative

Attacker objective: The objective is to exploit weak or inconsistent access decisions to reach data or actions that should have been denied.

1. Entry occurs when a system accepts an authorization model that does not match the data and decision pattern it is supposed to govern.
2. Escalation follows when teams layer ad hoc logic, duplicated policy rules, or inconsistent synchronization on top of that mismatch.
3. Impact appears as inconsistent access decisions, weak auditability, and authorization logic that is hard to scale or explain.

NHI Mgmt Group analysis

Authorization architecture is now a governance decision, not a platform preference. Modern enterprises are no longer choosing between isolated policy engines and a single access layer. They are choosing how access decisions will be expressed, audited, synchronized, and scaled across systems that do not share the same data shape. The field should treat authorization as a design discipline spanning application logic, data relationships, and runtime context.

Data shape is the first control variable in policy design. If the organization’s access problem is relationship-heavy, a graph model can reduce complexity. If the problem depends on attributes, context, and computed conditions, code-based policies are more precise. The wrong model can still work technically, but it increases operational friction and governance debt. The practitioner implication is to map the access problem before selecting the engine.

Explainability and scale are in tension, and that tension is where governance lives. Typed policy improves reviewability, while relationship graphs improve throughput for shared access patterns. Neither is universally superior, and neither should be treated as a default for all workloads. This is why policy governance must include analysis of who can understand the rule set, who can change it safely, and how current the underlying authorization data remains.

Multi-policy authorization is becoming the practical baseline for complex environments. Most real-world enterprises will not live in one model only, because infrastructure, APIs, and business-layer authorization make different demands. The important discipline is to keep the layers coherent rather than let them drift into separate, contradictory control planes. That means shared ownership, shared audit logic, and a clear statement of which decision belongs to which model.

From our research library:

• 71% of organizations use third-party APIs, according to Gartner’s 2024 data.
• Read next: Authorisation Models Guide

What this signals

Authorization now has to be governed as a multi-model control plane. Enterprises with API-heavy and data-sharing workloads should expect a mix of graph resolution and contextual policy evaluation, not a clean replacement of one by the other. The priority is to keep decision boundaries visible so review, logging, and ownership do not fragment across teams.

The next maturity step is to align authorization data freshness with the business rate of change. If groups, entitlements, and sharing relationships move faster than the policy layer can observe, the control becomes formally correct but operationally stale. That is where authorization drift begins.

For practitioners

• Define the authorization question before selecting the engine Write the access decision in plain language first, then classify whether it is attribute-driven, relationship-driven, or a blend of both. This prevents teams from forcing every problem into the same policy style.
• Separate relationship resolution from contextual policy Use graph-style logic for memberships and sharing where that is the natural data model, and reserve rule-based evaluation for context, conditions, and computed checks. Keep the boundary explicit in architecture reviews.
• Build policy observability into the operating model Plan how you will observe, cache, version, and synchronize authorization data before rollout. Without that operating model, even a well-chosen engine becomes hard to trust under change.
• Test the decision type you actually need Confirm whether the application needs a boolean allow or deny, a filtered result set, or a reasoned decision response. The required output shape should influence the engine choice as much as the policy language itself.

Key takeaways

• Authorization design is increasingly about matching the policy model to the access problem, not about adopting one universal engine.
• Code-based and graph-based authorization solve different kinds of decisions, and both can be valid in the same enterprise.
• Governance needs to cover policy logic, synchronization, auditability, and data freshness if authorization is going to stay trustworthy.

Related NHI Mgmt Group resources: Authorisation Models Guide · Broken Access Control Prevention Guide · OWASP Top 10 Guide

Key terms

• Authorization Model: An authorization model is the structure an organisation uses to decide who can do what, and under which conditions. It combines decision logic with enforcement so access is granted or denied in a consistent way across applications and services.
• Relationship Graph Authorization: A model that derives permissions from explicit relationships between objects instead of from hard-coded application rules. It lets teams express who can do what, to which resource, and through which delegation path, which is especially useful when access changes frequently or spans agents, users, and services.
• Typed Policy: Typed policy is an authorization approach that uses a defined schema for entities, actions, and attributes. It improves readability, validation, and auditability because the policy language can be analysed before deployment. It is most useful when business logic and compliance need predictable, structured decisions.
• Policy Synchronization: Policy synchronization is the controlled propagation of one approved authorization decision model to multiple applications or environments. It reduces duplication, but the enterprise must still verify that each runtime interprets and enforces the policy the same way.

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.