Table of Contents
OpenFGA
OpenFGA is an open-source authorization engine. Its only job is to answer one question: “Is this user allowed to do this thing?” It does not run your app. It sits beside your app and says yes or no.
Why it exists
Permission logic gets messy. Rules like “only the owner can edit” or “managers can approve” spread across your code and get tangled.
OpenFGA pulls all of that into one place. Your app stops asking “does this user have the right role?” and instead asks OpenFGA “can this user do this?”
- One source of truth.
- One place to change the rules.
It is based on a Google paper called Zanzibar, the system Google uses for Docs, Drive, and YouTube. OpenFGA is an open version of that idea.
What it is built on: ReBAC
OpenFGA uses relationship-based access control (ReBAC).
- RBAC (older): a user has a role, a role has permissions. Simple but rigid.
- ReBAC: access comes from how objects connect to each other.
Example of relationships:
- A user is the owner of a document.
- A document is inside a folder.
- So the user can also reach things in that folder.
Access flows along these links.
The main parts
| Part | What it is |
|---|---|
| Store | A container holding your model and data. One project. |
| Authorization model | The rules. Written in a DSL. Holds the shape, not real users. |
| Relationship tuples | The data. Small facts as (user, relation, object). |
| Check API | The question. Returns allowed: true or allowed: false. |
A tuple looks like this:
(account:123, assignee, role:manager)
This means “account 123 is an assignee of role manager”. These tuples often come from your database through CDC (Change Data Capture).
How a Check works
The model plus the tuples form a graph. A Check walks that graph.
Example question:
Check: can account:123 do pos_order_approve on organization:default?
The steps:
- Your app asks the question.
- OpenFGA reads the model to learn what path would allow this.
- OpenFGA walks the tuples:
- account:123 is assignee of role:manager
- role:manager grants pos_order_approve
- Both links connect, so the answer is
allowed: true.
If any link is missing (for example, 123 was never made a manager), the walk
fails and the answer is allowed: false.
Other useful features
- List objects: “Which documents can this user read?” Good for filtering results.
- List users: “Who can access this document?” Good for sharing screens.
- Conditions (ABAC): grants that only apply if some data is true, like
“only under $500” or “only during work hours”.
How it fits your app
Input → Process → Output:
- Input: write the model once, keep tuples in sync with your database.
- Process: on every sensitive action, call Check before doing the work.
- Output: OpenFGA returns
trueorfalse; your app allows or blocks it.
The result: rules live in one clear place, checks are fast, and different teams can own different parts of the model.