ReBAC vs ABAC: Choosing Authorization Models for Edge-Distributed Systems

Authorization at CDN scale is fundamentally different from authorization in a monolithic application. When a single API gateway handles all traffic, authorization logic runs in one place with access to all the data it needs. When traffic is distributed across hundreds of edge nodes spanning dozens of countries, the authorization model must account for data replication, consistency guarantees, and compute constraints that do not exist in centralized architectures.

Two authorization paradigms dominate modern distributed systems: Relationship-Based Access Control (ReBAC), exemplified by Google Zanzibar and OpenFGA, and Attribute-Based Access Control (ABAC), represented by Amazon Cedar and Open Policy Agent (OPA). Each model makes fundamentally different assumptions about how authorization data is structured, evaluated, and distributed. For CDN operators building authorization at scale, this choice shapes everything from edge function design to cache invalidation strategy.

ReBAC: Authorization Through Relationships

ReBAC models authorization as a graph problem. Instead of asking "does this user have the 'read' permission?" ReBAC asks "does a path exist in the relationship graph from this user to this resource that grants read access?" This graph-based model naturally captures the complex organizational hierarchies, team memberships, and resource ownership structures that real applications require.

Google's Zanzibar system, published in 2019, formalized the ReBAC approach at global scale. Zanzibar serves over 10 million authorization checks per second across Google's product suite, including Google Drive, YouTube, and Cloud IAM. The key insight of Zanzibar is that most authorization decisions reduce to reachability queries in a directed graph of relationships.

The Relationship Tuple Model

ReBAC systems store authorization data as relationship tuples. Each tuple declares a relationship between a subject and an object:

# OpenFGA relationship tuples
document:budget-2026#viewer@user:alice
document:budget-2026#editor@team:finance#member
team:finance#member@user:bob
team:finance#member@user:carol
org:acme#admin@user:dave
team:finance#parent@org:acme

The authorization model defines how relationships compose. An editor can also view. An org admin inherits admin over all teams in the org. A team member inherits viewer access to all team documents. These rules create transitive paths through the relationship graph that determine access.

For CDN architectures, this model integrates with token authentication by embedding relationship context in tokens. A JWT might carry a minimal relationship context (user ID, org membership) that edge nodes use for initial filtering, with full graph traversal deferred to a central ReBAC service for complex authorization decisions.

Consistency Challenges for Edge Distribution

The fundamental challenge of deploying ReBAC at CDN edge nodes is the consistency requirement. When Alice is removed from a team, every edge node must stop granting her access to that team's documents. Zanzibar solves this with "Zookies" (consistency tokens) that track the version of the relationship graph a check was evaluated against. Each authorization response includes a Zookie, and clients can pass it back to ensure subsequent checks see at least that version.

For CDN edge nodes operating in a zero trust model, the consistency question becomes: how stale can the relationship graph at the edge be before it becomes a security risk? Most organizations accept a consistency window of 5-30 seconds for read access and require near-immediate consistency (under 1 second) for write access revocation. This aligns with cache key design patterns where different content types have different staleness tolerances.

ABAC: Authorization Through Attributes

Attribute-Based Access Control takes a fundamentally different approach. Instead of traversing a relationship graph, ABAC evaluates a policy function against attributes of four elements: the subject (who is requesting access), the resource (what is being accessed), the action (what operation is requested), and the environment (contextual conditions like time, IP address, or risk score).

For CDN edge functions, ABAC's attribute-based model offers a compelling advantage: all the data needed for an authorization decision can be embedded in the request itself. A JWT carrying user attributes (department, clearance level, role) combined with resource metadata (classification, owner, region) and environmental data (request time, source IP, TLS version) provides everything the policy engine needs to render a decision.

Cedar: Amazon's Policy Language for Edge Authorization

Cedar, developed by Amazon for AWS Verified Permissions, represents the state of the art in ABAC policy languages. Unlike OPA's Rego, which is Turing-complete and theoretically unbounded in evaluation time, Cedar policies are designed with formal verification in mind. Every Cedar policy is guaranteed to terminate, and evaluation cost is bounded and predictable.

