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

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 motordur. Auth0 FGA ise farklı bir tutarlılık modeli ile OpenFGA üzerine kurulu, REST-öncelikli, tamamen yönetilen bir hizmettir.

Çoğu takım için varsayılan Auth0 FGA’dır; altyapı bütçeniz yoksa kendi sunucunuzda OpenFGA. Bu varsayılanı SpiceDB’ye çeviren iki gereksinim vardır: bir sonraki okumada hemen geçerli olması gereken izin iptali ve kontrolünüzdeki altyapıdan çıkamayacak yetkilendirme verisi. Şema sözdizimi, API ergonomisi ve yayımlanan ölçek tavanları bu ikisinin yanında daha az belirleyicidir.

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) biçiminde yazılır. “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 şeması: organizasyonlu belge yönetimi
definition 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#

Özellik	SpiceDB	OpenFGA (Auth0 FGA)
Tür tanımlama	definition anahtar sözcüğü	type anahtar sözcüğü
İlişki bildirimi	relation name: type	define name: [type]
İzin hesaplama	permission name = expr	define name: expr
İlişki takibi	-> (ok)	from anahtar sözcüğü
Birleşim	+	or
Kesişim	&	and
Dışlama	-	but not
Koşullar	Caveats (beta)	Conditions
Joker erişim	user:*	user:*
Playground	play.authzed.com	play.fga.dev

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). Bu rakamlar platformun tasarım zarfını tanımlar; kendi kotalarınız ve bölgeleriniz Okta sözleşmenizden gelir.

Mimari Karşılaştırma Tablosu#

Özellik	SpiceDB	Auth0 FGA
Birincil protokol	gRPC	REST (HTTPS)
Kendi sunucunuzda barındırma	Evet (açık kaynak)	Hayır (OpenFGA açık kaynak)
Yönetilen seçenek	Authzed	Auth0/Okta FGA
Depolama	PostgreSQL, CockroachDB, MySQL	Yönetilen (opak)
Çoklu bölge	CockroachDB veya altyapı kurulumu ile	Yerleşik (ABD, AB, AU)
SLA	Altyapınıza bağlıdır	%99,99 (satıcı belgelerinde)
Açık kaynak	SpiceDB (Apache 2.0)	OpenFGA (Apache 2.0)

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 başlat (gRPC)
const client = v1.NewClient(
  "spicedb-preshared-key",
  "localhost:50051",
  v1.ClientSecurity.INSECURE_LOCALHOST_ALLOWED
);

// --- İlişkileri 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 tutarlılık için ZedToken içerir
const zedToken = writeResponse.writtenAt;

