Differences

This shows you the differences between two versions of the page.

--- security:authorization:store [2026/07/09 03:38] – created phong2018
+++ security:authorization:store [2026/07/09 03:39] (current) – removed phong2018
@@ Line 1: / Line 1: @@
-====== OpenFGA Store ======
-A **Store** is the top-level container in OpenFGA. Think of it as one project or
-one workspace. Everything for one authorization setup lives inside it, and
-nothing leaks out to other stores.
-===== Why stores exist =====
-You need a boundary. Without one, all your rules and data would sit in a single
-shared pile. Stores give you clean separation.
-Each store is fully isolated. A Check inside store A can never see tuples that
-live in store B. This lets you keep different apps, or different environments
-(dev, staging, production), completely apart.
-===== What is inside a store =====
-A store holds three things.
-^ Part ^ What it is ^
-| **Authorization models** | The rules (''type'' and ''relation'' definitions). Versioned. |
-| **Relationship tuples** | The data. Small facts like ''(account:123, assignee, role:manager)''. |
-| **Assertions** | Saved tests: example questions with expected answers. |
-==== Authorization models ====
-The rules. A store can hold //many versions// of the model over time. Each
-version gets its own model ID. When you change the rules, you write a new
-version; the old one stays. Your tuples keep working, and you can point a Check
-at a specific model version if you want.
-==== Relationship tuples ====
-The data. All the small facts like:
-<code>
-(account:123, assignee, role:manager)
-</code>
-This is usually the biggest part, sometimes millions of rows.
-==== Assertions ====
-Saved tests. You write example questions with expected answers, like "manager
-should be allowed to approve → true". They let you check that your model still
-behaves correctly after a change.
-===== How you use a store =====
-Every store has a unique **store ID** (a long string). This ID is the key to
-everything.
-  - **Create** a store once. OpenFGA gives you back its ID.
-  - **Scope** every API call to that ID (write a model, add tuples, run a Check).
-  - **Isolate** by design. One store's data never mixes with another's.
-===== How many stores should you have =====
-This is a design choice, not a fixed rule. Common patterns:
-  * **One store per environment**: separate dev, staging, production. Safest start.
-  * **One store per application**: give each unrelated app its own store.
-  * **One store per tenant**: strong isolation, but more stores to manage. \\ Many teams instead keep all tenants in one store and separate them using object IDs (like ''organization:acme'' vs ''organization:globex'').
-<note tip>
-A good default: start with **one store per environment**, and only split further
-when you have a real reason.
-</note>
-===== See also =====
-  * [[https://openfga.dev|OpenFGA official site]]
-  * [[https://openfga.dev/docs/getting-started/create-store|Create a store]]