Kullanıcı girişini kendimiz mi yazalım, hazır kimlik servisi mi kullanalım?

Kısa cevap: kimlik doğrulama sizin ürününüz değilse hazır bir çözüm kullanın, ama "hazır" kelimesinin iki ayrı şeyi anlattığını bilerek karar verin. Bir yanda faturası aylık aktif kullanıcı sayısına bağlı bulut kimlik servisleri var (Auth0, Clerk, Amazon Cognito, Microsoft Entra External ID). Diğer yanda kendi sunucunuzda çalıştırdığınız açık kaynak kimlik sunucuları var (Keycloak, Zitadel, Ory, Authentik, FusionAuth). Üçüncü seçenek, giriş akışını uygulamanın içinde bir kütüphaneyle taşımak. Ekiplerin "kendimiz yazalım" derken kastettiği şey neredeyse her zaman üçüncüsüdür, yani sıfırdan kriptografi değil, olgun bir kütüphanenin etrafındaki akışların sahipliği. Karar da tam orada veriliyor: parolayı doğrulamak kolaydır, hesap kurtarmayı, oturum iptalini, MFA kaydını ve üç yıl sonra gelecek kurumsal SSO talebini taşımak zordur.

Giriş ekranı bir özellik değil, bir alt sistem

Kapsamı görmenin en hızlı yolu OWASP'ın uygulama güvenliği doğrulama standardına bakmak. 30 Mayıs 2025'te yayımlanan ASVS 5.0, 17 bölümde yaklaşık 350 gereklilik içeriyor ve bunların dördü doğrudan "giriş" dediğimiz şeyle ilgili: V6 Kimlik Doğrulama, V7 Oturum Yönetimi, V9 Kendi Kendine Yeten Token'lar, V10 OAuth ve OIDC. Tek başına V6, sekiz alt başlıkta 50 gereklilik taşıyor. Alt başlıkların adları işin dağılımını da gösteriyor: parola güvenliği, genel kimlik doğrulama güvenliği, kimlik faktörünün yaşam döngüsü ve kurtarma, çok faktörlü doğrulama, bant dışı yöntemler, kriptografik yöntemler ve kimlik sağlayıcıyla doğrulama.

Parola tarafı bile göründüğünden daha kalabalık. NIST'in Ağustos 2025'te yayımlanan SP 800-63B Revizyon 4 belgesi net kurallar koyuyor: parola tek başına kimlik doğrulama aracıysa en az 15 karakter zorunlu, sadece çok faktörlü akışın parçasıysa 8 karaktere düşülebilir, en az 64 karakterlik girdiye izin verilmeli, karakter türü zorunlulukları (büyük harf, sayı, sembol) getirilmemeli, girilen parola bilinen ve ele geçirilmiş parola listesine karşı kontrol edilmeli ve periyodik parola değişimi istenmemeli. Sadece ele geçirilme kanıtı varsa değişim zorlanır. ASVS aynı yaklaşımı seviyelere bağlıyor: birinci seviyede en azından politikanıza uyan ilk 3000 parolaya karşı kontrol, ikinci seviyede ele geçirilmiş parola kümesine karşı kontrol isteniyor.

Saklama tarafında OWASP'ın parola saklama rehberi Argon2id için asgari yapılandırmayı 19 MiB bellek, 2 tur ve 1 paralellik olarak veriyor; bellek yerine CPU harcamak isteyene 46 MiB, 1 tur, 1 paralellik alternatifini sunuyor. bcrypt kullanıyorsanız iş faktörü en az 10 olmalı ve 72 baytlık girdi sınırını hatırlamak gerekiyor, çünkü uzun parolalar sessizce kesilir. Bu üç paragraf, "giriş ekranını iki günde yazarız" cümlesinin neden hep iki güne sığmadığını açıklıyor.

Üç seçeneğin gerçek sınırları

Bulut kimlik servisi, ilk sürüme en hızlı çıkaran yol. Sosyal giriş, MFA, e-posta doğrulama, parola sıfırlama ve yönetim arayüzü hazır gelir; siz sadece uygulamayı OpenID Connect istemcisi haline getirirsiniz. Bedeli iki yerde çıkıyor: fatura kullanıcı sayınızla büyür ve ihtiyacınız olan özellik hangi kademedeyse fiyatınız oradan başlar.

