Kendi kimlik doğrulama sistemini neden kurmamalısın: onlarca müşteri görüşmesinden alınan dersler

Kimlik doğrulama, insanın kendi başına halledebileceği bir iş gibi görünür. E-posta, şifre, hash'le, girişte karşılaştır. Kendi kimlik doğrulama sistemini kurmak ne kadar zor olabilir ki?

Yapabilirsin. Tuzak da burada.

Onlarca ekiple, kendi başlarına yazdıkları kimlik doğrulamayı konuştuk. Çoğu aynı nedenle bize geldi: işin önünde engel olmuştu.

Farklı sektörler, teknolojiler ve büyüklükler, ama aynı son. Kendi yazdıkları kimlik doğrulama sistemi, ekibin sırtında bir yük haline gelmişti.

İşin garip yanı, bu hiçbir zaman kesinti olarak ortaya çıkmaz. Sistem insanları içeri alır ve sorunsuzca çalışır; iş, büyük bir değişiklik gerektirene kadar: bir güvenlik denetimi, ilk kurumsal müşteri, bir satın alma, iki ürünü kapsayan bir özellik.

Geçen hafta "sorun yoktu." Sonra yol haritasındaki bir sonraki adım orada takılı kaldı.

Ev yapımı kimlik doğrulamada en büyük hata, bunu bir özellik gibi değerlendirmektir. İlk günde yazabilirsin. Ama gerçek trafik gelince, kullanıcıların, kuruluşların ve izinlerinle iç içe geçer.

Kimlik doğrulama bir özellik değildir. Kimlik altyapısıdır.

Giriş sayfasının ardında tüm bir kimlik modeli var#

Her ev yapımı kimlik doğrulama sistemi aynı şekilde başlar. Bir e-posta ve şifre al, hash'le, kaydet, girişte karşılaştır. Kırk satır kod, tertemiz bitti.

Sorunlar, yayına girdikten sonra başlar. Botlar kayıt noktasına yüklenir, hız limiti, CAPTCHA, cihaz parmak izi eklemek zorunda kalırsın. SMS kodları bir sabah çalışmaz, yeniden deneme ve günlük sınır eklemek gerekir. Sonra daha zorları gelir: güvenli şifre sıfırlama, MFA ve kurtarma akışı, oturumlar ve yenileme tokenları, ve is_admin boolean'ından çok daha fazlası olan bir izin modeli.

Bunların hiçbiri kendi başına zor değildir. Her biri bir sprintte biter. Ama her yeni özellikte, ürün adına daha büyük bir soruya yanıt vermiş olursun.

Bu yanıtlar üst üste yığılır ve üründe artık farkına varmadan doğru kabul edilen bir kimlik modeli oluşur: kim kullanıcı sayılır, bir kişi birkaç kuruluşa ait olabilir mi, bir kurumsal müşterinin kimlik sistemi nasıl entegre edilir ve biri ayrıldığında erişim nasıl geri alınır.

Sonrasında yazdığın her özellik, bu yanıtları verilmiş kabul eder ve sistem ne kadar uzun süre çalışırsa, değiştirmek o kadar zorlaşır.

Bunu bir şirkette böyle gördük: yirmi yıllık, yerel işletmelere hizmet veren, dikey bir B2B SaaS. On yıl önce kendi kimlik doğrulamasını yazmışlar, her müşteri için ayrı giriş ve izin kontrolleri doğrudan iş modüllerine eklenmiş. O zaman mantıklıydı.

Yirmi yıl sonra, ufak gibi görünen bir şey istediler: tek ve birleşik bir giriş sayfası, kullanıcı adı olarak e-posta. Oysa sayfa değişikliği değildi. O kontroller yüzlerce modüle yayılmıştı ve girişleri birleştirmek; kullanıcı modeline, kuruluş modeline, kimlik bilgisi göçüne ve her izin sınırına dokunmak demekti. Kimse buna imza atmak istemedi, yıllarca süründü.

