OpenFGA and Zanzibar: Distributed Authorization for CDN Workloads

Authorization at CDN scale presents a unique engineering challenge. Every request that reaches an edge server requires an access decision — can this user view this content, invoke this API, or access this cached resource? Traditional approaches embed authorization logic directly in application code or rely on centralized policy engines that become bottlenecks at global scale. Google solved this problem internally with Zanzibar, an authorization system that processes over 10 million checks per second across services like Drive, YouTube, and Cloud IAM. OpenFGA, the open-source implementation of the Zanzibar model, brings this capability to CDN operators who need fine-grained, relationship-based authorization without building a custom system from scratch. This article examines how the Zanzibar authorization model maps to CDN infrastructure, from edge architecture to token-based authentication integration, with practical patterns for deploying OpenFGA at edge scale.

What Is Zanzibar and Why Did Google Build It?

Before Zanzibar, Google's services each implemented their own authorization systems. Google Drive had its sharing model, YouTube had its own content access logic, and Cloud IAM had yet another permissions framework. These systems shared common patterns — hierarchical permissions, group memberships, resource ownership — but each reimplemented them independently. The result was inconsistent behavior across services, duplicated engineering effort, and authorization bugs that appeared in one service but not another.

Google published the Zanzibar paper in 2019, describing a unified authorization system built around a single abstraction: the relationship tuple. A tuple takes the form (user, relation, object) — for example, (user:alice, viewer, document:readme) states that Alice is a viewer of the readme document. Authorization checks query whether a specific relationship exists, either directly or through inheritance. The system stores billions of these tuples and resolves authorization checks by traversing a graph of relationships defined in an authorization model.

The Zanzibar model solves three problems that are directly relevant to CDN security. First, it decouples authorization logic from application code — the CDN edge does not need to understand the business rules behind access decisions, only whether a relationship exists. Second, it handles hierarchical permissions naturally — a user with access to a tenant automatically has access to that tenant's CDN zones, origins, and cached content. Third, it scales horizontally — the tuple store can be partitioned and replicated across regions, matching the distributed nature of CDN edge infrastructure.

How Does OpenFGA Implement the Zanzibar Model?

OpenFGA (Fine-Grained Authorization) is an open-source project originally developed by Auth0, now maintained under the Cloud Native Computing Foundation. It implements the core Zanzibar concepts — relationship tuples, authorization models, and a Check API — as a standalone service that can be self-hosted or consumed as a managed service. For CDN operators, OpenFGA provides the Zanzibar authorization model without the engineering investment of building a custom implementation.

The authorization model in OpenFGA defines types (user, document, folder, tenant) and the relationships between them. Each type declares which relations it supports and how those relations can be resolved. A folder type might define a viewer relation that can be assigned directly or inherited from a parent folder. A CDN zone type might define an admin relation that is inherited from the owning tenant. These inheritance rules are what make ReBAC more expressive than traditional role-based access control.

The Check API is the core authorization primitive. Given a tuple (user, relation, object), it returns whether the relationship exists — either directly in the tuple store or through the inheritance rules defined in the authorization model. For CDN edge authorization, the Check API answers questions like: "Does this API key have read access to this content zone?" or "Is this tenant allowed to configure cache rules for this origin?" The API is designed for low-latency, high-throughput evaluation, making it suitable for inline authorization in API gateway and edge function architectures.

How Does ReBAC Compare to RBAC and ABAC for CDN Authorization?

CDN authorization has traditionally relied on Role-Based Access Control (RBAC). A user is assigned an "admin" or "viewer" role at the tenant level, and that role grants blanket access to all resources within the tenant. This works for simple deployments but breaks down when tenants need granular control — sharing a specific CDN zone with a partner, granting read-only access to monitoring data for a single origin, or allowing a contractor to manage cache invalidation for one domain without touching others.

Attribute-Based Access Control (ABAC) provides more granularity by evaluating policies against attributes of the request context: the user's department, the resource's classification, the time of day, the request's geographic origin. ABAC policies are powerful but complex to write, debug, and audit. A policy engine evaluating dozens of attributes for every edge request introduces both latency and operational complexity. Policy changes require careful testing because the interaction between attribute-based rules can produce unexpected results.

Relationship-Based Access Control (ReBAC) occupies a middle ground that maps naturally to CDN resource hierarchies. Permissions flow through relationships: a user who is an admin of a tenant inherits admin access to every CDN zone owned by that tenant, every origin behind those zones, and every cache configuration applied to those origins. Adding a new zone to the tenant automatically extends the admin's access without any additional permission grants. Conversely, revoking the tenant admin role cascades the revocation across all related resources.

