Series · 5 articles

Authorization with OpenFGA

From Zanzibar to multi-tenancy, five articles on permissions that scale

When permissions stop fitting in a `role` column on the users table, the role model no longer holds. The series starts from the concepts behind Google Zanzibar, connects them to Keycloak, and gets to the problems you actually run into: isolating several organizations, resolving deep hierarchies, and the cost of ListObjects once the resources become many.

5
Published articles
72
Minutes of reading
Avanzato
Level
OpenFGAZanzibarReBACKeycloakMulti-tenancyAuthorization

The moment roles stop being enough

As long as permissions fit in a role column on the users table, the role model works and there is no reason to change it. It stops working with the first request that does not fit inside it: this document is shared with that user, but read-only, and only as long as it stays in the project they are a member of.

At that point you add an exceptions table, then a flag, then an if in the controller. The permission stops being data and becomes code scattered around, and nobody can answer the question that matters any more: who can see this resource, and why?

Google faced the same problem at scale and published the model behind it, Zanzibar: permissions become relationship tuples, not roles. OpenFGA is the open source implementation of that model.

The series starts from the concepts, connects them to Keycloak to separate authentication from authorization, and gets to the problems you actually run into: isolating several organizations in the same system, resolving deep hierarchies, and the cost of reverse queries once the resources become many.

What you will learn

  • Understand the Zanzibar model: relationship tuples instead of roles
  • Connect OpenFGA to Keycloak, separating authentication from authorization
  • Isolate several organizations in the same system without duplicating the model
  • Resolve deep hierarchies without writing application code
  • Recognize when ListObjects becomes the bottleneck, and how to work around it

Articles in the series

  1. 01
    Zanzibar for Everyone: Authorization Models and the Tuple Approach 14 min

    From RBAC to Zanzibar: how OpenFGA's tuple model works, the DSL for defining relationships, and the three fundamental questions of authorization.

  2. 02
    OpenFGA + Keycloak: Bridging Identity and Permissions 15 min

    How to integrate OpenFGA with Keycloak: user synchronization, JWT as the bridge, contextual tuples, and strategies for keeping identity and authorization aligned.

  3. 03
    Multi-tenancy with OpenFGA: Isolation Without Multiplying Complexity 13 min

    Two strategies for multi-tenancy with OpenFGA: store-per-tenant and type-per-tenant. How to achieve structural isolation without scattering WHERE tenant_id everywhere.

  4. 04
    Deep Hierarchies, Inverse Queries, and the WHERE Problem 17 min

    How to handle N-level hierarchies in OpenFGA, optimize ListObjects with fast/slow path, and implement Dynamic Data Masking as a complementary pattern.

  5. 05
    ListObjects in Production: Caching, Pre-materialization, and BatchCheck 13 min

    Why ListObjects becomes the bottleneck in OpenFGA, and how to address it: Redis caching, pre-materialized read models, BatchCheck, and invalidation strategies.