O ilk giriş sayfasını yazdıklarında, bir özellik gibi görünüyordu. Geride ise tüm bir kimlik modeli bırakmışlardı.

İşin büyüdükçe ev yapımı kimlik doğrulama genellikle yetmemeye başlar#

Adil olmak gerekirse, ev yapımı kimlik doğrulama genellikle uzun süre sorunsuz çalışır. İnsanları içeri alır, oturumları yeniler, yıllarca günlük işin akışını taşır. Karmaşıklık yavaşça birikir, asla bir anda olmaz, sen de parça parça başa çıkarsın ve kontrol sende sanırsın.

Ama "yeterli" olması, çoğunlukla işin duvara çarpmamış olması demektir. O duvara gelince, mesele genellikle kimlik doğrulamanın kendisi değildir. Yanındaki iş değişmiş, "yeterli" bir gecede "engel"e dönüşmüştür.

Aşağıdaki durumlar, ölçeklendikçe çoğu üründe ortaya çıkar. Farklı görünürler, ama altında hep aynı sorun vardır: iş ilerledi, eski kimlik modeli yetemedi.

Kurumsal müşteriler SSO istemeye başlar#

Senaryo: Bir müşteri kendi IdP'siyle giriş yapmak ister, senin kimlik doğrulaman ise "başkasının kimlik sağlayıcısının" ne olduğunu bilmez.

İlk gerçek kurumsal anlaşma gelir, satın alma bir gereksinim dokümanı yollar. Önce onların Microsoft Entra veya Google Workspace'iyle SSO isterler. Sonra hem SAML, hem OIDC gerekir; çünkü diğer müşteri başka bir şey kullanıyordur. Ardından SCIM gelir, çalışanları otomatik ekleyip kaldırmak için.

Her müşterinin kurulumu farklıdır: protokoller, alan eşlemeleri, sertifika döngüleri ve onların kuruluş yapısı seninkine nasıl bağlanacak?

Ve hemen hiçbiri sonradan kullanılmaz. Sıradaki müşteri başka bir IdP ve yeni bir konfigürasyon getirir; çoğu baştan başlar. SSO bir kez yapılan bir özellik değildir. Her büyük müşterin için yeniden inşa edersin, maliyeti müşteri sayısıyla birlikte artar.

Kimlik doğrulama artık "kullanıcılar ürününe giriş yapsın" değildir. "Ürünün müşterinin kimlik sistemiyle entegre olsun"dur. İki bambaşka iş.

Bir şirketin tüm SSO kurulumunun elle yapıldığını gördük ve baştan sona tek bir mühendis biliyordu. O varken müşteriler yayına alınıyordu. O tatile çıkınca satışlar ve onboarding arkada sıraya giriyordu. O ayrılınca bilgi de onunla gitti.

Kendi kimlik doğrulamalarını yapmaya karar verdikleri gün bunlar hiç masada değildi.

Ürün, dağılmış kimliği birleştirmek zorunda kalır#

Senaryo: Kimlik datan başta parçalıydı, kuruluş ve ürüne göre bölünmüştü. Büyüyünce birleşik bir kimliğe ihtiyaç doğdu.

Yukarıdaki yirmi yıllık şirket login birleştirmek istediğinde bu duvara çarptı ve aynı durum başka ürünlerde de görünüyor. Dokuz ürünlü bir platformla çalıştık, hepsi satın alınmış, her biri kendi kimlik doğrulama ve kullanıcı deposuna sahip.

Birleşme satıldıkça olmaz. Her aldığın üründe bir kimlik doğrulama yığını daha miras kalır ve dokuz paralel sistem, sadece idame etmek için ciddi kaynak ister.

Sorular birikir. Aynı kişi ürün-A ve B'de tek bir kullanıcı mı, iki farklı mı? Müşteri kuruluşunu her iki üründe nasıl hizalarsın? Ürünler arası bir özelliğe nasıl yetki verirsin? Bir çalışan ayrıldığında dokuzunda birden erişimi nasıl kapatırsın? Bütün bunları nerede denetlersin?