// Cedar policy: Allow engineering team to read internal docs
permit(
  principal in Group::"engineering",
  action == Action::"read",
  resource in Folder::"internal-docs"
) when {
  context.request.tls_version >= "1.3" &&
  context.request.source_country in ["US", "CA", "GB"] &&
  principal.clearance_level >= resource.required_clearance
};

This predictability makes Cedar ideal for edge computing environments where function execution budgets are measured in milliseconds. A Cedar policy evaluation typically completes in 50-100 microseconds, compared to OPA/Rego's 0.5-2 milliseconds. At CDN scale, where edge nodes handle millions of requests per second, this 10-20x performance difference translates directly into infrastructure cost savings.

OPA and Rego for Complex Policy Evaluation

Open Policy Agent (OPA) with its Rego policy language remains the most widely deployed ABAC framework. Rego's expressiveness allows policies that would be awkward or impossible in Cedar, such as policies that aggregate across multiple resources, perform arithmetic calculations for rate limiting, or implement custom matching algorithms.

# OPA/Rego policy: Rate-aware access control
package cdn.authz

import rego.v1

default allow := false

allow if {
  input.user.role == "premium"
  input.resource.classification == "public"
}

allow if {
  input.user.role == "enterprise"
  input.resource.classification in ["public", "internal"]
  count(input.user.active_sessions) < 10
  input.request.rate_1min < input.user.rate_limit
}

For CDN deployments, OPA can be compiled to WebAssembly and executed at edge nodes. The compiled WASM bundle contains both the policy logic and the Rego runtime, typically weighing 1-3 MB. Edge nodes load the bundle at startup and evaluate policies locally against request attributes. Policy updates are distributed via the CDN architecture's existing content distribution mechanisms, treating policy bundles as just another cacheable asset with version-controlled invalidation.

Edge Deployment

The practical differences between ReBAC and ABAC become stark when deployed at CDN edge nodes. Each model has distinct requirements for data distribution, compute resources, and consistency guarantees that affect performance metrics across the edge network.

Data Requirements at the Edge

ABAC requires only the policy bundle (1-5 MB) to be distributed to edge nodes. All request-specific data arrives with the request itself via JWT claims and resource metadata headers. Policy updates are infrequent (daily or weekly) and distribute like any other static asset through the CDN's existing content distribution pipeline.

ReBAC requires the relationship graph, or at least relevant subsets of it, to be available at the edge. For a system with millions of users and billions of relationships, full replication is impractical. Partial replication strategies include caching hot relationship paths (the 20% of relationships that serve 80% of authorization checks), pre-computing authorization decisions for known access patterns, and maintaining a negative cache of recently revoked relationships for broken access control prevention.

Latency Profiles

At the edge, authorization latency directly impacts user experience and CDN performance metrics. ABAC evaluations complete in 0.05-2 milliseconds depending on policy complexity and engine (Cedar at the low end, OPA at the high end). These evaluations run entirely within the edge node's compute budget with no external dependencies.

ReBAC latency depends on whether the required relationships are cached at the edge. Cache hits complete in 0.5-5 milliseconds (graph traversal plus cache lookup). Cache misses require a round-trip to the central ReBAC service, adding 5-50 milliseconds depending on geographic distance. For CDN operators, this variable latency is the most significant concern with edge-deployed ReBAC, as it makes P99 latency unpredictable and impacts observability metrics.

Hybrid Approaches: Best of Both Models

Modern authorization systems increasingly combine ReBAC and ABAC capabilities. OpenFGA supports contextual tuples that inject request-time attributes into relationship checks. Cedar includes entity hierarchies that model organizational relationships. These hybrid approaches are particularly powerful for CDN architectures where different authorization decisions have different performance requirements.

A practical hybrid pattern for edge functions uses ABAC for the "fast path" (checking attributes embedded in the JWT against compiled policies) and falls back to ReBAC for the "full path" (traversing relationships for complex authorization decisions). The edge function first evaluates ABAC policies locally. If the ABAC evaluation returns a definitive allow or deny, the result is used immediately. If the ABAC evaluation is inconclusive (the policy requires relationship data not in the JWT), the edge function forwards the request to an origin-adjacent ReBAC service.