Açık kaynak kimlik sunucusu, orta yol. Keycloak Nisan 2023'te CNCF'e bağışlandı ve inkübasyon aşamasında, Apache-2.0 lisanslı ve Red Hat destekli. Protokol tarafında bulut servisleriyle aynı işi yapar, verinin tamamı sizde kalır, kullanıcı sayısına göre fatura yoktur. Karşılığında bir bileşen daha işletiyorsunuz: sürüm yükseltmeleri, yedek ve geri dönüş, yüksek erişilebilirlik, sertifika yenileme, tema ve akış özelleştirmeleri. Devops kapasitesi olan ekipler için makul, tek geliştiricili projelerde genelde kötü bir takas.

Kütüphane seçeneği ise kullanıcı tablosunun sizde kaldığı, akışları sizin kodladığınız model. Auth.js, Better Auth, Spring Security, Devise gibi olgun kütüphaneler kriptografiyi ve oturum yönetimini üstlenir. Tek uygulamalı, tek istemcili, kurumsal SSO beklentisi olmayan ürünlerde en düşük sürtünmeli çözüm bu. Sınırı şurada: ikinci uygulama, mobil istemci ya da servisler arası yetkilendirme geldiğinde elinizde bir yetkilendirme sunucusu olmadığını fark ediyorsunuz.

Kendi yazarsanız sahiplendiğiniz iş listesi

Parola doğrulama bu listenin en kolay kalemi. Geri kalanı şöyle görünüyor: kayıt ve e-posta doğrulama, tek kullanımlık ve süresi dolan sıfırlama bağlantıları, kullanıcı varlığını sızdırmayan hata mesajları, hız sınırlama ve saldırganın hesabı kilitleyerek hizmeti engellemesine izin vermeyen bir kilitleme politikası, parola değişiminde tüm cihazlardaki oturumların iptali, MFA kaydı ve kurtarma kodları, kullanıcının aktif oturumlarını görüp sonlandırabildiği bir ekran, yönetici olarak kullanıcı kimliğine bürünme özelliğinin denetim kaydı.

Bu listede saldırıya en açık yer parolanın kendisi değil, kurtarma akışıdır. ASVS'in V6.4 başlığını ayrı açması boşuna değil: ilk kimlik bilgisinin nasıl üretildiği, sıfırlamanın nasıl doğrulandığı ve yönetici müdahalesinin nasıl sınırlandığı ayrı gerekliliklerle tanımlanıyor. Pratikte gördüğümüz en yaygın hata, e-posta sıfırlama bağlantısının süresiz ya da tekrar kullanılabilir olması. İkincisi, MFA açık bir hesapta kurtarma akışının MFA'yı atlaması. Böyle bir sistemde ikinci faktör vitrindir.

Satın alırken faturanın görünmeyen kısmı

Fiyat listesinde kullanıcı başına maliyeti görürsünüz, kararı belirleyen kalemleri genelde görmezsiniz. Kurumsal SSO (SAML ya da OIDC federasyonu) bu kategorinin en pahalı eklentisi ve çoğu satıcıda ya bağlantı başına ücretli ya da yalnızca üst kademede açık. Denetim kayıtlarının saklama süresi, MFA yöntemlerinden hangilerinin hangi kademede olduğu, makineden makineye token'ların ayrıca ölçülmesi, yönetim API'sinin hız sınırı ve kendi alan adınızda giriş sayfası sunma hakkı da aynı yerlerde saklanır.

Fiyatların iki yöne de hareket ettiğini hesaba katın. Auth0 2024'te ücretsiz kademesini 7.500 aylık aktif kullanıcıdan 25.000'e çıkardı; başka satıcılar aynı dönemde kademelerini yeniden düzenledi. Bu yüzden karşılaştırmayı bugünkü kullanıcı sayınızla değil, üç yıl sonraki tahmininizle ve ihtiyacınız olan özelliklerin bulunduğu kademeyle yapın. Yıllık maliyeti bir geliştiricinin bu işe ayıracağı zamanla kıyaslamak da işe yarar, ama kıyası kurulum değil bakım üzerinden kurun: kimlik altyapısı kurulduktan sonra da yaşayan bir sistemdir.

Satın almak riski devretmez, işi devreder

Kimlik sağlayıcı kullanmak saldırı yüzeyini küçültür, ama sıfırlamaz. Okta'nın Ekim 2023'te açıkladığı müşteri destek sistemi ihlali bunun ders kitabı örneği: olay ilk duyuruda 134 müşteriyi, yani müşteri tabanının yüzde birini etkiliyor gibi görünüyordu, sonraki güncellemede saldırganın destek sistemindeki 18.400 kullanıcının tamamının ad ve e-posta bilgisini indirdiği ortaya çıktı. Bir sağlayıcıya bağlandığınızda o sağlayıcının olay müdahale kalitesi sizin olay müdahale kalitenizin parçası oluyor.