Dokuzun biri bile arızalı değil. Birlikte olduklarında bir duvar.

"Kimliği birleştir" kulağa bir özellik gibi gelir. Kodda ise var olan en temel şeyi yeniden tanımlamaktır: bir kullanıcı ve kuruluş ne demek? Hemen her özellik eski tanım üstündedir; değişirse üstteki tüm katmanı oynatır.

Yapay zeka çağında, ajanlar ve CLI'lar kullanıcı adına sistemine erişir#

Senaryo: Artık yalnızca insanlar tarayıcıdan girmez. Şimdi ajanlar, komut satırları ve scriptler bir kullanıcı adına hareket etmek ister, senin kimlik doğrulaman ise sadece sayfadan giriş yapan insanı bilir.

Bir ajan, bir kullanıcı adına iç araçlarını çağırmalı. Bir MCP sunucu, korumalı kaynakları güvenli şekilde sunmak zorunda. Bir CLI, tarayıcı olmadan hesap verisine erişmeli.

Üçü de aynı soruları doğurur: Bu istek hangi kullanıcıya ait, hangi kaynağa erişebilir, token kime ait, kapsamı ne, nasıl iptal edersin, kullanıcıyı mı yoksa ajanı mı loglarsın?

Eski sistem bu istemcilerin ihtiyaç duyduğu mekanizmaları hiç üretmemiştir. MCP, yetkilendirme için OAuth'a dayanır. Bir CLI, ya OAuth login ile geçer, ya da bir kişiyi temsil eden, istendiğinde iptal edilebilen kişisel erişim token'ı taşır. Bunların hiçbiri bir giriş sayfasına göre yapılmamıştır.

Eğer kimlik doğrulaman bir sayfadan giren kişiye göre kurulmuşsa, şimdi bir istemcinin o kişi adına iş yapacağını desteklemek zorundasın.

Uzun vadeli bakım, kendi kimlik doğrulamanı kurmanın en büyük maliyetidir#

Yukarıdaki durumların hiçbirinde "kimlik doğrulama çöktü" yok. Sistem hâlâ çalışıyor. Her biri ufak bir özellik gibi görünür, ama başlarken ürün stratejisi, veri taşımaları ve müşteri teslimatına yaraşır bir işe dönüşür.

MFA en net örnek. Yüzeyde "giriş sonrası bir doğrulama daha".

İki adım sonra: hangi kuruluş ve kullanıcıda zorunlu, admin üyelerine mecbur bırakabilir mi, ödeme bilgisi değiştirmek ya da veri dışa aktarmak gibi hassas işlemlerde yeniden doğrulama mı gerekir, kurtarma kodları nasıl üretilir ve sıfırlanır, destek ekibi sıfırlayabilir mi, SSO kullanıcısının MFA'sı kime aittir - sana mı müşterinin IdP'sine mi? MFA eklemek, tüm bir güvenlik politikası katmanı eklemektir.

"Sadece bazı kullanıcıları senkronize et" aynı hikaye: Arkasında onboarding, offboarding, çapraz kuruluş üyeliğiyle ilgili bir dizi karar var, hepsi kullanıcı ve kuruluş modellerinin başlangıçtan doğru tasarlandığını varsayar.

Ne kadar fazla özellik eklersek, o kadar bir kimlik ürünü kendi ürünümüzün içine gömmüş oluruz. İlk sürüm ucuzdur, birkaç mühendis ve birkaç hafta. Ama yıllarca beslersin.

Gizli maliyet: Fatura sadece nasıl ödendiğini değiştirir#

Kendi yazmanın en yaygın nedeni maliyettir ve safça değildir.

Görüştüğümüz bir üyelik organizasyonu beş yıl önce hesap yaptı. Yaklaşık yüz bin üyesi vardı, ama düzenli giriş yapan birkaç bin. Tedarikçiler toplam üye sayısına göre fiyat biçiyor, teklif bütçeyi ikiye katlamıştı, kendin yazmak daha ucuz çıktı. O yıl, yanlış bir karar değildi.

