SpiceDB vs Auth0 FGA: İlişki Tabanlı Yetkilendirme Karşılaştırması

Abstract#

SpiceDB ve Auth0 FGA, Zanzibar tabanlı iki önde gelen yetkilendirme sistemidir. Ancak temelde farklı tercihler yaparlar. SpiceDB, ZedToken'lar aracılığıyla güçlü tutarlılık garantileri sunan gRPC-öncelikli, kendi sunucunuzda barındırılabilen (veya Authzed üzerinden yönetilen) bir motorudur. Auth0 FGA ise farklı bir tutarlılık modeli ile OpenFGA üzerine kurulu, REST-öncelikli, tamamen yönetilen bir hizmettir. Bu yazı, her iki sistemin şema dillerini, mimarisini, tutarlılık modellerini ve entegrasyon kalıplarını yan yana karşılaştırır. Her iki sistem için de çalışan TypeScript örnekleri sunarak doğru seçimi yapmanıza yardımcı olmayı amaçlar.

Note: Bu yazı, Harici Yetkilendirme Sistemleri serisinin 3. bölümüdür. 1. bölüm platform genel değerlendirmesini, 2. bölüm ise SaaS için AWS Cognito + Verified Permissions konusunu kapsar.

Google Zanzibar Mirası#

Hem SpiceDB hem de Auth0 FGA, tasarımlarını aynı kaynaktan alır: Google'ın USENIX ATC 2019'da yayınlanan Zanzibar makalesi. Zanzibar, Google'ın Drive, Calendar, Cloud, Maps, Photos ve YouTube için yetkilendirme kararlarını yöneten dahili sistemidir. Trilyonlarca erişim kontrol listesini ve saniyede milyonlarca yetkilendirme isteğini 95. yüzdelik dilimde 10 milisaniyenin altında gecikme ile işler.

Zanzibar makalesi, her iki sistemin de uyguladığı birkaç kavramı tanıttı:

• İlişki tuple'ları: Yetkilendirme verisinin atomik birimi -- (kullanıcı, ilişki, nesne). "Kullanıcı X, Belge Y'nin editörüdür" bir tuple olur.
• Namespace yapılandırması: Hangi nesne türlerinin var olduğunu ve hangi ilişkilere sahip olabileceklerini tanımlayan bir şema.
• İlişki yeniden yazımı: İlişkileri takip ederek ve birleştirerek izinleri hesaplama. "Görüntüleyebilir" demek "görüntüleyici VEYA editör VEYA sahip" anlamına gelebilir.
• Tutarlılık token'ları: İzin kontrollerinin son yazmaları yansıtmasını sağlayan mekanizmalar (Zanzibar bunlara "zookie" der).

SpiceDB ve Auth0 FGA'nın ayrıştığı nokta, bu kavramları ne kadar sadakatle uyguladıkları ve tutarlılık, dağıtım ve API tasarımı konusunda hangi tercihleri yaptıklarıdır.

SpiceDB, at_least_as_fresh ve fully_consistent semantikleri dahil olmak üzere tam Zanzibar tutarlılık modelini uygular. Auth0 FGA (OpenFGA üzerinden) daha rahat bir yaklaşım benimser ve varsayılan token tabanlı tutarlılık yerine HIGHER_CONSISTENCY bayrağını isteğe bağlı olarak sunar.

Şema Karşılaştırması#

Şema, yetkilendirme mantığınızı tanımladığınız yerdir. Her iki sistem de türleri, ilişkileri ve izinleri tanımlamak için bildirimsel bir dil kullanır, ancak sözdizimi ve yetenekleri farklıdır.

SpiceDB Şema Dili#

SpiceDB, definition blokları, relation bildirimleri ve permission hesaplamaları ile kendi şema dilini kullanır. İlişkiler hangi tür öznelerin atanabileceğini tanımlar. İzinler, küme işlemleri ile ilişkileri birleştirerek hesaplanan erişimi tanımlar.

// SpiceDB semasi: organizasyonlu belge yonetimidefinition user {}
definition organization {    relation admin: user    relation member: user
    permission manage = admin}
