Bu sayfa ErtisAuth'un yapı taşlarını ve birbirleriyle ilişkilerini tanıtır. Her kavramın tüm ayrıntılarını içeren kendi referans sayfası vardır.

genel bakış

Kurulum
└── Membership (kiracı)
    ├── Users ──────────── bir rolü, bir kullanıcı tipi ve isteğe bağlı kendi yetkileri vardır
    ├── User Types ─────── kullanıcı verisinin şeması, kalıtımla
    ├── Roles ──────────── isimlendirilmiş yetki kümeleri
    ├── Applications ───── makine istemcileri; bir rolü ve isteğe bağlı kendi yetkileri vardır
    ├── Providers ──────── Google, Apple, Facebook, Microsoft ile giriş
    ├── Code Policies ──── cihazla giriş kodlarının biçimi
    ├── Events ─────────── olup bitenlerin kaydı
    ├── Webhooks ───────── olayların tetiklediği HTTP çağrıları
    └── Mail Hooks ─────── olayların tetiklediği e-postalar

Membership#

Membership, Keycloak'taki realm gibi izole bir kiracıdır. Diğer her şey tam olarak bir membership'e aittir ve bir membership'te üretilen token başka bir membership'in kaynaklarına erişemez.

Membership ayrıca kullanıcılarının kimlik doğrulamasına ait ayarları da tutar:

access, refresh, scoped ve sıfırlama token'larının süreleri,
token'ların imzalandığı gizli anahtar (secret key),
şifre hash algoritması ve metin kodlaması,
mail sağlayıcıları, aktivasyon politikası, OTP ayarları ve cihaz kodu politikası.

Tek bir kurulum, örneğin her ürün ya da her müşteri için bir tane olmak üzere çok sayıda membership barındırabilir. Bkz. Membership'ler.

Kullanıcı#

Kullanıcı, giriş yapan bir kişidir. Her kullanıcının şunları vardır:

membership içinde benzersiz olan bir username ve bir email_address (ikisi de giriş için kullanılabilir),
yetkilerinin çoğunu veren bir role,
kullanıcının başka hangi alanlara sahip olduğunu belirleyen bir user_type,
isteğe bağlı, kendine ait permissions ve forbidden listeleri (UBAC),
bir is_active bayrağı: aktif olmayan kullanıcılar giriş yapamaz.

Bkz. Kullanıcılar.

Kullanıcı tipi#

Kullanıcı tipi, bir kullanıcı türünün şemasıdır; örneğin Müşteri ya da Çalışan. Özel alanları (bir telefon numarası, bir doğum tarihi, bir adres listesi…) tipleri ve doğrulama kurallarıyla birlikte tanımlar. Kullanıcı tipleri birbirinden türeyebilir; hepsi en sonunda standart alanları (firstname, lastname, username, email_address, role…) tanımlayan yerleşik base-user tipinden türer.

Bkz. Kullanıcı Tipleri.

Rol#

Rol, birçok kullanıcı ve uygulamanın paylaştığı, isimlendirilmiş bir yetki (permissions) ve yasak (forbidden) kümesidir. Setup, her şeyi yapabilen ayrılmış admin rolünü oluşturur.

Bkz. Roller ve Yetkilendirme.

Uygulama#

Uygulama bir makine istemcisidir: bir backend servisi, zamanlanmış bir iş, sunucu tarafında çalışan bir web uygulaması. Id'si ve bir secret'tan oluşan bir Basic token ile kimliğini doğrular; bir kullanıcı gibi bir rolü ve isteğe bağlı kendi yetkileri vardır.

Bkz. Uygulamalar.

Utilizer#

Utilizer, ErtisAuth'ta isteği yapan için kullanılan terimdir: bir kullanıcı (Bearer token ile) ya da bir uygulama (Basic token ile). Olaylar onlara sebep olan utilizer'ı kaydeder ve yetkiler utilizer için değerlendirilir.

Token'lar#

Token	Kim	Biçim	Ne için
Access token	kullanıcılar	JWT, `Authorization: Bearer …`	API'yi çağırmak
Refresh token	kullanıcılar	JWT	yeni bir access token almak
Scoped token	kullanıcılar	JWT, `Authorization: Bearer …`	bazı yetkilerle sınırlandırılmış bir access token
Basic token	uygulamalar	`Authorization: Basic <id>:<secret>`	API'yi çağırmak
Sıfırlama token'ı (reset token)	kullanıcılar	opak bir dize	yeni bir şifre belirlemek
Aktivasyon token'ı	kullanıcılar	opak bir dize	bir hesabı aktifleştirmek

Bkz. Kimlik Doğrulama.

Sağlayıcı#

Sağlayıcı (provider), harici bir kimlik sağlayıcıyı (Google, Apple, Facebook, Microsoft) bir membership'e bağlar. Onunla giriş yapan kullanıcılar ilk girişlerinde oluşturulur ya da mevcut bir hesaba bağlanır.

Bkz. Harici Kimlik Sağlayıcılar.

Olaylar, webhook'lar ve mail hook'lar#

İşlemlerin çoğu bir olay (event) kaydeder: bir kullanıcı oluşturuldu, bir token üretildi, bir rol güncellendi… Olaylar API üzerinden okunabilir ve şunları tetikler:

seçtiğiniz bir URL'ye HTTP isteği gönderen webhook'lar,
şablonlu bir e-posta gönderen mail hook'lar.

Bkz. Olaylar, Webhook'lar ve Mail Hook'lar.

Kimlikler ve slug'lar#

Her kaynağın bir _id'si vardır (MongoDB ObjectId dizesi).
Membership'ler, roller, uygulamalar, kullanıcı tipleri, sağlayıcılar, webhook'lar, mail hook'lar ve kod politikalarının ayrıca bir slug'ı vardır: siz belirtmezseniz name alanından türetilen, URL'lerde kullanılabilen bir ad. Slug boşluk içeremez ve rakamla başlayamaz.
Bir kaynağa başka bir kaynaktan başvurulduğunda slug kullanılır: bir kullanıcının role ve user_type alanları slug'dır; bir sağlayıcının defaultRole ve defaultUserType alanları da öyle.
Membership'lerin, rollerin, uygulamaların, kullanıcı tiplerinin ve sağlayıcıların tek kaynak endpoint'leri id'yi de slug'ı da kabul eder.

`sys` alanı#

Kaynaklar, sunucunun güncel tuttuğu bir sys nesnesi taşır:

json

"sys": {
	"created_at": "2026-01-01T12:00:00Z",
	"created_by": "admin",
	"modified_at": "2026-01-02T08:30:00Z",
	"modified_by": "backend"
}

created_by ve modified_by, değişikliği yapan kullanıcının username'ini ya da uygulamanın slug'ını tutar (setup ya da bir sağlayıcıyla kayıt gibi ErtisAuth'un kendi yaptığı değişikliklerde system). İstek gövdesinde gönderilen bir sys yok sayılır. Tüm tarihler UTC'dir.