# Hybrid authorization at the edge (pseudocode)
def authorize(request):
    # Fast path: ABAC with JWT attributes
    abac_result = cedar.evaluate(
        principal=request.jwt.claims,
        action=request.method,
        resource=request.resource_metadata,
        context=request.environment
    )

    if abac_result.is_definitive():
        return abac_result  # 0.1ms

    # Slow path: ReBAC for relationship checks
    # Check edge cache first
    cached = relationship_cache.check(
        user=request.jwt.sub,
        relation="can_access",
        object=request.resource_id
    )

    if cached is not None:
        return cached  # 1-3ms

    # Cache miss: forward to central service
    return rebac_service.check(
        user=request.jwt.sub,
        relation="can_access",
        object=request.resource_id,
        zookie=request.consistency_token
    )  # 10-50ms

This tiered approach handles 85-95% of authorization decisions at the edge with sub-millisecond latency, with the remaining decisions incurring the cost of a centralized ReBAC check. For most CDN workloads, this balance between security completeness and performance at scale is acceptable.

Policy Distribution and Updates

Both models require mechanisms for distributing policy updates to edge nodes. For ABAC, this means distributing new policy bundles. For ReBAC, it means propagating relationship changes. The CDN's existing content distribution architecture can serve both purposes with appropriate configuration.

ABAC policy bundles should be treated as versioned, immutable artifacts. Each bundle has a unique version identifier, and edge nodes atomically switch from one version to the next. This prevents partial policy updates that could create inconsistent authorization behavior across edge nodes. The web application firewall can enforce that all edge nodes run the same policy version, rejecting requests to nodes that have not yet received the latest update.

ReBAC relationship updates are inherently incremental. New tuples are added, existing tuples are removed, and the relationship graph evolves continuously. For edge nodes, these updates propagate via event streams that each node subscribes to. The origin protection layer ensures that relationship events are authenticated and cannot be spoofed by attackers attempting to inject false relationships.

Security Considerations for Edge Authorization

Both authorization models introduce security considerations specific to edge deployment. Token manipulation is a shared concern: if an attacker can modify JWT claims at the edge, ABAC decisions become unreliable. If an attacker can corrupt the relationship cache, ReBAC decisions are compromised. Security headers and mutual TLS between edge nodes and origin services protect against these attacks.

For ABAC specifically, policy bundle integrity must be verified at each edge node. Signing policy bundles with the policy distribution service's private key and verifying the signature at each edge node ensures that tampered policies are rejected. Cedar supports cryptographic policy validation natively, while OPA bundles can be signed using standard tooling.

For ReBAC, the relationship cache is a high-value target. An attacker who can insert false relationships into the edge cache can grant themselves access to protected resources. Edge caches should only accept relationship data from authenticated sources, and all relationship updates should be verified against the central ReBAC service within a bounded time window. This aligns with zero trust authentication principles where every data source is verified.

Logging and audit trails are essential for both models. Every authorization decision at the edge should be logged with sufficient detail to reconstruct the decision logic. For ABAC, this includes the policy version, input attributes, and decision outcome. For ReBAC, this includes the relationship path traversed and the consistency token used. These logs feed into monitoring and observability systems for security analysis and compliance reporting.

Migration Strategies

Organizations often need to migrate between authorization models as their requirements evolve. A common path is from simple RBAC (Role-Based Access Control) to either ReBAC or ABAC, or from one model to the other. For CDN operators, migration must happen without authorization downtime, which means running both models in parallel during the transition period.

The shadow mode pattern deploys the new authorization model alongside the existing one. Both models evaluate every request, but only the existing model's decision is enforced. The new model's decisions are logged and compared against the existing model's decisions. Discrepancies indicate policy gaps that must be resolved before cutover. CDN security teams can analyze these discrepancies at the edge to identify authorization rules that need adjustment.

Gradual rollout follows shadow mode. Traffic is progressively shifted from the old model to the new one, starting with read-only operations on non-sensitive resources and expanding to write operations on critical resources. This mirrors the canary deployment pattern common in CDN infrastructure, where changes are validated at a small percentage of edge nodes before global deployment.

Decision Framework: When to Choose Each Model

