Authorization is having a bit of a moment in the tech world right now. Organizations like Apple are investing more heavily in policy-driven access control, signalling a shift towards policy as code. As this approach is solidified, it’s becoming clear that the next big revolution in the authorization space will be focused on a specific segment — specifically, the data layer.

Enter OpenFGA, a Linux Foundation incubation project that is designed around a singular goal — making fine-grained, relationship-based authorization scalable, predictable, and human-readable. While solutions like OAuth and OpenID Connect are all about who the user is, OpenFGA is about what the user can do with the data they access — and how they are related to the system overall.

Below, we’re going to take a deep dive into OpenFGA and look at when and where it could be useful in the API space.

What is OpenFGA?

OpenFGA: an open-source authorization solution for granular relationship-based access control.

OpenFGA is an open-source authorization engine inspired by Google’s Zanzibar system. In essence, it is all about relational context — it deploys relationship-based access control (or ReBAC), which defines user permissions based specifically on the relationship between the user and the data objects they’re trying to use.

This is a fundamental shift in how you describe authorization, so it bears some consideration here. OpenFGA’s authorization model is a shift away from simple classification and into relational status — for instance, a user can have a relationship to a certain data object, and the relationship between that data object and other data objects can impact the authorization schema. A user might want to access a document, and while they may not have explicit authorization to that document, they may have a “viewer” relationship to the parent document folder, which thereby extends relational access control for the end user.

This introduces a sort of fuzzy logic to access control. Suddenly, you express authorization less in terms of absolutes and more in terms of relational attributes, for instance, ‘manager of a user,’ ‘contributor to parent document,’ or ‘department member.’ These relationships are then stored as a contextual relationship tuple:

model
  schema 1.1

type user

type group
  relations
    define member: [user]

type document
  relations
    define viewer: [group#member]

When a user attempts an action or interaction, these tuples can then be checked and verified, as well as extended across objects and systems, validating whether the user has the necessary permissions for the given data object or system.

This approach is a notable movement away from the more monolithic and static methods for authorization currently in use. Instead of simply defining a user as an ‘admin’ or ‘viewer,’ you can now broker access dependent on the relationship between the user and object, as well as between the object and other objects.

For complex microservices, APIs, and multi-tenant SaaS deployments, this cuts the complexity quite significantly and ensures that fine-grained authorization is based on observable and realistic relationships and context rather than static and unyielding frameworks.

It should be noted that OpenFGA is not a replacement for your authentication and authorization provider — it is fundamentally a complementary relationship store and decision engine. By defining a schema for your relationships and storing these relationships as tuples, you can actively review, evaluate, and coordinate access across OpenFGA’s SDKs and APIs.

OpenFGA In Practice

What does this look like in practice? In many ways, it looks the same as with any authorization process — the difference, however, lies in the centralization of the checking process. When a request hits an endpoint, a service calls a /check endpoint with three key pieces of data:

• User, which is the actual user in question making the request.
• Action, which is the permission or verb being requested by the user.
• Object, or the resource being acted upon within the data.

These pieces of data are then examined within the context of the stored tuple — both in terms of the request from the user in question as well as the relationship between the data objects themselves. From here, OpenFGA either returns a true or false response to authorize the access.

Where this gets more complex is when inheritance, delegation, and hierarchy come into play. Because each relational tuple can define a relationship that can then pass ownership or access to underlying resources, you can get quite complex relational controls at scale.

Where OpenFGA Makes Sense

So, where does this kind of approach make sense? OpenFGA shines in domains with complex resource graphs, dynamic permissions, and complex relational data objects. A few good examples of this kind of reality include:

• Multi-tenant SaaS: API providers with a SaaS offering may have different customers with access policies that may be quite complex. In this sort of situation, your choices are typically either setting up an authorization schema for each individual system to customize or establishing some kind of provider-defined setup. With OpenFGA, you can allow for tenant-dictated access controls, which then interface with your centralized rights management much more effectively and seamlessly.
• Enterprise data platforms: In this sort of environment, you can have complex hierarchical datasets while still requiring relatively dynamic cross-org models for access and visibility. OpenFGA makes perfect sense here, as it allows you to control access by relationships to the data rather than forcing a “one size fits all” solution onto the overall data system.

Ideally, wherever you need controls based on relational data access rather than top-down one-size-fits-all schemas, OpenFGA makes sense. For example, the OpenFGA newsletter mentions how virv.ai, an AI-driven collaboration platform, is using OpenFGA to relate individuals and agents to artifacts and resources. Other developer-centric tools, like Grafana Labs, AppsCode, and Incus, are all beginning to use OpenFGA as well.

How OpenFGA Complements OAuth and OpenID Connect

It’s important to recognize that this is not a drop-in replacement for other authorization systems. In fact, in most cases, you’ll want to integrate this with your existing OAuth or OpenID Connect solutions.

These other options can be broadly said to handle identity and consent — in essence, validation that you are who you say you are, and approval of your access to the API or resource. OpenFGA, on the other hand, handles authorization related to the data proper — it is an addendum around the data and objects themselves.

For this reason, you should not think of it as an alternative or a replacement. A good way to think about it is like this:

• OAuth says: “Bill can access the Shipments API.”
• OpenFGA says: “Bill can view shipments he initiated or shipments managed by those that report to him.”

Conclusion

Ultimately, authorization has always been the unglorious side of security — it’s invisible until it breaks, and then all chaos kicks off. But as systems get more complex, and the data they work upon more distributed, we need to start figuring out how to make data-centric authorization a more integrated and top-level concern.

OpenFGA is a big part of this. It offers a new approach that’s composable, expressive, relational, and human-contextual. It doesn’t replace other solutions, but augments them for better management and control, giving API builders a way to describe and control access as data rather than as code.

If you’re working with APIs that are more about relational systems and complex sets of data than a simple set of singular functions or data objects, something like OpenFGA will allow you better — and significantly more granular — control over your systems and flows.