// --- İzin kontrolü ---
const checkResult = await client.checkPermission(
  v1.CheckPermissionRequest.create({
    consistency: {
      requirement: {
        oneofKind: "atLeastAsFresh",
        atLeastAsFresh: zedToken, // Bu okumanın yazmayı yansıtmasını sağlar
      },
    },
    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)

// --- Kaynakları ara ---
// bob'un görüntüleyebildiği tüm belgeleri bul
const lookupStream = client.lookupResources(
  v1.LookupResourcesRequest.create({
    consistency: {
      requirement: {
        oneofKind: "atLeastAsFresh",
        atLeastAsFresh: zedToken,
      },
    },
    resourceObjectType: "document",
    permission: "view",
    subject: {
      object: { objectType: "user", objectId: "bob" },
    },
  })
);

// lookupResources eşleşen kaynak ID'lerinin bir stream'ini döndürür
const accessibleDocs: string[] = [];
for await (const response of lookupStream) {
  accessibleDocs.push(response.resourceObjectId);
}
// accessibleDocs "doc-roadmap" içerir (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 başlat (REST)
const fgaClient = new OpenFgaClient({
  apiUrl: process.env.FGA_API_URL!,  // örn. 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'ları yaz ---
await fgaClient.write({
  writes: [
    {
      user: "user:alice",
      relation: "editor",
      object: "document:doc-roadmap",
    },
    {
      user: "user:bob",
      relation: "viewer",
      object: "document:doc-roadmap",
    },
  ],
});

// --- İzin kontrolü ---
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 görüntüleyebildiği tüm belgeleri bul
const { objects } = await fgaClient.listObjects({
  user: "user:bob",
  relation: "view",
  type: "document",
}, {
  consistency: ConsistencyPreference.HigherConsistency,
});
// objects "document:doc-roadmap" içerir (bob bir viewer)

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

İşlem	SpiceDB	Auth0 FGA (OpenFGA)
İlişki yazma	writeRelationships (gRPC)	write (REST)
İzin kontrolü	checkPermission (gRPC)	check (REST)
Erişilebilir kaynakları bulma	lookupResources (streaming gRPC)	listObjects (REST)
Erişimi olan kullanıcıları bulma	lookupSubjects (streaming gRPC)	listUsers (REST)
İlişkileri okuma	readRelationships (streaming gRPC)	read (REST)
İlişkileri silme	writeRelationships DELETE op ile	write deletes dizisi ile
Tutarlılık kontrolü	İstek başına ZedToken	HIGHER_CONSISTENCY bayrağı

Çift Yazma Problemi#

Hem SpiceDB hem de Auth0 FGA harici depolardır. Uygulama verileriniz kendi veritabanınızda durur, yetkilendirme ilişkileri ise yetkilendirme sisteminde tutulur. 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 için tek DB işlemi
async function createDocument(
  db: Database,
  doc: { id: string; title: string; ownerId: string }
): Promise<void> {
  await db.transaction(async (tx) => {
    // Uygulama yazması
    await tx.insert(documents).values({
      id: doc.id,
      title: doc.title,
      ownerId: doc.ownerId,
      createdAt: new Date(),
    });

    // Outbox yazması (aynı işlem, 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'ı okur ve SpiceDB veya Auth0 FGA'ya senkronize eder
async 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,
      });

      // İşlenmiş olarak işaretle
      await db
        .update(authzOutbox)
        .set({ status: "processed", processedAt: new Date() })
        .where(eq(authzOutbox.id, event.id));
    } catch (error) {
      // Başarısız olarak işaretle ve yeniden deneme sayacını artır
      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.

Tutarlılık Modelleri#

Tutarlılık, SpiceDB ve Auth0 FGA’nın en belirgin şekilde farklılaştığı noktadır. Yeni iptal edilmiş bir iznin hâlâ geçerli sayılıp sayılmadığını doğrudan etkiler; Zanzibar makalesi buna “New Enemy Problem” adını verir.

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:

Mod	Davranış	Kullanım Alanı
minimize_latency	Önbelleklenmiş veri kullanır, eski sonuçlar sunabilir	Kısa süreli eskimenin kabul edilebilir olduğu yüksek verimli okumalar
at_least_as_fresh	Okumanın belirli bir ZedToken’ı yansıtmasını garanti eder	Çoğu uygulama için varsayılan; tazelik ve performansı dengeler
fully_consistent	Tüm önbellekleri atlar, doğrudan veri deposundan okur	Eskimenin kabul edilemez olduğu güvenlik açısından kritik işlemler

İ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 başına tutarlılık kontrolü
// UI oluşturma için hızlı kontrol (önbellek 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" } },
  })
);

// Yıkıcı bir işleme izin vermeden önce sıkı kontrol
const 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: tutarlılık bayrağı
const { allowed } = await fgaClient.check({
  user: "user:alice",
  relation: "delete",
  object: "document:doc-123",
}, {
  consistency: ConsistencyPreference.HigherConsistency,
});

Bu ikili bir seçimdir. SpiceDB’nin belirli bir token ile kullanılan 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.

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

Özellik	SpiceDB	Auth0 FGA (OpenFGA)
Token tabanlı tutarlılık	Evet (ZedToken’lar)	Planlanmış (yol haritası)
İstek başına kontrol	Üç mod	İkili (varsayılan veya yüksek)
Önbellek atlama	fully_consistent modu	HIGHER_CONSISTENCY bayrağı
Eski okuma koruması	Token ile at_least_as_fresh	Henüz mevcut değil
Varsayılan davranış	İstek başına yapılandırılabilir	Önbellek + kopyalar

İ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.

Büyük Ölçekte SpiceDB#

SpiceDB’nin en dikkat çekici dağıtımı OpenAI’dadır; ChatGPT Enterprise bağlayıcıları için yetkilendirmeyi yönetir. Bu dağıtım 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: Bağımlı sistemlerde önbellek geçersizleştirme kalıplarını mümkün kılar.

Büyük Ölçekte Auth0 FGA#

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. Pratikte elinize geçeni Okta sözleşmeniz ve SKU’nuz belirler; tasarımınızı dayandıracağınız değerleri önce doğrulayın. Ölçeklemenin kendisi 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ı#

Metrik	SpiceDB	Auth0 FGA
Belgelenen ölçek	Milyarlarca izin (OpenAI)	Satıcının yayımladığı üst sınırlar (ör. 100B ilişki, 1M RPS)
Ölçekleme yaklaşımı	Kendi yönettiğiniz yatay	Tamamen yönetilen
Depolama ölçekleme	CockroachDB (yatay) veya PostgreSQL (dikey)	Yönetilen (opak)
Çoklu bölge	Altyapı kurulumu ile	Yerleşik
SLA	Altyapınıza bağlıdır	Satıcı belgelerinde %99,99

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.

SpiceDB Kendi Sunucusunda: Uygun Senaryolar#

• 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 hâlihazırda işlettiğiniz altyapı üzerinde artımlı bir adımdır.

Auth0 FGA: Uygun Senaryolar#

• 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: SKU’nuz gerçekten kapsıyorsa, yönetilen bir SLA’ya güvenmek aynı hedefi kendi barındırdığınız altyapıda tutturmaktan operasyonel olarak daha kolaydır.
• 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#

Faktör	Kendi Sunucunuzda SpiceDB	Auth0 FGA (Yönetilen)
Altyapı maliyeti	$500-2.000/ay (ölçeğe göre değişir)	Paket veya istek başına fiyat
Operasyon yükü	Orta-Yüksek (K8s + DB)	Düşük (tamamen yönetilen)
Üretime geçiş süresi	Haftalar-aylar	Günler-haftalar
Veri yerleşimi kontrolü	Tam	Mevcut bölgelerle sınırlı
Tutarlılık modeli	Tam Zanzibar (ZedToken’lar)	HIGHER_CONSISTENCY bayrağı
Satıcı bağımlılığı	Düşük (açık kaynak)	Orta (Okta ekosistemi)
Topluluk desteği	Aktif açık kaynak topluluğu	Okta kurumsal destek

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#

Senaryo	Öneri	Neden
Anında izin iptali gerektiren güvenlik açısından kritik sistem	SpiceDB	ZedToken’lar istek başına tutarlılık garantileri sağlar
Auth0 auth ile hızlı benimseme isteyen küçük takım	Auth0 FGA	Yerel Auth0 entegrasyonlu yönetilen hizmet
Veri egemenliği ile çoklu bölge dağıtımı	SpiceDB (kendi sunucunuzda)	Veri yerleşimi ve depolama üzerinde tam kontrol
İşbirlikçi SaaS ürünü geliştiren startup	Auth0 FGA	Daha hızlı üretime geçiş, daha düşük operasyonel yük
Kubernetes altyapısına sahip büyük ölçekli sistem	SpiceDB	Mevcut altyapıya doğal uyum, ölçekte uygun maliyet
Uyumluluk ağırlıklı ortamdaki kuruluş	SpiceDB (kendi sunucunuzda)	Tam denetim kontrolü, özel depolama, üçüncü taraf veri erişimi yok
Minimum taahhütle ReBAC keşfeden takım	OpenFGA (kendi sunucunuzda)	Ücretsiz, açık kaynak, sonra Auth0 FGA’ya geçiş yapılabilir

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ç#

İzin kontrolleriniz kısa süreli eskimeyi kaldırabiliyorsa ve yetkilendirme veriniz satıcının bölgelerinde durabiliyorsa varsayılan Auth0 FGA olarak kalır. İptal edilen bir iznin bir sonraki okumada görünmemesi gerekiyorsa ya da veri yerleşimi ve depolama backend’i sizin kontrolünüzde kalmak zorundaysa SpiceDB’ye geçin. Bu geçişin bedeli, takımınızın işleteceği bir Kubernetes ve veritabanı ayak izidir.

Çift yazma problemi her ikisi için de aynı şekilde geçerlidir. 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.

Karar vermeden önce en karmaşık yetkilendirme senaryonuzu her iki playground’da modelleyin (play.authzed.com ve play.fga.dev). Şema modellemesi bir öğleden sonranızı alır ve karşılaştırma tablolarının düzleştirdiği farkları ortaya çıkarır.

Kaynaklar#

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