For CDN operators, ReBAC solves the "permission explosion" problem. A multi-tenant CDN serving 10,000 tenants, each with 50 zones, 200 origins, and 500 cache rules, would require millions of individual RBAC role assignments. With ReBAC, the relationships are modeled hierarchically — tenants own zones, zones contain origins, origins have cache rules — and permissions inherit through the hierarchy. The total number of explicitly stored tuples is orders of magnitude smaller than the equivalent RBAC mapping.

How Do Authorization Decisions Work at the CDN Edge?

When a request arrives at a CDN edge server, the authorization flow proceeds through three stages: token extraction, local cache lookup, and remote Check API call. The request carries an authorization token — typically a JWT issued during OAuth token exchange — that identifies the user and optionally includes coarse-grained claims like tenant membership. The edge server extracts the user identity from the token and constructs a Check query: does (user:$subject, $required_relation, $target_resource) exist?

The first lookup hits the edge-local authorization cache. This cache stores recent Check results keyed by the full tuple, with a configurable TTL (typically 30 to 60 seconds). Cache hits return in under 1 millisecond, adding negligible latency to the request path. The cache hit rate depends on traffic patterns — a popular API endpoint serving authenticated requests from a small set of users will see 95%+ cache hit rates, while a long-tail content library accessed by many unique users will see lower rates.

On a cache miss, the edge server calls the OpenFGA Check API over a persistent gRPC connection to the nearest OpenFGA replica. The Check API resolves the relationship by traversing the authorization model's type definitions, following inheritance chains from the target resource up through its parent objects. A query for (user:alice, viewer, origin:api-backend) might resolve through the chain: alice is a viewer of cdn_zone:api, which owns origin:api-backend, so alice inherits viewer access. This resolution typically completes in 5 to 15 milliseconds for simple hierarchies and 20 to 50 milliseconds for deep graphs.

The resolved result is cached at the edge for subsequent requests. To keep the cache consistent, the edge server subscribes to a change notification stream from the OpenFGA service. When a relationship tuple is written or deleted — for example, when a user's access is revoked — the change notification triggers invalidation of the affected cache entries. This design provides sub-millisecond authorization for the common case while maintaining the flexibility to handle complex permission models through the centralized Check API.

What Consistency Models Apply to Distributed CDN Authorization?

The Zanzibar paper introduces the concept of "zookies" (Zanzibar cookies) — opaque tokens that encode the timestamp of a write operation. When a client writes a relationship tuple, the Write API returns a zookie. Subsequent Check requests can include this zookie to guarantee that the authorization decision reflects all writes up to that timestamp. This mechanism provides snapshot isolation without requiring global strong consistency, which would be prohibitively expensive across a globally distributed CDN network.

For most CDN authorization scenarios, eventual consistency is acceptable. Content access permissions change infrequently — a tenant might update access controls a few times per day, while the CDN serves millions of requests per hour. The edge cache already introduces a propagation delay equal to the cache TTL, so eventual consistency in the tuple store adds minimal additional delay. A user who is granted access will typically be able to access content within 30 to 60 seconds, which is acceptable for content delivery workflows.

Strong consistency via zookies is essential for two scenarios. The first is permission revocation for security incidents. When a compromised account's access must be revoked immediately, the revocation write returns a zookie that can be broadcast to all edge caches to force immediate invalidation. The second is regulatory compliance scenarios where access must be provably denied after a specific timestamp — for example, removing access to GDPR-protected content when a data subject exercises their right to erasure. In these cases, the zookie ensures that no edge server serves the content after the revocation is processed, even if the edge cache has not yet expired.

OpenFGA implements this through consistency tokens returned by Write operations. The CDN control plane can propagate these tokens to edge servers along with cache invalidation signals, ensuring that critical authorization changes take effect within seconds rather than waiting for cache TTL expiration. This hybrid consistency model — eventual consistency for routine access with strong consistency for revocations — matches the operational requirements of zero trust CDN infrastructure.

How Do You Model Multi-Tenant CDN Authorization with OpenFGA?

Multi-tenant CDN platforms serve hundreds or thousands of independent customers, each with their own content, configurations, and access policies. The authorization model must ensure strict tenant isolation — a user in Tenant A must never access Tenant B's resources — while supporting flexible intra-tenant permissions like shared zones, delegated administration, and read-only monitoring access.

OpenFGA's type system maps directly to CDN resource hierarchies. The model defines five types: tenant, cdn_zone, origin, cache_rule, and user. The tenant type has admin and viewer relations. The cdn_zone type has admin, editor, and viewer relations, plus a parent relation pointing to its owning tenant. Crucially, the cdn_zone's admin relation is defined as a union: either directly assigned, or inherited from the parent tenant's admin relation. This single rule ensures that tenant administrators automatically have admin access to every zone within the tenant.

