Auth0 released version 1.0 of OpenFGA, an open-source authorization server for fine-grained access control use cases. This release indicates the stability of OpenFGA’s APIs and its readiness for production deployments.
Open Fine Grained Authorization (OpenFGA) is the engine at the core of Auth0’s Authorization-as-a-Service offering, Auth0 FGA. Released as a Developer Community Preview in December 2021, Auth0 FGA was designed to help developers provide fine-grained access control at scale.
Auth0 FGA is based on Google's Zanzibar authorization service, which underpins access control for all Google products worldwide and is the foundation for Google Cloud IAM. In a paper released in 2019, Google shared the core data model and architecture for Zanzibar, after which several implementations, e.g. Keto , SpiceDB, Carta and Auth0 FGA, followed.
A few months after the launch of Auth0 FGA, its core engine and SDKs were published as the OpenFGA project.
An authorization model language and relationship tuples are at the core of Zanzibar’s design and, therefore, OpenFGA’s. The authorization model language enables a flexible definition of the entities in a domain, objects over which permissions could apply, and possible relationships between them. An example of this for a document-sharing use case is shown below:
model
schema 1.1
type document
relations
define viewer: [domain#member,user]
define commenter: [domain#member,user]
define editor: [domain#member,user]
define owner: [domain#member,user]
type domain
relations
define member: [user]
type user
After an authorization model is defined, relationship tuples, representing concrete relations between entities and objects, can be specified. Below is a relationship tuple based on the previous document-sharing use case:
[
{
"user": "user:anne",
"relation": "editor",
"object": "document:new-roadmap",
},
]
Authorization models and relationship tuples can be added to the OpenFGA server via API or language-specific SDKs. Once these are in place, applications can use the Check API to evaluate relationships. An example of this with the Go SDK is shown below:
body := fgaSdk.CheckRequest{
AuthorizationModelId: fgaSdk.PtrString("1uHxCSuTP0VKPYSnkq1pbb1jeZw"),
TupleKey: fgaSdk.TupleKey{
User: "user:anne",
Relation: "editor",
Object: "document:new-roadmap",
},
}
data, response, err := fgaClient.OpenFgaApi.Check(context.Background()).Body(body).Execute()
// data = { allowed: true }
While the OpenFGA server can store authorization models and relationship tuples in memory, production use cases require persistent storage, which it provides via adapters to MySQL or PostgreSQL databases.
Given OpenFGA is a core part of an Auth0 product, questions are often asked about its reasons for being open-sourced and its potential longevity as a project. In response to those, Auth0 product manager, Andrés Aguiar, writes: "We believe there’s an opportunity to create a large ecosystem around a fine-grained authorization system ... [Auth0/Okta] is a leader in the Identity Access Management space, is trusted by thousands of customers, is cloud-agnostic, and has the financial capacity to invest in the product long-term."
To further accelerate its adoption by the community, OpenFGA was put forward as a Cloud Native Computing Foundation (CNCF) Sandbox project, for which it was accepted in September 2022.
As OpenFGA is focused on enabling the development of authorization models that can be queried via an API, it is often compared to Open Policy Agent (OPA). While both products provide a flexible declarative language for access control models, the primary difference is in modelling paradigms. OpenFGA is centred around a Relationship-based Access Control (ReBAC) model, while OPA allows the definition of Attribute-based Access Control (ABAC) and Role-based Access Control (RBAC) models.
The OpenFGA server and its SDKs are maintained on GitHub and released under Apache 2.0 open-source license.