Erişilebilirlik tarafında da somut bir soru var: sağlayıcı çöktüğünde ne oluyor? Mevcut oturumlar ayakta kalıyor mu, yeni girişler mi duruyor, yoksa uygulamanın tamamı mı kapanıyor? Bu soruyu sözleşme imzalamadan önce cevaplayın ve cevabı izlenebilirlik ve hata bütçesi hesabınıza yazın. Bir de tedarik zinciri boyutu var: sağlayıcının tarayıcıda çalışan SDK'sı sizin sayfanızda çalışıyor. Aynı mantık yazılım tedarik zinciri güvenliği yazımızdaki bağımlılık tartışmasının kimlik tarafındaki karşılığıdır.

Çıkış maliyeti: parola hash'i taşınmıyor

Kimlik kararının en pahalı kısmı geri dönüş. Amazon Cognito kullanıcı havuzundan parola hash'lerini ve MFA gizli anahtarlarını dışa aktarmak mümkün değil. Yani başka bir sağlayıcıya geçiyorsanız ya tüm kullanıcılara parola sıfırlama e-postası atıyorsunuz ya da yavaş göç yapıyorsunuz: yeni sistem, kullanıcı ilk kez giriş yaptığında parolayı eski sistemde doğrular, doğruysa kendi tarafında hash'leyip kaydeder ve o kullanıcıyı taşımış olur. Bu desen çalışır, ama iki sistemi aylarca yan yana işletmek demektir ve hiç giriş yapmayan kullanıcılar için yine sıfırlama gerekir.

Daha sinsi bir bağımlılık, sağlayıcının ürettiği kullanıcı kimliğinin veritabanınıza yayılması. Token'daki sub değerini kendi tablolarınızda yabancı anahtar olarak kullandıysanız, sağlayıcıyı değiştirmek onlarca tablodaki referansı yeniden eşlemek anlamına gelir. Ucuz sigorta şu: kendi kullanicilar tablonuzda kendi kimliğinizi üretin, sağlayıcının kimliğini o satırda bir alan olarak tutun ve geri kalan tüm ilişkileri kendi kimliğinize bağlayın. Aynı şekilde sağlayıcının kural motorunda yazdığınız kodu (Auth0'da actions, Keycloak'ta authenticator) mümkün olduğunca ince tutun; oraya giren iş mantığı taşınmaz.

Standarda bağlanın, satıcıya değil

Taşınabilirliği sağlayan şey satıcı seçimi değil, sınırın nerede çizildiği. Uygulamanız sağlayıcıyla yalnızca OpenID Connect üzerinden konuşuyorsa değişim bir yapılandırma işidir. Sağlayıcının özel API'lerine, özel token biçimlerine ve özel oturum davranışına yayıldıysa değişim bir proje olur.

Protokol tarafında Ocak 2025'te yayımlanan RFC 9700 (BCP 240) bugünün asgari çizgisini tanımlıyor: genel istemciler PKCE kullanmak zorunda, yetkilendirme sunucuları PKCE'yi desteklemek zorunda, yönlendirme adresleri tam dizi eşleşmesiyle doğrulanmalı, implicit akışı kullanılmamalı, kaynak sahibinin parolasını istemciye veren akış (ROPC) kullanılmamalı ve genel istemcilerin yenileme token'ları ya göndericiye bağlanmalı ya da her kullanımda döndürülmeli. OAuth 2.1 hâlâ IETF taslağı; RFC 8252, PKCE (RFC 7636), tarayıcı tabanlı uygulamalar taslağı ve RFC 9700'ü tek belgede toplayacak. Kısa versiyonu şu: girişinizi "yetkilendirme kodu artı PKCE" diye anlatamıyorsanız elinizde kendi protokolünüz var ve onu kimse denetlemedi.

Token'ı tarayıcıda tutmak ayrı bir karar

Sağlayıcı seçtikten sonra gelen ikinci soru, token'ların nerede duracağı. IETF'in tarayıcı tabanlı uygulamalar taslağı en güvenli deseni açıkça işaret ediyor: sunucu tarafında çalışan bir arka uç (backend for frontend), OAuth istemcisi olarak sağlayıcıyla konuşur, erişim ve yenileme token'larını kendi tarafında tutar, tarayıcıya yalnızca HttpOnly bir oturum çerezi verir. Tarayıcı token görmediği için XSS ile token sızdırmak da mümkün olmaz.