Choose ReBAC when your authorization domain is dominated by organizational hierarchies and document ownership patterns, when users frequently share resources with specific individuals or teams, when your application models social relationships (followers, collaborators, approvers), or when you need to answer questions like "list all resources this user can access" efficiently. ReBAC works best when relationship data changes less frequently than requests are made against it, allowing effective caching at edge nodes.

Choose ABAC when authorization decisions depend heavily on dynamic context (time, location, risk score, device posture), when edge computing constraints demand sub-millisecond authorization latency, when policies change more frequently than relationship data, when you need formal verification that policies are consistent and complete, or when authorization data can be fully embedded in request tokens without external lookups.

Choose a hybrid model when your application has both structural (who owns what) and contextual (under what conditions) authorization requirements, when different API endpoints have different authorization complexity levels, or when you are migrating between models and need both to coexist. The AI agent authorization space is increasingly adopting hybrid models where agent identity is managed through ReBAC relationships and per-action permissions are governed by ABAC policies.

For CDN operators specifically, the decision often comes down to the ratio of authorization checks that can be resolved locally at the edge versus those requiring centralized data. If over 90% of checks can use locally available data (JWT attributes plus cached policies), ABAC is the pragmatic choice. If the authorization model inherently requires traversing relationships that cannot be predicted and pre-cached, ReBAC provides the correct abstraction despite the higher infrastructure cost. Integration with passkey authentication and multi-factor authentication systems further influences this decision based on the identity data available at each edge node.

Understanding the difference between 401 and 403 responses becomes particularly important in these architectures, as edge nodes must communicate both authentication failures (no valid token) and authorization failures (valid token but insufficient permissions) accurately. The bot management layer adds another dimension, where automated clients require different authorization paths than human users.

Frequently Asked Questions

What is the core difference between ReBAC and ABAC?

ReBAC (Relationship-Based Access Control) makes authorization decisions based on the relationships between entities in a graph, such as "user is a member of organization that owns this document." ABAC (Attribute-Based Access Control) evaluates policies against attributes of the subject, resource, action, and environment, such as "user has department=engineering AND resource has classification=internal AND time is within business hours." ReBAC excels at modeling hierarchical and social structures, while ABAC excels at dynamic, context-dependent policies.

Can ReBAC and ABAC authorization checks run at CDN edge nodes?

Yes, but with different trade-offs. ABAC policies (via Cedar or OPA/Rego) can be compiled into lightweight runtimes that execute entirely at the edge with sub-millisecond latency, needing only the attributes embedded in the request token. ReBAC requires relationship graph data, which must either be replicated to edge nodes (adding storage and consistency overhead) or queried from a central service (adding latency). Hybrid approaches cache frequently-accessed relationship subgraphs at the edge.

How does Google Zanzibar handle consistency for authorization at global scale?

Zanzibar uses a consistency model called "new enemy" problem avoidance. It assigns a Zookie (consistency token) to each authorization check that represents a snapshot of the relationship graph. When a relationship is removed (for example, revoking a user's access), subsequent authorization checks use Zookies that guarantee they see the removal. This provides causal consistency without requiring strict global consistency, achieving authorization check latencies under 10 milliseconds at Google's scale of millions of checks per second.

What is Amazon Cedar and how does it compare to OPA/Rego for edge authorization?

Cedar is an ABAC policy language created by Amazon, designed for formal verification and predictable performance. Unlike OPA's Rego language, which is Turing-complete and can have unpredictable evaluation times, Cedar policies are guaranteed to terminate and have bounded evaluation costs. This predictability makes Cedar better suited for edge environments where compute budgets are strict. Cedar policies compile to efficient evaluation engines that run in under 100 microseconds per check, compared to OPA's typical 0.5-2 milliseconds.

When should an organization use a hybrid ReBAC+ABAC model for CDN authorization?

A hybrid model is appropriate when the authorization domain includes both structural relationships (org hierarchies, team memberships, document ownership) and dynamic contextual rules (time-based access, IP restrictions, risk scores). For example, a CDN serving a multi-tenant SaaS application might use ReBAC to determine if a user belongs to a tenant that owns a resource, then apply ABAC policies for environmental constraints like geo-fencing or rate limits. OpenFGA supports this hybrid approach through its contextual tuples feature, and Cedar can reference external relationship data via entity hierarchies.