The inheritance chain continues downward. An origin type has a parent relation to its cdn_zone, and its admin relation inherits from the parent zone's admin. A cache_rule type has a parent relation to its origin, inheriting admin access from the origin's admin. With these four type definitions and their inheritance rules, the entire CDN resource hierarchy is covered. Adding a new zone to a tenant requires writing a single tuple — (cdn_zone:new-zone, parent, tenant:acme) — and all existing tenant administrators automatically gain access.

Cross-tenant collaboration is handled through direct relationship assignments that bypass the inheritance hierarchy. A partner who needs viewer access to a specific zone receives a direct tuple: (user:partner-bob, viewer, cdn_zone:shared-assets). This grants access to that zone and its child resources without granting any access to the owning tenant's other zones. The partner cannot traverse the relationship graph upward to discover or access sibling zones. This pattern supports common CDN scenarios like shared origins, collaborative content management, and third-party monitoring integrations.

What Are the Performance Considerations for Edge-Scale Authorization?

CDN edge servers process millions of requests per second globally. Every additional millisecond of authorization latency directly impacts content delivery performance. The authorization layer must be designed so that the common case — a repeat visitor accessing cached content — adds zero measurable latency, while the uncommon case — a new visitor or a cache miss — adds minimal and predictable latency.

The edge-local cache is the primary performance optimization. Implemented as an in-memory LRU cache on each edge server, it stores Check results as boolean values keyed by the (user, relation, object) tuple hash. The cache size is bounded by memory constraints — a typical edge server allocates 64 to 256 MB for authorization caching, which holds several million cache entries. Cache entries have a TTL of 30 to 60 seconds, balancing responsiveness to permission changes against cache hit rates.

For cache misses, the edge server maintains a pool of persistent gRPC connections to the nearest OpenFGA replica. Connection pooling eliminates TLS handshake overhead on each request. The OpenFGA service itself is deployed in multiple regions, co-located with CDN edge clusters, to minimize network round-trip time. A well-provisioned deployment achieves p99 latencies under 25 milliseconds for Check API calls, including network transit from the edge to the nearest OpenFGA replica.

Request coalescing reduces the load on the OpenFGA service during cache cold starts. When multiple concurrent requests at the same edge server require the same Check query, only the first request makes the API call. Subsequent requests with the same tuple wait on the first request's result, which is then cached for all of them. This pattern is critical during traffic spikes to a newly deployed origin, where hundreds of requests from the same user might arrive at the edge within the cache TTL window. Without coalescing, each request would independently call the Check API, multiplying the load on the OpenFGA service by the concurrency level.

Prefetching is another optimization for predictable access patterns. When a user authenticates and their access token is validated at the edge, the edge server can proactively issue ListObjects queries to enumerate the user's accessible resources and pre-populate the authorization cache. This shifts the latency of the first Check from the request path to the authentication path, where the user is already waiting for a redirect or token exchange. The trade-off is increased load on the OpenFGA service during authentication, which is acceptable because authentication events are orders of magnitude less frequent than content requests.

How Does OpenFGA Integrate with Existing CDN Authentication?

Most CDN platforms already implement authentication through JWTs, OAuth 2.0 tokens, or mutual TLS certificates. OpenFGA complements these authentication mechanisms rather than replacing them. Authentication answers "who is this?" while OpenFGA answers "what can they do?" The integration point is the edge server's request processing pipeline, where the authenticated identity from the token is used as the user component of the OpenFGA Check query.

For JWT-based authentication, the integration is straightforward. The edge server validates the JWT signature and extracts the sub (subject) claim as the user identity. It constructs a Check query using the subject, the required relation (derived from the HTTP method — GET maps to "viewer," POST/PUT to "editor," DELETE to "admin"), and the target resource (derived from the request path). The Check result determines whether the request proceeds to the cache layer or returns a 403 response.

For passkey and multi-factor authentication flows, the integration requires the authentication service to write relationship tuples that reflect the authentication strength. A user who authenticates with a passkey receives a tuple granting access to sensitive resources, while a user with only a password receives a tuple granting access to non-sensitive resources. This maps authentication assurance levels to authorization decisions without embedding MFA logic in the CDN edge.

Integrating OpenFGA with WAF and bot management systems extends the authorization model to security decisions. A rate-limited client can have its authorization level temporarily downgraded by writing a tuple that restricts access to cached-only content, preventing the client from triggering cache misses that would increase origin load. When the rate limit window expires, the restriction tuple is deleted, restoring normal access. This creates a unified model where both business authorization and security restrictions flow through the same OpenFGA engine.