Beş yıl sonra, denklem değişmişti. Kendi girişlerini koruyup güvenli tutmanın maliyeti, almak olandan daha fazlaydı.

Birinci yılda, kaçtığın fatura görünür, mühendislik zamanı ise gözükmez. Beşinci yılda, kurtarılan tutar aynı, ama mühendis zamanı yol haritası gecikmelerine, güvenlik borcuna ve kimsenin devralmak istemediği bakıma dönüşmüştür.

Yani kendi kimlik doğrulamanı yazmak bedava değil. Sadece "kimlik doğrulama aboneliği" diye bir fatura gelmez. Kişi/aylarla, kaçan teslim tarihlerinde, yeniden işlerde, güvenlik borcunda ve çekirdek üründe harcayabileceğin mühendislik dikkatinde ödersin.

Bir avuç mühendis üstlenmek zorunda kalır#

O SSO'yu elde yöneten mühendis bir istisna değil. Ev yapımı kimlik doğrulama yeterince uzun çalışınca, kritik bilgi bir iki kişiye birikir: hangi müşteri nasıl yapılandırıldı, hangi alanı dokunmamalısın, geçmiş bir veri taşımacılığının nedeniyle ilgili toplu bilgi. Nadiren dokümana yazılır. Hep birinin kafasındadır.

O oradaysa teslimatlar yürür. O yoksa kurumsal satış kuyruğa girer ve en önemli altyapının bir sahibi değil, sadece "bilen kişi"si olduğu ortaya çıkar.

Bazı ekipler bir adım öteye geçip, müşterilere tam bir self-servis SSO konfigürasyon platformu yazar. Kulağa olgun gelir, ama kaç müşteriye hizmet verdiğini sorunca ortaya çıkar. 1.5 milyon aylık aktif kullanıcısı olan bir sistemde, tüm bu altyapı on iki müşteriye anca çalışıyordu.

Bir özellik yazdığını sandın. Aslında dahili bir ürün yazdın, maliyeti bir avuç müşteriye paylaştın. Eğer kimlik işin ise buna değer. Değilse, bu en saf haliyle gizli bir faturadır.

Mühendislerini nerede kullanmak istersin?#

O yirmi yıllık SaaS'a dönelim. Zayıf mühendisler değiller. Yirmi yıl bir sektörde ürün hayatta tutmak, müşterisini iyi tanıyanları gösterir.

Asıl problem de bu. Dürüstçe sor: Her müşterinin SSO'sunu elde yönetmek ve yirmi yılın izin mantığını yüzlerce modülden çıkarmak mı, yoksa asıl sektör yazılımını ileri taşımak mı istersin?

Bu mühendislik mükemmeliyetçiliği değil. Bu kaynak tahsisi. Eğer fatura ödeme, dikey SaaS, üyelik portalı veya operasyon yazılımı yapıyorsan, kendi OAuth servenı yazdın diye sana fazladan bir kuruş ödeyen olmaz.

Görüştüğümüz bir fatura ödeme ekibi açıkça söyledi: kendi IdP'leri iyiydi, ama strateji meselesi. Kimlik doğrulamaya çok kod yazma. Gücünü fatura ödemeyi en iyi yapmak için sakla, geri kalan için en güvenilir kimlik doğrulamayı kullan.

Kimlik doğrulama güvenilir olmalı. Ama "güvenilir" demek, "seni yazdın" demek değildir. Veritabanın, e-posta altyapın, bulutun da güvenilir olmalı ve olgun bir ekip, sırf önemli diye her şeyi içeride tutmaz.

Çoğu ürün için, kimlik doğrulama temel bir bağımlılıktır, ayırt edici bir özellik değil. Kimlik temelli ürün yapmıyorsan, ürün içinde bir kimlik ürünü çalıştırmak genellikle bir siper değildir. Kaynağı uzun vadede tüketen bir derttir.