definition folder {    relation org: organization    relation viewer: user | organization#member    relation editor: user | organization#admin
    permission view = viewer + editor    permission edit = editor}
definition document {    relation parent_folder: folder    relation owner: user    relation editor: user    relation viewer: user
    permission view = viewer + editor + owner + parent_folder->view    permission edit = editor + owner + parent_folder->edit    permission delete = owner}

SpiceDB şemasının temel özellikleri:

• Ok operatörü (->): Nesneler arasındaki ilişkileri takip eder. parent_folder->view, "üst klasörü görüntüleyebilen herkes bu belgeyi de görüntüleyebilir" anlamına gelir.
• Birleşim (+): Birden fazla ilişkiyi birleştirir. viewer + editor + owner, bu ilişkilerden herhangi birinin izni verdiği anlamına gelir.
• Kesişim (&) ve Dışlama (-): İzin hesaplamasında VE ve DEĞİL mantığı desteği.
• Özne ilişkileri (organization#member): Öznelere yalnızca kimlikleri üzerinden değil, ilişkileri üzerinden referans verir.

OpenFGA DSL (Auth0 FGA)#

Auth0 FGA, farklı bir sözdizimi olan ancak benzer kavramları modelleyen OpenFGA DSL'ini kullanır. Türler tanımların yerini alır ve define anahtar sözcüğü hem ilişkileri hem de izinleri bildirir.

model  schema 1.1
type user
type organization  relations    define admin: [user]    define member: [user]    define manage: admin
type folder  relations    define org: [organization]    define viewer: [user, organization#member]    define editor: [user, organization#admin]    define view: viewer or editor    define edit: editor
type document  relations    define parent_folder: [folder]    define owner: [user]    define editor: [user]    define viewer: [user]    define view: viewer or editor or owner or view from parent_folder    define edit: editor or owner or edit from parent_folder    define delete: owner

OpenFGA DSL'nin temel özellikleri:

• from anahtar sözcüğü: SpiceDB'nin ok operatörünün karşılığıdır. view from parent_folder, parent_folder ilişkisini takip eder ve view iznini kontrol eder.
• or / and / but not: Küme işlemleri semboller yerine anahtar sözcüklerle ifade edilir.
• Parantez içinde tür kısıtlamaları: [user, organization#member] bir ilişkide hangi özne türlerinin izinli olduğunu belirtir.
• Ayrı permission anahtar sözcüğü yok: İlişkiler ve izinler aynı define sözdizimini kullanır. Ayrım örtüktür -- [type] referans veren ilişkiler atanabilir; diğer ilişkilere referans verenler hesaplanır.

Şema Karşılaştırma Tablosu#

Her iki şema da aynı yetkilendirme mantığını modeller. Aralarındaki seçim büyük ölçüde sözdizimi tercihi ve her birinin bağlı olduğu ekosisteme bağlıdır.

Mimari Farklılıklar#

SpiceDB ve Auth0 FGA arasındaki mimari farklılıklar, farklı tasarım felsefelerini yansıtır: kendi sunucunuzda barındırma esnekliği ile yönetilen hizmet basitliği.

SpiceDB#

• Protokol: gRPC-öncelikli, isteğe bağlı HTTP/REST gateway ile. gRPC birincil entegrasyon yoludur ve daha iyi performans özellikleri sunar (HTTP/2, ikili protokol, streaming).
• Dağıtım: Kubernetes, Docker veya bare metal üzerinde kendi sunucunuzda barındırma. Authzed, altyapı yönetmek istemeyen takımlar için yönetilen bir hizmet sunar.
• Depolama backend'leri: PostgreSQL, CockroachDB, MySQL veya Memdb (test için bellek içi). CockroachDB, güçlü tutarlılık ile yatay ölçeklenebilir dağıtımları mümkün kılar.
• Ölçekleme: Paylaşılan bir veri deposu tarafından desteklenen birden fazla SpiceDB örneği ile yatay ölçekleme. Önbellek katmanları, okuma ağırlıklı iş yükleri için veri deposu yükünü azaltır.

Auth0 FGA#

• Protokol: REST-öncelikli (HTTPS). SDK'lar REST çağrılarını soyutlar, ancak alttaki API HTTP/JSON'dur.
• Dağıtım: Tamamen yönetilen SaaS. Auth0 FGA için kendi sunucunuzda barındırma seçeneği yoktur, ancak ihtiyaç halinde OpenFGA'yı (açık kaynak motor) kendi sunucunuzda barındırabilirsiniz.
• Depolama: Okta tarafından yönetilir. ABD, AB ve Avustralya'da çoklu bölge dağıtımı. AWS üzerinde özel bulut dağıtımı mevcuttur.
• Ölçekleme: Platform tarafından yönetilen ölçekleme. Okta, üst sınır düzeyinde rakamlar yayımlar (örneğin yaklaşık 100 milyar ilişki ve saniyede 1 milyon istek). Bunları her kiracı, bölge veya fiyat katmanı için garanti değil; satıcı dokümantasyonu ve pazarlama bağlamında değerlendirin. Kota, plan ve SLA şartlarını sözleşmenizde doğrulayın.

Mimari Karşılaştırma Tablosu#

Kod Örnekleri#

Aşağıdaki örnekler her iki sistemde de aynı senaryoyu uygular: kullanıcıların sahip, editör veya görüntüleyici olarak atanabildiği ve izinlerin klasör hiyerarşileri aracılığıyla aktığı bir belge yönetimi uygulaması.

SpiceDB ile TypeScript#

SpiceDB, gRPC üzerinden iletişim kuran @authzed/authzed-node istemci kütüphanesini kullanır.

import { v1 } from "@authzed/authzed-node";
// SpiceDB istemcisini baslat (gRPC)const client = v1.NewClient(  "spicedb-preshared-key",  "localhost:50051",  v1.ClientSecurity.INSECURE_LOCALHOST_ALLOWED);
// --- Iliskileri yaz ---const writeResponse = await client.writeRelationships(  v1.WriteRelationshipsRequest.create({    updates: [      {        operation: v1.RelationshipUpdate_Operation.TOUCH,        relationship: {          resource: { objectType: "document", objectId: "doc-roadmap" },          relation: "editor",          subject: {            object: { objectType: "user", objectId: "alice" },          },        },      },      {        operation: v1.RelationshipUpdate_Operation.TOUCH,        relationship: {          resource: { objectType: "document", objectId: "doc-roadmap" },          relation: "viewer",          subject: {            object: { objectType: "user", objectId: "bob" },          },        },      },    ],  }));
// writeResponse.writtenAt tutarlilik icin ZedToken icerirconst zedToken = writeResponse.writtenAt;
// --- Izin kontrolu ---const checkResult = await client.checkPermission(  v1.CheckPermissionRequest.create({    consistency: {      requirement: {        oneofKind: "atLeastAsFresh",        atLeastAsFresh: zedToken, // Bu okumanin yazmayi yansitmasini sagla      },    },    resource: { objectType: "document", objectId: "doc-roadmap" },    permission: "edit",    subject: {      object: { objectType: "user", objectId: "alice" },    },  }));
const canEdit =  checkResult.permissionship ===  v1.CheckPermissionResponse_Permissionship.HAS_PERMISSION;// canEdit === true (alice bir editor)
// --- Kaynaklari ara ---// bob'un goruntuleyebildigi tum belgeleri bulconst lookupStream = client.lookupResources(  v1.LookupResourcesRequest.create({    consistency: {      requirement: {        oneofKind: "atLeastAsFresh",        atLeastAsFresh: zedToken,      },    },    resourceObjectType: "document",    permission: "view",    subject: {      object: { objectType: "user", objectId: "bob" },    },  }));
// lookupResources eslesen kaynak ID'lerinin bir stream'ini dondururconst accessibleDocs: string[] = [];for await (const response of lookupStream) {  accessibleDocs.push(response.resourceObjectId);}// accessibleDocs "doc-roadmap" icerir (bob bir viewer)

Auth0 FGA ile TypeScript#

Auth0 FGA, REST üzerinden iletişim kuran @openfga/sdk istemci kütüphanesini kullanır.

import { OpenFgaClient, ConsistencyPreference } from "@openfga/sdk";
// OpenFGA istemcisini baslat (REST)const fgaClient = new OpenFgaClient({  apiUrl: process.env.FGA_API_URL!,       // orn., https://api.us1.fga.dev  storeId: process.env.FGA_STORE_ID!,  authorizationModelId: process.env.FGA_MODEL_ID!,  credentials: {    method: "client_credentials",    config: {      clientId: process.env.FGA_CLIENT_ID!,      clientSecret: process.env.FGA_CLIENT_SECRET!,      apiTokenIssuer: "fga.us.auth0.com",      apiAudience: "https://api.us1.fga.dev/",    },  },});
// --- Tuple'lari yaz ---await fgaClient.write({  writes: [    {      user: "user:alice",      relation: "editor",      object: "document:doc-roadmap",    },    {      user: "user:bob",      relation: "viewer",      object: "document:doc-roadmap",    },  ],});
// --- Izin kontrolu ---const { allowed } = await fgaClient.check({  user: "user:alice",  relation: "edit",  object: "document:doc-roadmap",}, {  consistency: ConsistencyPreference.HigherConsistency,});// allowed === true (alice bir editor, edit = editor or owner)
// --- Nesneleri listele ---// bob'un goruntuleyebildigi tum belgeleri bulconst { objects } = await fgaClient.listObjects({  user: "user:bob",  relation: "view",  type: "document",}, {  consistency: ConsistencyPreference.HigherConsistency,});// objects "document:doc-roadmap" icerir (bob bir viewer)

Yan Yana API Karşılaştırması#

Çift Yazma Problemi#

Hem SpiceDB hem de Auth0 FGA harici depolardır. Uygulama verileriniz veritabanınızda yaşar. Yetkilendirme ilişkileri yetkilendirme sisteminde yaşar. Bu ikisini senkronize tutmak çift yazma problemidir ve ilişki tabanlı yetkilendirmenin en çok hafife alınan operasyonel zorluğudur.

Problem#

Bir belgeyi sahibiyle birlikte oluşturmayı düşünün:

1. Uygulama belge kaydını PostgreSQL'e yazar
2. Uygulama user:alice, document:doc-123'ün sahibidir ilişkisini SpiceDB'ye (veya Auth0 FGA'ya) yazar
3. 2. adım başarısız olursa, belge mevcut olur ancak yetkilendirme verisi olmaz

Tersi de eşit derecede tehlikelidir: 1. adım başarısız olur ancak 2. adım başarılı olursa, yetkilendirme sistemi var olmayan bir belgeye referans verir.

Veritabanınız ile yetkilendirme sistemi arasında dağıtık işlem yoktur. Bunu ele almak için bir kalıba ihtiyacınız var.

Transactional Outbox Kalıbı#

En güvenilir çözüm transactional outbox kalıbıdır. Hem uygulama verisini hem de yetkilendirme olayını tek bir işlemde aynı veritabanına yazın. Ayrı bir worker süreci daha sonra outbox'ı okur ve yetkilendirme deposuna senkronize eder.

// Transactional outbox: her iki yazma icin tek DB islemiasync function createDocument(  db: Database,  doc: { id: string; title: string; ownerId: string }): Promise<void> {  await db.transaction(async (tx) => {    // Uygulama yazmasi    await tx.insert(documents).values({      id: doc.id,      title: doc.title,      ownerId: doc.ownerId,      createdAt: new Date(),    });
    // Outbox yazmasi (ayni islem -- atomik)    await tx.insert(authzOutbox).values({      eventType: "relationship_created",      payload: JSON.stringify({        resource: { type: "document", id: doc.id },        relation: "owner",        subject: { type: "user", id: doc.ownerId },      }),      status: "pending",      createdAt: new Date(),    });  });}
// Asenkron worker: outbox'i okur ve SpiceDB veya Auth0 FGA'ya senkronize ederasync function processOutbox(  db: Database,  authzClient: AuthZClient): Promise<void> {  const pending = await db    .select()    .from(authzOutbox)    .where(eq(authzOutbox.status, "pending"))    .orderBy(authzOutbox.createdAt)    .limit(100);
  for (const event of pending) {    try {      const payload = JSON.parse(event.payload);
      // SpiceDB veya Auth0 FGA'ya yaz      await authzClient.writeRelationship({        resource: payload.resource,        relation: payload.relation,        subject: payload.subject,      });
      // Islenmis olarak isaretle      await db        .update(authzOutbox)        .set({ status: "processed", processedAt: new Date() })        .where(eq(authzOutbox.id, event.id));    } catch (error) {      // Basarisiz olarak isaretle ve yeniden deneme mantigi      await db        .update(authzOutbox)        .set({          status: "failed",          retryCount: event.retryCount + 1,          lastError: error.message,        })        .where(eq(authzOutbox.id, event.id));    }  }}

Alternatif Yaklaşımlar#

Change Data Capture (CDC): Debezium veya benzer bir araç kullanarak veritabanı değişikliklerini yakalayın ve yetkilendirme deposuna iletin. Kurulumu daha karmaşıktır ancak uygulamayı senkronizasyon mekanizmasından tamamen ayırır.

Uzlaştırma işleri: Kısa süreli tutarsızlığı kabul edin ve uygulama durumunu yetkilendirme durumuyla karşılaştıran periyodik işler çalıştırarak sapmaları düzeltin. Bu en basit yaklaşımdır ancak izinlerin yanlış olabileceği bir pencere açar.

Warning: Senkronizasyon için anlamlı mühendislik zamanı ayırın. Çift yazma problemi, harici yetkilendirme sistemlerini benimsemenin en çok hafife alınan maliyetidir. AuthZed, Google Zanzibar ve SpiceDB deneyimlerine dayanan bu konu hakkında detaylı rehber yayınlamıştır.

Tutarlılık Modelleri#

Tutarlılık, SpiceDB ve Auth0 FGA'nın en belirgin şekilde farklılaştığı noktadır. Son iptal edilen bir iznin hala geçerli olup olmadığını doğrudan etkiler -- Zanzibar makalesindeki "New Enemy Problemi".

ZedToken'lar (SpiceDB)#

SpiceDB, ZedToken'lar aracılığıyla (Zanzibar'ın "zookie" kavramının karşılığı) tam Zanzibar tutarlılık modelini uygular. Her yazma işlemi bir ZedToken döndürür. Bu token'ı sonraki okumalarda geçirmek, okumanın en az o yazmayı yansıtmasını garanti eder.

SpiceDB, istek başına üç tutarlılık modu sunar:

İstek başına tutarlılık modeli önemli bir avantajdır. UI elemanlarını oluşturmak için minimize_latency (kısa süreli eskimenin sorun olmadığı durumlar) ve yazma işlemleri veya hassas erişim kontrolleri için fully_consistent kullanabilirsiniz.

// SpiceDB: istek basina tutarlilik kontrolu// UI olusturma icin hizli kontrol (onbellek kullanabilir)const uiCheck = await client.checkPermission(  v1.CheckPermissionRequest.create({    consistency: {      requirement: { oneofKind: "minimizeLatency", minimizeLatency: true },    },    resource: { objectType: "document", objectId: "doc-123" },    permission: "view",    subject: { object: { objectType: "user", objectId: "alice" } },  }));
// Yikici bir isleme izin vermeden once siki kontrolconst deleteCheck = await client.checkPermission(  v1.CheckPermissionRequest.create({    consistency: {      requirement: { oneofKind: "fullyConsistent", fullyConsistent: true },    },    resource: { objectType: "document", objectId: "doc-123" },    permission: "delete",    subject: { object: { objectType: "user", objectId: "alice" } },  }));

Auth0 FGA'da Tutarlılık (OpenFGA)#

OpenFGA (v1.5.7'den itibaren) sorgu API'lerinde HIGHER_CONSISTENCY bayrağı sunar. Ayarlandığında, OpenFGA okuma önbelleğini atlar ve sorguları okuma kopyaları yerine birincil veritabanına yönlendirir.

// Auth0 FGA: tutarlilik bayragiconst { allowed } = await fgaClient.check({  user: "user:alice",  relation: "delete",  object: "document:doc-123",}, {  consistency: ConsistencyPreference.HigherConsistency,});

Bu, SpiceDB'nin üç katmanlı modeli yerine ikili bir seçimdir. SpiceDB'nin belirli bir token ile at_least_as_fresh karşılığı yoktur -- ya varsayılan tutarlılık (önbellekleme ve kopyalar nedeniyle potansiyel olarak eski) ya da daha yüksek tutarlılık (doğrudan birincil okuma) alırsınız.

Tip: OpenFGA'nın yol haritasında tam tutarlılık token desteği (ZedToken'lara benzer) bulunmaktadır. Yazma işlemleri, sonraki okumalara geçirilebilecek bir token döndürür. OpenFGA v1.8 itibarıyla bu özellik hala geliştirme aşamasındadır.

Tutarlılık Karşılaştırması#

İzin iptalinin derhal uygulanması gereken uygulamalar için (güvenlik açısından hassas sistemler, finansal uygulamalar), SpiceDB'nin tutarlılık modeli bugün daha güçlü garantiler sağlar. Kısa süreli eskimenin kabul edilebilir olduğu uygulamalar için (içerik platformları, işbirliği araçları), Auth0 FGA'nın daha basit modeli yeterli olabilir.

Ölçeklenebilirlik#

Her iki sistem de önemli ölçekte doğrulanmıştır, ancak ölçekleme hikayeleri farklıdır.

SpiceDB Ölçekte#

SpiceDB'nin en dikkat çekici dağıtımı OpenAI'dadır. ChatGPT Enterprise bağlayıcıları için yetkilendirmeyi yönetir. Bu, on milyarlarca ince taneli izni işler. AuthZed (SpiceDB'nin arkasındaki şirket), sistemi karmaşık ilişki grafikleri ile yüksek frekanslı izin kontrollerinin gerçekleştiği yapay zeka ajanı yetkilendirme senaryoları için konumlandırmaktadır.

SpiceDB'yi ölçeklendirmek şunları içerir:

• Yatay ölçekleme: Bir yük dengeleyicinin arkasına daha fazla SpiceDB örneği ekleyin. Tüm örnekler aynı veri deposunu paylaşır.
• Depolama backend seçimi: Yatay ölçeklenebilir, güçlü tutarlılık için CockroachDB. Dikey ölçekleme ile daha basit dağıtımlar için PostgreSQL. Alternatif ilişkisel backend olarak MySQL.
• Önbellekleme: SpiceDB sık erişilen ilişkileri önbelleğe alır. minimize_latency tutarlılık modu önbellek kullanımını maksimize eder.
• Watch API: Aşağı akış tüketicileri için önbellek geçersiz kılma kalıplarını etkinleştirir.

Auth0 FGA Ölçekte#

Auth0 FGA (Okta FGA), ürün materyallerinde ilişki sayısı, saniye başına istek ve kullanılabilirlik hedefi gibi yüksek ölçek rakamları yayımlar. Bu sayılar platform tasarım zarfını tanımlar; her müşteri için otomatik taahhüt değildir. SLA, bölgeler ve kotlar Okta sözleşmenize ve SKU'nıza bağlıdır -- güvendiğiniz değerleri yazılı olarak doğrulayın. Ölçekleme tamamen platform tarafından yönetilir -- altyapı yönetmezsiniz.

Temel ölçekleme özellikleri:

• Çoklu bölge: ABD, AB ve Avustralya bölgelerinde otomatik dağıtım.
• Özel bulut: Veri yerleşimi gereksinimleri olan kuruluşlar için AWS'de mevcuttur.
• Yönetilen ölçekleme: Okta kapasite planlaması, yük devretme ve performans optimizasyonunu yönetir.
• OpenFGA kendi sunucunuzda: Yönetilen hizmeti aşarsanız veya özel dağıtıma ihtiyacınız varsa, OpenFGA PostgreSQL veya MySQL ile kendi sunucunuzda barındırılabilir.

Ölçek Karşılaştırması#

Kendi Sunucunuzda Barındırma vs Yönetilen Hizmet Tercihleri#

SpiceDB'yi kendi sunucunuzda barındırmak ile Auth0 FGA'yı yönetilen hizmet olarak kullanmak arasındaki karar teknik tercihten öteye geçer. Operasyon yükü, uyumluluk, maliyet ve organizasyonel kapasite ile ilgilidir.

Kendi Sunucunuzda SpiceDB Ne Zaman Mantıklıdır#

• Veri egemenliği: Yetkilendirme verileri belirli coğrafi veya ağ sınırları içinde kalmalıdır. Kendi sunucunuzda barındırma, veri yerleşimi üzerinde tam kontrol sağlar.
• Özel depolama gereksinimleri: Belirli bir veritabanı backend'ine (örneğin çoklu bölge tutarlılığı için CockroachDB) veya özel yedekleme/kurtarma prosedürlerine ihtiyacınız var.
• Ölçekte maliyet optimizasyonu: Çok yüksek yetkilendirme hacimlerinde, kendi sunucunuzda barındırma istek başına fiyatlandırmadan daha uygun maliyetli olabilir. Bir üretim SpiceDB kümesi için altyapı maliyeti ölçeğe bağlı olarak genellikle aylık $500-2.000 arasında değişir.
• Derin entegrasyon ihtiyaçları: gRPC API'sine, değişikliklerin akışı için Watch API'sine veya özel önbellekleme katmanlarına doğrudan erişim.
• Mevcut Kubernetes uzmanlığı: Takımınız zaten Kubernetes kümeleri işletiyorsa, SpiceDB eklemek yeni bir operasyonel alan yerine artımlıdır.

Auth0 FGA Ne Zaman Mantıklıdır#

• Minimum operasyonel yük: Yönetilecek altyapı yok, ayarlanacak veritabanı yok, alınacak ölçekleme kararı yok.
• Auth0/Okta ekosistemi: Kimlik doğrulama için zaten Auth0 kullanıyorsanız, FGA mevcut kimlik altyapınızla doğal olarak entegre olur.
• Hızlı benimseme: Birden fazla dilde resmi SDK'larla REST API'leri. Kendi sunucunuzdaki SpiceDB'ye kıyasla daha kısa üretime geçiş süresi.
• SLA gereksinimleri: Yönetilen SLA (SKU'nuz için geçerliyse), aynı hedefi kendi barındırdığınız altyapıda karşılamaktan operasyonel olarak daha kolay olabilir -- yine de kapsamı sözleşmenizde doğrulayın.
• Takım büyüklüğü kısıtlamaları: Yetkilendirme altyapısına mühendislik kapasitesi ayıramayan küçük takımlar yönetilen hizmetten fayda görür.

Tercih Matrisi#

Karar Matrisi#

Aşağıdaki akış şeması, özel gereksinimlerinize göre SpiceDB ve Auth0 FGA kararınızda yol gösterir.

Hızlı Karar Rehberi#

Yapılmaması Gerekenler#

• Takımınızda Kubernetes ve veritabanı operasyonları uzmanlığı yoksa sadece açık kaynak olduğu için SpiceDB'yi seçmeyin. Operasyonel yük faydaları aşabilir.
• Tutarlılık token'larının ZedToken'lar gibi çalıştığını varsayarak Auth0 FGA'yı seçmeyin. Tutarlılık modelleri anlamlı ölçüde farklıdır. at_least_as_fresh semantiklerine ihtiyacınız varsa, Auth0 FGA'nın mevcut tutarlılık modelini gereksinimlerinizle test edin.
• Çift yazma problemi analizini atlamayın. Her iki sistem de bir senkronizasyon stratejisi gerektirir. Yetkilendirme verilerini uygulama verileriyle senkronize tutma planı olmadan platform seçmek üretim sorunlarına yol açar.
• Orta yol olarak OpenFGA'yı göz ardı etmeyin. OpenFGA'yı kendi sunucunuzda barındırmak, kendi sunucunuz kontrolü ile Auth0 FGA şema dilini sağlar. Daha sonra yönetilen altyapıya ihtiyaç duyarsanız, alttaki model aynı olduğu için Auth0 FGA'ya geçiş basittir.

Sonuç#

SpiceDB ve Auth0 FGA, olgunlaşmış ve üretimde doğrulanmış Zanzibar uygulamalarıdır. Aynı temel sorunu çözerler -- ölçekte ilişki tabanlı yetkilendirme -- ancak farklı tercihlerle.

SpiceDB, ZedToken'lar aracılığıyla daha güçlü tutarlılık garantileri, gRPC-öncelikli performans ve tam altyapı kontrolü sağlar. Daha fazla operasyonel yatırım gerektirir ancak ince taneli tutarlılık kontrolü ve veri egemenliği gerektiren takımları ödüllendirir.

Auth0 FGA, güçlü ölçeklenebilirlik garantileri ve yerel Auth0 entegrasyonu ile yönetilen, REST-öncelikli bir deneyim sağlar. Tutarlılık ayrıntısını operasyonel basitlik ve daha hızlı üretime geçiş için takas eder.

Çift yazma problemi her ikisine de eşit olarak uygulanır. Hangi sistemi seçerseniz seçin, yetkilendirme verilerinin uygulama verileriyle nasıl senkronize kalacağını planlayın. Transactional outbox kalıbı çoğu mimari için en güvenilir yaklaşımdır.

En karmaşık yetkilendirme senaryonuzla bir kavram kanıtı çalıştırın. Şemanızı her iki sistemde modelleyin (play.authzed.com ve play.fga.dev kullanın), uygulama kodunuzla entegre edin ve tutarlılık modelini güvenlik gereksinimlerinize göre değerlendirin. Her iki sistemin belirli kullanım durumunuzu nasıl ele aldığını gördüğünüzde doğru seçim netleşir.

Kaynaklar#

• Zanzibar: Google's Consistent, Global Authorization System (USENIX ATC 2019) - Hem SpiceDB hem de OpenFGA'ya ilham veren orijinal Google Zanzibar makalesi
• AuthZed SpiceDB GitHub Repository - Açık kaynak Google Zanzibar tabanlı yetkilendirme sistemi
• SpiceDB Consistency Documentation - ZedToken'lar ve tutarlılık modları hakkında resmi dokümantasyon
• SpiceDB Schema Language Reference - Şema tanımlama sözdizimi ve yetenekleri
• authzed-node GitHub Repository - Node.js/TypeScript için resmi SpiceDB istemci kütüphanesi
• OpenFGA Documentation - OpenFGA yetkilendirme modelinin temel kavramları
• OpenFGA Query Consistency Modes - HIGHER_CONSISTENCY ve sorgu tutarlılık seçenekleri dokümantasyonu
• Auth0 Fine-Grained Authorization (FGA) Documentation - Resmi Auth0 FGA dokümantasyonu ve entegrasyon rehberleri
• Okta Fine Grained Authorization Product Page - Auth0/Okta FGA ürün genel bakışı ve ölçeklenebilirlik dokümantasyonu
• AuthZed - The Dual-Write Problem in SpiceDB - Harici ilişki depolarıyla senkronizasyon zorluklarına derin bakış
• OpenFGA Consistency Tokens Roadmap Issue - Zanzibar tarzı tutarlılık token'ları için OpenFGA yol haritası
• Permit.io - Policy Engine Showdown: OPA vs OpenFGA vs Cedar - Sözdizimi örnekleriyle kapsamlı politika motoru karşılaştırması