How Do You Handle Edge-Local Authorization Caching and Invalidation?

The authorization cache at the CDN edge is the critical performance component of the entire system. Without it, every request would require a round-trip to the OpenFGA service, adding 10 to 50 milliseconds of latency that would negate the performance benefits of edge delivery. The cache must be fast (in-memory lookups under 1 millisecond), consistent (reflecting permission changes within an acceptable window), and memory-efficient (each edge server handles thousands of unique users).

The cache implementation uses a two-tier architecture. The first tier is a per-worker in-process hash map that holds the most recently accessed tuples. This eliminates inter-process communication overhead on multi-worker edge servers. The second tier is a shared memory segment or local Redis instance that holds the broader authorization dataset. A cache miss in the first tier falls through to the second tier before making a remote Check API call.

Cache invalidation follows two paths. Proactive invalidation uses the OpenFGA change stream — a persistent connection that pushes write events (tuple creations and deletions) from the OpenFGA service to subscribed edge servers. When a tuple changes, the edge server identifies and removes all affected cache entries. The change stream is filtered by the resources relevant to each edge server, avoiding unnecessary invalidation traffic. Reactive invalidation uses TTL expiration as a safety net — even if a change stream event is lost due to a network partition, the cached entry will expire within the TTL window.

For cache invalidation at global scale, the system uses a fan-out architecture. The OpenFGA service publishes change events to a message bus (such as Apache Kafka or NATS). Regional aggregators subscribe to the bus and relay relevant events to edge servers in their region. This reduces the number of connections to the OpenFGA service and provides regional buffering for change events during network partitions. The aggregators also deduplicate events — if a tuple is written and then immediately deleted, the aggregator collapses both events into a single invalidation signal.

What Real-World Patterns Apply to CDN Authorization with OpenFGA?

Several authorization patterns appear repeatedly in CDN deployments. The first is content-gated access for media CDNs. A streaming platform serves video content through a CDN, with access gated by subscription tier. The authorization model defines subscription types (free, basic, premium) as relations between users and content libraries. The edge server checks (user:viewer, subscriber, content_library:premium) before serving premium video segments. This replaces the common pattern of encoding subscription information in signed URLs, which are difficult to revoke and can be shared.

The second pattern is edge personalization gated by consent. Under GDPR and similar regulations, personalization features require user consent. The authorization model represents consent as a relationship: (user:visitor, consented_to, personalization:tracking). The edge server checks this relationship before applying personalization logic in edge functions, ensuring that personalization is only applied to consenting users without making a round-trip to the consent management platform.

The third pattern is AI agent authorization for edge AI workloads. As AI inference moves to the CDN edge, the authorization model must govern which tenants can execute which models, with what input data, at what rate. OpenFGA models this as relationships between tenants, AI models, and data classifications: (tenant:acme, can_invoke, model:sentiment-analysis) with additional constraints on input data sensitivity. This prevents tenants from accessing models they have not licensed or processing data categories outside their agreement.