Next.js, Nuxt ya da benzeri sunucu tarafı çalışan bir çatı kullanıyorsanız bu desen zaten elinizin altında, ek altyapı gerektirmiyor. Tamamen istemci tarafında çalışan tek sayfa uygulamalarında token'ı tarayıcı hafızasında tutmak zorundaysanız, en azından yenileme token'ı rotasyonunu ve kısa ömürlü erişim token'larını şart koşun. Uç nokta tarafındaki kontrolleri API güvenliği ve OWASP API Top 10 yazımızda ayrıntılandırdık.

B2B satıyorsanız karar erken zorlanır

Kurumsal müşteriye satış yapan ürünlerde kararı hızlandıran şey teknik zarafet değil, satın alma listesi. Belirli bir büyüklükten sonra müşteri kendi kimlik sağlayıcısıyla giriş ister (Entra ID, Google Workspace, Okta), çalışan işten ayrıldığında hesabın otomatik kapanmasını ister ki bu SCIM ile kullanıcı sağlama demektir, kendi MFA ve oturum süresi politikasını uygulamak ister, alan adı doğrulaması ve ilk girişte otomatik hesap açma ister. Bunların hepsini kendiniz yazmak mümkündür, ama her yeni müşteri için ayrı bir federasyon yapılandırması yönetmek ekibin sürekli işi haline gelir.

Buradaki tasarım hatası genelde daha derinde oluyor: kullanıcı ile kuruluş ilişkisinin tek olduğu varsayılıyor. Aynı kişinin iki farklı müşteri hesabında bulunabileceğini baştan modellemezseniz, ilk danışmanlık firması müşteriniz olduğunda veri modelini açmak zorunda kalırsınız. Kiracı sınırının veri katmanında nasıl kurulduğunu çok kiracılı SaaS mimarisi yazımızda ele aldık; kimlik tarafındaki karşılığı, kiracı kimliğinin her zaman token'dan türetilmesi ve istek gövdesinden gelen değere asla güvenilmemesidir.

Ölçütler: hangi durumda hangisi

Bulut kimlik servisi alın: ekip küçükse, birden fazla istemciniz varsa (web, mobil, servis), kurumsal SSO talebi kısa vadede geliyorsa ve kullanıcı sayınız faturayı üç yıl boyunca makul tutuyorsa. Kendi sunucunuzda açık kaynak kimlik sunucusu çalıştırın: verinin ülke içinde ve sizin kontrolünüzde kalması bir gereklilikse, kullanıcı sayısı büyükse ve işletme kapasiteniz varsa. Kütüphaneyle uygulamanın içinde tutun: tek uygulama, tek istemci, kurumsal federasyon beklentisi yok ve giriş akışını özelleştirme ihtiyacı yüksekse.

Üç seçenekte de değişmeyen iki kural var. Parola saklamayı, token imzalamayı ve oturum çerezi üretmeyi kendiniz yazmayın; bu işleri kütüphaneye bırakın. İkinci faktörü baştan planlayın, sonradan eklenen MFA her zaman kurtarma akışında bir boşluk bırakır. Yöntem seçimini çok faktörlü kimlik doğrulama ve passkey yazılarımızda karşılaştırdık.

Bu hafta yapılabilecek beş iş

Bir: parola sıfırlama bağlantınızı test edin. Aynı bağlantı ikinci kez çalışıyorsa ya da bir gün sonra hâlâ geçerliyse, önce bunu düzeltin. İki: parola değiştirdikten sonra eski cihazdaki oturumun kapandığını doğrulayın; kapanmıyorsa ele geçirilmiş bir oturumu iptal etme yolunuz yok demektir. Üç: MFA açık bir test hesabında kurtarma akışını deneyin ve ikinci faktörü atlayıp atlamadığını görün. Dört: sağlayıcı kullanıyorsanız fiyat listesinde kurumsal SSO, denetim kaydı saklama süresi ve makineden makineye token kalemlerinin hangi kademede olduğunu yazın, üç yıllık tahmininizle çarpın. Beş: veritabanınızda sağlayıcının ürettiği kullanıcı kimliğinin kaç tabloda yabancı anahtar olarak durduğunu sayın; sayı sıfır değilse çıkış maliyetinizi bulmuş oldunuz.

Bu beş adım kararı vermiyor, kararın bedelini görünür kılıyor. Kimlik tarafında en pahalı hata yanlış sağlayıcıyı seçmek değil, sınırı yanlış yere çizip iki yıl sonra geri dönemeyecek hale gelmek. Karara oturduğunuzda da diyagramla değil ölçüt listesiyle başlayın; aynı çerçeveyi hazır paket mi, özel yazılım mı yazımızda da kurmuştuk.