Kendi kimlik doğrulama sistemini bir günde inşa edebilirsin. Tuzak tam da burada.
Onlarca B2B ekip bize benzer bir hikaye anlattı. Her şey basit bir giriş sayfası ile başlıyor. Gerçek trafik üzerinden akmaya başlayınca, fark etmeden kimlik altyapısına dönüşüyor: ürününün tamamen üstüne kurulduğu temel oluyor.
Bir özellik gibi görünüyordu. Ardında bütün bir kimlik modeli bıraktı.
Her kendi inşa edilen kimlik doğrulama sistemi birkaç satır kodla başlar. Sorunlar, çıktıktan sonra başlar; küçük kararların her biri, ürününün tamamının doğru kabul ettiği modele sessizce dönüşür.
Birinci gün: kırk satır kod
E-posta, şifre, şifrele, sakla, girişte kıyasla. Temiz ve tamam.
İki yüzüncü gün: sessiz bir kimlik modeli
Kim kullanıcı sayılır? Hangi kuruluşa ait? Hangi oturum hala güvenilir? Erişim nasıl geri çekilir?
Beşinci yıl: dokunamayacağın bir temel
Kâğıt üstünde sadece giriş sayfasını değiştirmek, kodda kimlik temelini baştan inşa etmek anlamına geliyordu.
Kendi yapımın kimlik doğrulama yıllarca sorunsuz çalışır — ta ki iş değişene kadar
İnsanları yıllarca problemsiz giriş yapar. Sonra bir iş değişikliği, “yeterli” olanı bir gecede “engel” haline getirir. Büyüyen hemen hemen her üründe bu üçü mutlaka karşına çıkar.
Kurumsal müşteriler SSO istemeye başlar
İlk büyük anlaşma gelir ve satın alma ekibi kendi Entra veya Google Workspace’i ile SSO ister. Sonra hem SAML hem de OIDC gerekir, çünkü diğer müşteri başka bir sistem kullanır. Her müşterinin kimlik altyapısı farklıdır ve yapılan işin neredeyse hiçbiri bir sonrakine aktarılmaz.
- Her müşteri için farklı protokoller, alan eşleşmeleri ve sertifika rotasyonları
- SSO bir defa yapılmaz. Her kurumsal müşteriyle tekrar baştan inşa edilir
- Sessizce, uçtan uca sadece bir mühendisin tam olarak anlayabildiği bir el işine dönüşür
Dağınık başlayan kimlik şimdi birleşmek zorunda
Kuruluşlara göre ayrılmış, ürüne göre bölünmüş, genellikle satın almalarla gelmiş parçalar. “Kimliği birleştir” kulağa bir özellik gibi gelir; kodda ise bir kullanıcı ve bir kuruluşun ne olduğu baştan tanımlanır.
- Bir e-posta birkaç kuruluşa ait olabilir mi? Geçmiş kullanıcı adları nasıl taşınacak?
- Satın alınan dokuz ürün, dokuz ayrı kimlik doğrulama yığını ile paralel çalışır
- Hepsinde birden ayrılan birinin erişimini iptal et ve her şeyi tek yerde denetle
Yapay zekâ ajanları ve CLI'lar kullanıcı adına hareket etmeye başlar
Artık sadece tarayıcıdaki insanlar yok. Ajanlar, MCP sunucuları ve komut satırları da bir kullanıcı adına işlem yapıyor. Ve senin kimlik doğrulama sistemin sadece bir kişinin bir sayfaya girişini biliyor.
- Token kime, hangi kapsam ve hangi yetki ile verildi?
- Sadece bir aracıya veya veri dilimine izin ver, sonra geri al
- MCP ve CLI erişimi için OAuth gerekir, giriş formu değil
Asıl maliyet inşası değil. Yıllarca onu taşımak.
İlk sürüm ucuz: birkaç mühendis, birkaç hafta, tamamlandı. Sonrasında ise her yıl, ana ürünü geliştirmesi gereken mühendislik zamanı burada harcanır.
Fatura sadece ödeme şeklini değiştirdi
Hiçbir zaman “kimlik doğrulama” başlıklı bir fatura gelmez.
Sessizce bir veya iki kişiyle yürür
Kritik bilgiler dokümanlarda değil, birinin kafasındadır.
Mühendislerini nerede görmek istersin?
Kendi OAuth sunucunu yazdığın için hiç bir müşteriden fazladan kuruş almazsın.
Kendin inşa etmiyorsan, nasıl seçim yapacaksın?
Olgun kimlik doğrulama sistemlerinde zaten SSO, MFA, kuruluşlar, birleşik giriş, ajan erişimi gibi özellikler var. Asıl fark, ayrılabilirlikte. Birkaç bin kendi satırından kurtulup başkasına kilitlenmemeye dikkat et.
Uydurma bir yığın değil, standart protokoller
Gerçekten çıkabileceğin bir kapı
Faturalandırma kullanıcı tablonu takip etmez
Verilerin asla kilitli kalmaz
Kimlik doğrulama muhtemelen senin ana işin değil. Ona göre davran.
Logto açık kaynak, kendin barındırabilirsin ve yönetilen bulut olarak da sunulur. Standart OIDC ile giriş, MFA, SSO ve RBAC kutudan çıkar çıkmaz çalışır. Faturalama token’lara göre işler, ta şınmak istediğinde kapı açık kalır.