Kendi kimlik doğrulamanı yapmak ne zaman hâlâ mantıklı?#

Bir uç noktaya savrulmak kolaydır: Hiç kimlik kodu yazma. O da yanlış.

Bazen, kendi çözümünü (ya da yarısını) yapmak tamamen mantıklıdır: dahili demolar, çok erken prototipler, tek seferlik validasyon projeleri. Ve işin gerçekten çok özel, ince ayarlı yetkilendirmeler gerektiriyorsa, piyasadaki platformların asla ifade edemeyeceği özgünlükteyse, o kısmı içeride tutup, kimlik doğrulama, oturum, SSO, MFA ve kullanıcı dizinini harici bir platforma bırakmak tamamen makuldür.

Sadece POC eğilimine dikkat et. Tipik yol şudur: İki geliştirici, harici bir sistemi entegre eden bir prototip için altı ila sekiz ay harcar. Yöntem kötü değil. Kendi sözleriyle ürün güzel. Ama hiçbir zaman ölçek taşımak için yazılmamış.

Ve bir POC'u uzun vadeli altyapıya dönüştürmek en kolay şeydir. Altı ay sonra "mevcut çözüm" olur, iki yıl sonra "eski sistem", beş yıl sonra "dokunulamaz altyapı". Ev yapımı kimlik doğrulamadan çıkmanın en iyi zamanı genellikle arızadan sonra değil, temel haline gelmeden önce olur.

Yani çizgi şudur: Sorun, bir satır kimlik doğrulama kodu yazıp yazmadığın değildir. Sorun, genel bir kimlik altyapısını üstlenip, uzun vadede kendi ekibinde tutup tutmadığındır.

Uçtaki yetenekleri kendin yaz. Çekirdek kimlik katmanında dikkatli ol. Farkında olmadan kendine tam teşekküllü bir CIAM platformu inşa etme.

Kendi kodunu yazmayacaksan, hangi kimlik doğrulama çözümünü seçeceksin?#

Kendi yazmamaya karar verdiysen, sıradaki soru ortaya çıkar: Hangisini alacaksın, neye göre seçeceksin?

Olgun çözümlerde özellik seti genellikle hazırdır: SSO, MFA, çoklu kuruluş, birleşik giriş, ajan erişimi. Yani gerçek fark genellikle özellik tablosu olmaz.

Gözden kaçan ve karşılaştırmaya değer olan aşağıdaki noktalar var. Bunlar tek bir şeyin farklı boyutları: Kendin yazdığın birkaç bin satırdan çıkıp, kaçılamaz başka bir sisteme hapsolma.

• Kendi standart protokollerinde kal, bir tedarikçinin icat ettiği yığını seçme. OIDC, OAuth, RS256 imzalı JWT'ler zaten anladığın şeyler. Token'dan claim'leri doğrudan okursun, tedarikçiye özgü bir API öğrenmezsin.
• Gerçekten çıkabileceğin bir kapın olsun. Çözüm açık kaynak ve kendin barındırabilir ise, istediğinde gidebilirsin. (Kendin barındırmak uzun vadede ayrıca gizli bir maliyettir tabii.)
• Faturalandırma kullanıcı tablonu takip etmesin. Kayıtlı kullanıcıya veya aylık aktife göre fiyat, sadece büyüyen bir tabloya endekslenir, yeniden giriş yapmayan da doludur, ölçek büyüdükçe "büyüme vergisi"ne dönüşür. Yukarıdaki üyelik örgütünü kendi yazmaya iten de bu fiyatlamaydı.
• Verilerin kilitli kalmaz. Kullanıcı verilerini istediğin zaman dışarı çıkarabilirsin. Ve bu hassas verileri uzmanına emanet etmek, aslında doğru kişi olmadığın bir yüke girmekten kurtarır.