The fourth pattern is enterprise federation with external identity providers. Enterprise customers bring their own identity providers (Okta, Azure AD, Ping Identity) and expect their internal group memberships to map to CDN authorization. OpenFGA supports "usersets" that reference external groups: the tuple (group:okta-engineering#member, viewer, cdn_zone:docs) grants viewer access to all members of the Okta engineering group. When group membership changes in the external IdP, a synchronization process updates the OpenFGA tuples, and the change propagates to the edge caches through the standard invalidation flow.

How Does OpenFGA Support CDN Security and Compliance Workflows?

Authorization audit trails are a compliance requirement for CDN platforms handling sensitive data. OpenFGA provides a complete audit log of all tuple writes and Check API calls, including the timestamp, the requesting service, and the authorization decision. For CDN platforms subject to SOC 2, ISO 27001, or HIPAA compliance, this audit trail demonstrates that access to protected content is governed by explicit authorization policies that are consistently enforced across all edge servers.

The authorization model itself serves as documentation for access control policies. Unlike scattered RBAC role assignments or opaque ABAC policies, the OpenFGA model is a single, readable definition of who can access what and through which relationships. Compliance auditors can review the model to understand the permission structure without inspecting individual role assignments or policy rules. When a tenant's access requirements change, the model can be updated and versioned, with the previous version retained for audit purposes.

Security incident response benefits from OpenFGA's ability to quickly enumerate and revoke access. The ListObjects API answers "what resources does this user have access to?" in a single query, enabling rapid assessment of a compromised account's blast radius. The Write API supports batch tuple deletion, allowing all of a user's access to be revoked in a single atomic operation. Combined with the strong consistency mechanism (zookies), access revocation takes effect across all edge servers within seconds.

For DNS-level security, OpenFGA can model authorization for serverless and WebAssembly edge deployments where functions from different tenants execute on shared infrastructure. The authorization model ensures that a tenant's edge function can only access that tenant's data stores, secrets, and upstream APIs, enforcing isolation at the authorization layer even when compute resources are shared. This complements architectural isolation patterns like namespace separation and network policies.

Frequently Asked Questions

What is the difference between OpenFGA and Google Zanzibar?

Google Zanzibar is an internal authorization system described in a 2019 research paper. It handles authorization for Google Drive, YouTube, Cloud IAM, and other Google services, processing over 10 million authorization checks per second. OpenFGA is an open-source implementation of the Zanzibar model, originally developed by Auth0 (now Okta). While Zanzibar is proprietary to Google, OpenFGA provides the same relationship-based access control model as a self-hosted or cloud-hosted service. The core concepts are identical: relationship tuples, authorization models with type definitions, and a Check API that resolves relationship graphs. OpenFGA adds developer-friendly features like a DSL for writing authorization models, a visual playground for testing, and native SDKs for multiple programming languages.

How does relationship-based access control (ReBAC) differ from RBAC and ABAC?

Role-Based Access Control (RBAC) assigns permissions through roles: a user has the "editor" role, and the "editor" role grants write access to all documents. Attribute-Based Access Control (ABAC) evaluates policies against attributes of the user, resource, and environment: a user with department=engineering can access resources tagged department=engineering during business hours. Relationship-Based Access Control (ReBAC) models permissions as relationships between objects: user:alice is a viewer of document:readme, and document:readme is in folder:engineering, so alice inherits viewer access to all documents in the engineering folder. ReBAC excels at modeling hierarchical and inherited permissions that would require complex role hierarchies in RBAC or verbose policies in ABAC. For CDN authorization, ReBAC naturally models tenant-to-content relationships, content hierarchies, and delegated access patterns.

Can OpenFGA handle the latency requirements of CDN edge authorization?

OpenFGA's Check API typically responds in 5 to 15 milliseconds for simple relationship lookups, and 20 to 50 milliseconds for queries that traverse multiple relationship hops. For CDN edge authorization where sub-millisecond decisions are ideal, this latency is too high for inline request processing. The solution is edge-local caching: the CDN edge node maintains a local cache of recent authorization decisions, keyed by (user, relation, object) tuples. Cache entries have short TTLs (30 to 60 seconds) and are invalidated through a change notification stream from the OpenFGA server. This hybrid approach delivers sub-millisecond authorization at the edge for cached decisions while maintaining the flexibility of the Zanzibar model for cache misses. The consistency trade-off is that permission revocations take up to one TTL period to propagate, which is acceptable for most CDN content access patterns.

What consistency model does Zanzibar use for distributed authorization?

Zanzibar uses a concept called "zookies" (Zanzibar cookies) to provide tunable consistency. When a relationship tuple is written, the write returns a zookie that encodes the timestamp of the write. Subsequent Check requests can include this zookie to ensure the authorization decision reflects all writes up to that timestamp. This is called "check with snapshot isolation." Without a zookie, the Check API uses eventual consistency, meaning a recently written tuple might not be reflected in the authorization decision. OpenFGA implements this through consistency tokens returned by Write operations. For CDN workloads, eventual consistency is typically acceptable because content access permissions change infrequently, and the edge cache already introduces a propagation delay. Strong consistency via zookies is used for sensitive operations like revoking access to protected content or GDPR right-to-erasure requests.

How do you model multi-tenant CDN authorization with OpenFGA?

Multi-tenant CDN authorization maps naturally to OpenFGA's type system. Define types for tenant, cdn_zone, origin, cache_rule, and user. The authorization model establishes relationships: a tenant has administrators and viewers, a cdn_zone belongs to a tenant (and inherits the tenant's administrators), an origin belongs to a cdn_zone, and cache_rules belong to a cdn_zone. A user who is an administrator of tenant:acme automatically has admin access to all cdn_zones, origins, and cache_rules owned by that tenant through relationship inheritance. This eliminates the need to maintain separate access control lists for each CDN resource. When a new zone is created under a tenant, all tenant administrators automatically have access without any additional permission grants. The model also supports cross-tenant collaboration: a user can be granted viewer access to a specific cdn_zone without gaining access to the entire tenant — a pattern essential for enterprise CDN deployments.