Who Gets to Open the Door? A Short Story About OpenFGA

The building with too many keys

Imagine an office building.

Every employee gets a badge. The badge says: Engineer, or Manager, or Intern.

For years, that's how the building decides who opens which door. "Engineers can enter the server room. Managers can enter the finance room." Simple.

Then the building grows.

Now there's a server room shared with a partner company. A finance room that one specific intern — just for this month — needs access to. A private meeting room, unless you're invited to that one meeting.

Suddenly, "Engineer" and "Manager" aren't enough. You don't just need a role. You need a relationship — this person, to that door, for this reason.

That building is your app. That badge system is old-school access control. And the moment it stopped scaling — that's exactly the problem OpenFGA was built to solve.



Meet OpenFGA

OpenFGA is an open-source authorization engine. It's one job: answer the question "can this user do this thing to this object?" — fast, and at scale.

It's built on an idea from Google, called Zanzibar — the system that quietly decides who can view a Google Doc, edit a Drive file, or join a Calendar event, for billions of users, in milliseconds.

OpenFGA takes that same brain and makes it available for anyone to run.

It's not about roles anymore. It's about relationships:

  • Alice is the owner of document-42
  • Bob is a viewer of document-42
  • The finance team is a member of the finance folder, and anyone in that folder can view every file inside it

Notice something? None of that is "Bob is an Editor." It's "Bob relates to this specific thing, in this specific way."


The three ingredients

OpenFGA runs on three simple pieces:

1. A model — the rulebook. It defines what relations can exist. ("A document can have owners, editors, and viewers. Owners can also edit.")

2. Tuples — the facts. Tiny statements like (alice, owner, document:42). Millions of these live in the store, and they're just... data. Add one, remove one, done.

3. A check — the question. Your app asks OpenFGA: "Can Alice view document:42?" OpenFGA looks at the model, looks at the tuples, and answers allowed or denied — often in single-digit milliseconds.

That's it. Rulebook, facts, and questions. Everything else — RBAC, hierarchies, sharing, nested teams — is just clever combinations of those three things.


"Wait — isn't this what JWT does?"

Good question. And no — they're solving two completely different problems.

JWT (JSON Web Token) answers: "Who are you?" It's a signed token you carry around after logging in, proving your identity to every service you talk to. That's authentication.

OpenFGA answers: "Now that I know who you are — what are you allowed to touch?" That's authorization.

Think of it like walking into that office building again:

  • Your badge scan at the front door is the JWT. It confirms you are you.
  • OpenFGA is the security guard standing at every single door inside, checking — for this door, right now — do your relationships say you're allowed in?

A JWT can carry a few basic claims like role: admin, but it goes stale the moment permissions change — you'd have to log out and back in to get a new token. OpenFGA, on the other hand, checks live, real-time relationship data every time. Revoke access, and the very next check reflects it — no waiting for a token to expire.

They're not rivals. Most real systems use both: JWT to say who's knocking, OpenFGA to decide which doors open for them.


Why not just hardcode it?

You could write if user.role == 'admin' all over your codebase. Most apps start that way.

Then requirements grow — nested teams, shared folders, temporary access, partner orgs — and that logic multiplies into hundreds of scattered if statements. Nobody can say with confidence "who can access what" anymore. Audits become guesswork. Bugs become security holes.

OpenFGA pulls all of that logic out of your code and into one central, queryable system. One place to define the rules. One place to audit them. One fast API to ask questions against.


Where you'd actually use this

A few real shapes this solves well:

  • Google-Drive-style sharing — files, folders, and nested permissions that cascade downward
  • Multi-tenant SaaS — org A's data must never leak into org B's view, no matter how complex the internal teams get
  • Fine-grained document control — not just "can edit," but "can edit this clause, in this contract, because you're on this review team"

Any place where "role" alone stops being precise enough — that's OpenFGA territory.


The takeaway

Roles tell you what kind of person someone is. Relationships tell you what they're actually connected to, right now, in detail.

JWT tells the door who's knocking. OpenFGA decides whether it opens.

That shift — from roles to relationships — is the whole story of OpenFGA.



If you want to go build this yourself, OpenFGA's getting-started docs walk through installing the SDK, creating a store, and running your first check: openfga.dev/docs/getting-started