Açık not: Logto tam bu dört noktaya karşı geliştirdiğimiz kimlik ürünü. Açık kaynak, kendin barındırabilirsin, aynı zamanda yönetilen Bulut'da da sunuluyor: Bakımsız Cloud'u kullan, ya da tam kontrol için açık kaynak sürümünü barındır, taşınmak istediğin gün kapı açık kalır.

Giriş, MFA, SSO ve RBAC kutudan çıktığı gibi standart OIDC ile çalışır, faturalama token'a göre olur, ne kadar kullanırsan onu ödersin.

Başka olgun seçenekler de var ve kimlik doğrulama hiçbir zaman tek doğru yanıtı olan bir soru değildi. Değerlendireceksen, kimlik sağlayıcı nasıl seçilir hakkında yazdığım tüm yazıya bakabilirsin.

Sonuç: Uzun vadeli kimlik platformunu sıradan özellik sanma#

Kendi kimlik doğrulamanı yazmak, ilk gün genellikle makul bir karar. Sıkıntı, sonradan altyapıya dönüşmesinde.

İş her büyüdüğünde, tekrar tekrar önüne çıkar: Kurumlar SSO ister, güvenlik MFA ister, ürün birleşik giriş ister, çoklu ürünler bağlanmak ister, AI ajanları kullanıcıya kaynaklara ulaşmak ister. O ufak görünen her özelliğin arkasında bir dizi politika sorusu vardır ve yıllar boyunca hepsine cevap verirken, çekirdek ürününden yemiş olursun.

Bu fatura ilk gün gelmez. Genellikle seneler sonra ortaya çıkar. O zaman sonunda görürsün: O zamanlar yazdığın giriş sayfası, aslında ürünün tüm ömrüne işleyecek kimlik altyapısıymış bile.

Kimlik doğrulama muhtemelen çekirdek işin değil. Bunu ne kadar erken görürsen, zamanını, enerjini ve kaynağını gerçekten inşa ettiğin ürüne o kadar hızlı geri döndürebilirsin.

Sıkça Sorulan Sorular#

Hiç mi kendi kimlik doğrulama sistemi kurmamalı?#

Hayır. Erken demolar, dahili araçlar, tek seferlik validasyon projeleri ya da hazır çözümlerin asla kapsayamayacağı kadar özel, ince yetkilendirmeler gerektiriyorsa, hepsi uygun olabilir. Kaçınman gereken, uzun vadeli genel bir kimlik altyapısını üstlenip, farkına varmadan bir iş ekibinin bakım görevine park etmektir.

Kimlik doğrulama ile yetkilendirme arasındaki fark nedir?#

Kimlik doğrulama "kimsin" sorusunu yanıtlar. Yetkilendirme "ne yapabilirsin" sorusuna cevap verir. Gerçek bir SaaS'ta ikisi ayrılmaz: kullanıcılar, kuruluşlar, roller, izinler, oturumlar, token claim'leri ve denetim log'ları hep birbirine geçer. O yüzden kimlik sistemi değiştirince sadece giriş sayfasına bakmak yetmez.

Neden kurumsal SSO, ev yapımı kimlik doğrulamayı zorlaştırır?#

Çünkü artık ürününü müşterinin kendi kimlik sistemine takmak gerekir. Farklı müşteriler farklı IdP, protokol, claim alanı, sertifika ve kuruluş eşlemeleri kullanır. İlkini bağlamak, kalanların kopyala-yapıştır olacağı anlamına gelmez. Çoğu zaman, bir mühendisin özel bilgisiyle elle yürütülür.

Yıllardır kendi sistemimizi çalıştırıyoruz. Hâlâ geçiş yapabilir miyiz?#

Evet, ama tek seferde sert geçiş genellikle çözüm değil. Katman katman taşımak gerekir: yeni kayıtları, girişleri ve kurumsal SSO'ları önce kimlik platformuna koy, mevcut kullanıcıları bir sonraki girişlerinde taşı. Her adımda geri dönüş yolu ve denetim log'ları tut ki, geçiş asla geri dönüşsüz olmasın.