Google Zanzibar to globalny silnik uprawnień działający w Google, który pozwala na naprawdę fajne i rozbudowane zarządzanie dostępami, nawet w oparciu o pojedyncze pliki jak w Google Drive, czy wydarzeniem w Kalendarzu, albo zasobem w Google Cloud. OpenFGA to open-source’owy silnik autoryzacji (fine-grained authorization) inspirowany tym rozwiązaniem.
To pierwszy wpis z serii, znajdziesz je pod tagiem OpenFGA
Zamiast trzymać reguły dostępu w setkach warunków if/else, OpenFGA modeluje uprawnienia jako graf relacji (ReBAC): fakty typu „Anna jest edytorem dokumentu X” plus model określający, jak relacje się składają i dziedziczą.
Autoryzacja, której nie widać, dopóki apka nie urośnie
Budujesz sobie platformę, użytkownicy tworzą pliki, dokumenty, jakieś inne zasoby. Udostępniają je innym współpracownikom, przerzucają między folderami, które udostępnione są kolejnym osobom.
Można to zrobić w prostym zarządzaniu rolami, ustalamy owner_id, jakieś pole permissions, może nawet jakieś role tworzymy.
To działa, nie powiem, że nie. Do czasu, bo im więcej takich zasobów, tym zaczyna być problem, gdy schemat dostępów jest bardziej skomplikowany, np.:
- Udostępnienie pliku kolejnym osobom, a nie jednej osobie.
- Grupa „szefowie” mają mnieć wlot do każdego elementu.
- Folder XYZ udostępniony jest userowi A, a plik ZYX userowi B. Jak zarządzać dostępem dla pliku ZYX w folderze XYZ? Co widzisz user B, a co widzi user A? Im głębiej, tym bardziej dziwne te uprawnienia
- Zasady uprawnień RBAC puchnie i rozbudowuje się z każdą zmianą, każdym zagłębieniem.
Proste rozwiązanie, skuteczne w wielu miejscach, okazuje się ifologią, walką ze skomplikowaniem systemu dostępów, długiem technicznym opartym o labirynt zależności. Proste read-only rośnie do etapu budowania drzewka tego co można, a czego nie i sprawdzanie tego trwa wieczność. Testowanie tego? Masakra.
ReBAC to odpowiedź na to. Śledzenie tego „kto co może” jest realizowane w dziesiątkach miejsc, audytowanie to horror, więc ReBAC upraszcza to poprzez zadawanie pytań: „czy user:otlet ma relację edit do document:podwyzki?” – w odpowiedzi masz, że allowed: true w kilka milisekund, a nie sekundy na szukanie kto i co. Reguły są proste, a nie ifologia.
Jednak, by to osiągnąć w środowisku wielu aplikacji, i ten system należy wyrzucić osobno. Tutaj jako rozwiązanie u siebie możesz zastosować OpenFGA.
Google Zanzibar – geneza modelu
OpenFGA nie powstał w próżni. Jego fundamentem koncepcyjnym jest Google Zanzibar – globalny system autoryzacji Google, opisany w pracy naukowej opublikowanej w 2019 roku. Zanzibar obsługuje kontrolę dostępu dla Google Drive, YouTube, Calendar, Google Cloud i dziesiątek innych produktów, operując na skali miliardów obiektów i bilionów relacji.
Kluczowe idee, które Zanzibar wniósł do branży:
- Uprawnienia jako graf relacji, nie reguły w kodzie. Zamiast rozsiewać logikę dostępu po aplikacjach, Zanzibar centralizuje ją w jednym systemie przechowującym relationship tuples – atomowe fakty typu „użytkownik U ma relację R do obiektu O”.
- Model + fakty. Reguły składania i dziedziczenia relacji żyją w osobnym modelu; dane (tuple) mówią, co faktycznie zachodzi. Ta separacja jest sercem podejścia.
- Spójność (consistency). Zanzibar wprowadził mechanizm Zookies – tokeny snapshotu pozwalające gwarantować, że decyzja autoryzacyjna nie „cofnie się” względem wcześniej widzianego stanu (ochrona przed new enemy problem). To charakterystyka samego Zanzibar; implementacje open-source podchodzą do spójności różnie.
Z pracy Zanzibar wyrosły dwie główne implementacje open-source:
| Implementacja | Twórca | Akcent |
|---|---|---|
| OpenFGA | Okta / Auth0 (dziś projekt CNCF) | Neutralne zarządzanie, prosty DSL, szeroka baza maintainerów |
| SpiceDB | Authzed | Silny nacisk na spójność (tokeny Zookies), własny język schematu |
Słownik pojęć
| Pojęcie | W jednym zdaniu |
|---|---|
| authN (uwierzytelnianie) | Potwierdzenie, kto to jest (logowanie, MFA). |
| authZ (autoryzacja) | Decyzja, co dana osoba może zrobić z danym zasobem. |
| RBAC / ABAC / ReBAC | Trzy modele uprawnień: przez role / przez atrybuty / przez relacje. OpenFGA używa ReBAC. |
| Tuple (fakt) | Pojedyncza informacja o dostępie: „Anna jest edytorem dokumentu X”. |
| DSL / model autoryzacji | Zapis reguł określający, jak relacje się składają i dziedziczą. |
OpenFGA – twój własny Google Zanzibar
OpenFGA to open-source’owy silnik autoryzacji (nie uwierzytelniania!), inspirowany systemem Google Zanzibar. Prosta analogia: uwierzytelnianie (authN) to dowód przy wejściu do biura – potwierdza, kim jesteś. Autoryzacja (authZ) to klucze do konkretnych pomieszczeń – mówi, dokąd wolno ci wejść. OpenFGA zajmuje się wyłącznie tym drugim. Projekt został przyjęty do CNCF we wrześniu 2022, a 28 października 2025 awansował do poziomu Incubating.
To nie jest kolejna biblioteka w repozytorium. To serwer API (HTTP na porcie :8080, gRPC na :8081) uruchamiany w kontenerze Docker, który:
- Otrzymuje pytanie: „czy
user:annema relacjęeditordodocument:roadmap?”. - Zwraca odpowiedź
allowed: true/falsew milisekundach. - Centralizuje wszystkie reguły dostępu w jednym miejscu, niezależnie od liczby aplikacji, które z nich korzystają.
Co istotne, jeden silnik obsługuje RBAC, ABAC i ReBAC w ramach tego samego modelu – nie wymusza jednego podejścia, lecz pozwala je łączyć. Dane relacji mogą być przechowywane w istniejącej bazie: PostgreSQL, MySQL, SQLite lub w pamięci na potrzeby developmentu.
ReBAC: Relationship-Based Access Control
Sercem OpenFGA jest ReBAC – model, w którym uprawnienia wynikają z relacji między użytkownikami a obiektami, a nie ze sztywno przypisanych ról.
| Model | Jak działa | Ograniczenie | Kiedy stosować |
|---|---|---|---|
| RBAC | User -> rola -> uprawnienia | Eksplozja ról przy uprawnieniach per zasób; brak hierarchii | Proste, statyczne uprawnienia |
| ABAC | Reguły na atrybutach (dział, kraj, tag) | Trudny audyt „kto ma dostęp do X” | Decyzje kontekstowe (godzina, IP) |
| ReBAC | Graf relacji user<->obiekt<->obiekt | Wymaga osobnego serwera i modelu | Hierarchie, współdzielenie, dziedziczenie |
Dla każdej aplikacji z zasobami współdzielonymi między użytkownikami oraz zespołami z dziedziczeniem uprawnień ReBAC jest naturalnym dopasowaniem.
Fakt z rynku: Segment fine-grained authorization rośnie dwucyfrowo (CAGR rzędu 15–19% rocznie), napędzany adopcją chmury, architekturą mikrousługową i wymogami compliance. OpenFGA jest w tej kategorii projektem wiodącym.
OpenFGA – jak działa?
Kluczowe pojęcia
| Pojęcie | Opis |
|---|---|
| Store | Izolowana przestrzeń danych autoryzacji (np. osobny store per środowisko/tenant). |
| Authorization Model | Definicja typów i relacji w języku DSL. Wersjonowany – każdy zapis tworzy nową wersję. |
| Relationship Tuple | Pojedynczy fakt: (user, relation, object), np. user:otlet jest editor obiektu document:podwyzki. |
| Type | Rodzaj obiektu w systemie (user, group, folder, document). |
| Relation | Nazwana zależność w obrębie typu (owner, editor, viewer). |
| User / Object | Strony relacji, w formacie type:id (user:otlet, document:podwyzki). |
Zasada: Authorization Model (reguły) + Relationship Tuples (fakty) -> wynik Check. Model określa, jak relacje się składają, a tuple mówią, co faktycznie zachodzi.
Model w praktyce
Zobacz, jak to wygląda – poniżej cały model dla dokumentów z folderami i grupami:
model
schema 1.1
type user
type group
relations
define member: [user]
type folder
relations
define owner: [user]
define parent_folder: [folder]
define viewer: [user, group#member] or owner or viewer from parent_folder
type document
relations
define owner: [user]
define parent_folder: [folder]
define editor: [user, group#member] or owner
define viewer: [user, group#member] or editor or viewer from parent_folder
define can_edit: editor
define can_view: viewer
Kilka kluczowych wzorców:
[user, group#member]– relację można nadać zarówno pojedynczemu użytkownikowi, jak i wszystkim członkom grupy. To esencjonalne dla integracji z dostawcami tożsamości (EntraID, Google Workspace, Auth0).viewer from parent_folder– dziedziczenie: kto widzi folder, widzi też jego dokumenty. Zmiana na folderze propaguje się bez przepisywania tupli wszystkich dokumentów.can_edit/can_view– relacje „obliczeniowe” reprezentujące akcje. Aplikacja pyta ocan_edit, nie oeditor– dzięki temu logika składania uprawnień żyje w modelu, nie w kodzie.
API: cztery endpointy, zero zbędnych
OpenFGA udostępnia zaledwie cztery kluczowe operacje API. Wystarczą do absolutnie wszystkiego:
| API | Zastosowanie |
|---|---|
Write | Dodaje/usuwa relationship tuples (przy tworzeniu zasobu, zmianie właściciela, synchronizacji grup). |
Check | Autoryzacja pojedynczej akcji: „czy user ma relation do object?” → allowed: true/false. |
Expand | Zwraca pełny graf relacji dla pary (relation, object) – do debugowania „dlaczego ktoś ma dostęp”. |
ListObjects | Zwraca listę obiektów danego typu, do których user ma daną relację – do filtrowania querysetów (np. „które dokumenty user widzi”). |
Przykład: utworzenie dokumentu i nadanie właściciela:
# POST /stores/{store_id}/write
{
"writes": {
"tuple_keys": [
{ "user": "user:otlet", "relation": "owner", "object": "document:podwyzki" }
]
}
}
Zapytanie, czy Otlet może edytować:
# POST /stores/{store_id}/check
{
"user": "user:otlet",
"relation": "can_edit",
"object": "document:podwyzki"
}
-> { "allowed": true }
Listowanie dokumentów widocznych dla Janusza:
# POST /stores/{store_id}/listobjects
{
"user": "user:janusz",
"relation": "can_view",
"type": "document"
}
-> { "objects": ["document:podwyzki", "document:wyplaty"] }
OpenFGA a alternatywy
AWS Cedar
Cedar to język polityk autorstwa AWS (używany w AWS SSO). Podobny cel, inne podejście:
- Cedar – deklaratywny, formalnie zweryfikowany, optymalizowany pod wydajność i bezpieczeństwo. Integruje się głębiej z ekosystemem AWS.
- OpenFGA – bardziej uniwersalny, niezależny od chmury, z gotowym serwerem i SDK. Lepszy dla multi-cloud / self-hosted.
SpiceDB
SpiceDB (Authzed) to druga popularna, otwartoźródłowa implementacja modelu Zanzibar:
- Wspólny rodowód – oba wywodzą się z pracy Google Zanzibar, oba operują na grafie relacji (ReBAC).
- SpiceDB – kładzie silny nacisk na spójność (tokeny Zookies) i ma własny język schematu; dojrzały ekosystem komercyjny wokół Authzed.
- OpenFGA – projekt CNCF z neutralnym zarządzaniem, prostszym DSL i szeroką bazą maintainerów korporacyjnych. Wybór częsty tam, gdzie liczy się niezależność od jednego dostawcy i przynależność do CNCF.
Podsumowanie
- OpenFGA to nie RBAC. Przy zasobach współdzielonych, dziedziczeniu uprawnień i grupach to narzędzie dopasowane do problemu.
- To nie biblioteka, to serwer. Autoryzacja zostaje oddzielona od logiki aplikacji – jedna odpowiedzialność, jeden serwis, łatwiejszy audyt.
- ReBAC działa na grafie relacji, nie na tabelkach ról. To kluczowa zmiana mentalna i źródło siły modelu, pochodzące wprost z Google Zanzibar.
- OpenFGA nie uwierzytelnia. authN i authZ pozostają rozłączne. OpenFGA mówi „co może”, nie „kto to jest”.
Przy paru statycznych rolach OpenFGA to przerost formy – zwykły RBAC w bazie wystarczy. Ale gdy zasoby są współdzielone, foldery dziedziczą uprawnienia, a grupy z IdP mają nadawać dostęp. Trzymanie tej logiki w rozsypanych if/else to dług, który kiedyś spłacisz z odsetkami. Wtedy przeniesienie autoryzacji do osobnego serwisu przestaje być fanaberią, a staje się higieną.
Źródła
- OpenFGA — strona projektu — dokumentacja, DSL, API reference
- OpenFGA Docs: Authorization Concepts — ReBAC, ABAC, Zanzibar
- OpenFGA na GitHub — kod źródłowy, issue tracker
- Google Zanzibar Paper — oryginalna praca, która zainspirowała OpenFGA
- Auth0: Understanding ReBAC and ABAC Through OpenFGA and Cedar — porównanie modeli
