Geçen kış, Şubat 2025’te İstanbul Levent’te bir müşteri görüşmesindeyim. Karşımdaki adam kahvesini bile içmeden masaya koydu ve dedi ki: “SSO lazım. Birden fazla sağlayıcı olacak. Müşteriye göre değişecek. Önümüzdeki sprint’te başlasak iyi olur.” Ben de kahvemi tutmuş, masanın köşesine bakıyorum — kafamda tek soru: bu iş sandığımdan daha mı sert olacak? Cevap, dürüst olayım, çok gecikmedi.
Evet.
Daha önce JWT yazmıştım. Session tabanlı giriş de kurmuşluğum var, OAuth2 callback tarafında da epeyce didikleme yaptım açıkçası. Ama kurumsal SSO başka bir seviye — her tenant kendi kimlik sağlayıcısını getiriyor, rol eşleşmesi otomatik akıyor, Azure AD’den biri gruptan çıkarılınca uygulamada erişimi dakikalar içinde kesilmesi gerekiyor, aksi hâlde iş çöpe gidiyor. Yani “login” dediğin şey burada kapı zili değil. Bina güvenliği gibi çalışıyor.
İlk Tür: Bir Kütüphaneyi Zorla Eğitmeye Çalışmak
İlk refleksim gayet tanıdıktı. “Django için hazır bir kütüphane vardır.” Aradım, taradım, karşıma django-simple-sso çıktı. Kötü değildi aslında — iskelet fena sayılmazdı. Ama tasarımı tek sağlayıcıya göre yapılmıştı; bir tane kimlik kaynağı, bir tane ayar, dümdüz giden bir yapı. Bende ise tablo tam tersiydi: aynı müşteri için Azure AD ile Okta yan yana durabilmesi gerekiyor, email domain’e göre doğru sağlayıcı seçilmesi lazım, “admin mi manager mı?” sorusu da statik değil — IdP’den gelen role claim neyse ona göre şekillenmeliydi. Böyle olunca kütüphaneyi kullanmak yerine onu eğip bükmeye başladım.
Sonuç? Biraz karıştı.
Size bir şey söyleyeyim, 2023 yazında Ankara’daki kendi iç dashboard projemde aynı hataya düşmüştüm zaten; “hazır araç yetmezse ufak ekleme yaparım” demiştim, üç hafta sonra elimde ufak tefek hiçbir şey kalmamış, resmen yarı ürün ortaya çıkmıştı. Burada da tam o his geldi üstüme — hani o “yanlış yoldasın ama itiraf etmek istemiyorsun” hissi.
Neyi değiştirdim?
Kullanıcı-yönetici ilişkisini tek tek bağlayan model yapısını söküp çoktan-çoğa ilişkiye çevirdim. Auth akışı da bayağı değişti; kullanıcı email girince backend önce domain’i çözdü, sonra o domaine bağlı SSO ayarlarını çekti, uygun IdP’ye yönlendirdi. Yani giriş ekranı artık pasif bir form değildi — küçük bir trafik polisi gibiydi, tüm yükü üstlenmeden ama yine de kritik kararı vererek. Role mapping tarafına da ayrı katman koydum,. Rol eşlemesini her IdP’ye gömmeye kalkınca iş çabuk çuvallıyor; Azure’da grup adı başka oluyor, Okta’da claim formatı başka çıkıyor, legacy sistemde ise bambaşka tuhaflıklar var — evet, bazen gerçekten tuhaf.
Şimdi gelelim işin can alıcı noktasına.
Bunu yaşayan biri olarak söyleyeyim, Bu katman sayesinde mantığı merkezileştirdim. Ama bakım maliyeti sıfırlanmadı, açık konuşayım. Bu konuyla ilgili HTML Entity Araması: Üç Formu Tek Ekranda Yakal… yazımıza da göz atmanızı tavsiye ederim.
Kurcalayıp durduğunuz kütüphane sizi ilk etapta kurtarıyor gibi görünür; ama ihtiyaçlar tenant bazında dallanıp budaklanıyorsa çoğu zaman sorun çözülmüyor, sadece erteleniyor.
Sorun Büyüyünce Anladığım Şey
İlk sürüm üç hafta boyunca gerçekten iş gördü. Çoklu sağlayıcı destekledi, dinamik doğrulama yaptı, role sync çalıştı. Kağıt üstünde sağlamdı yani. Ama sonraki müşteri görüşmesinde gelen talep her şeyi yeniden sorgulamama yetti. Bu konuyla ilgili Crimson Desert’te Intel Desteği: Arc Sahneye Çıkıyor yazımıza da göz atmanızı tavsiye ederim.
“Yeni bir provider eklememiz lazım.”
Bir bakıma, size bir şey söyleyeyim, Tamam, dedim, hallederiz. Ama söz konusu olan öyle kolay test edilecek türden bir sistem değildi — eski tip kurumsal kimlik altyapısı, test erişimi almak bile başlı başına proje istiyordu. Lisans görüşmeleri, vendor koordinasyonu, e-postalar, toplantılar… zaman su gibi gidiyordu. İşte asıl mesele tam burada çıktı ortaya: ben hâlâ kendi anlayabildiğim sağlayıcılara bağımlıydım (en azından benim deneyimim böyle). Yeni gelen sistem için ya kod değiştirecektim ya da laboratuvar kurup günlerce test edecektim, ikisi de beni pek heveslendirmiyordu açıkçası. Müşterinin yol haritasında daha kaç IdP olduğunu düşününce bunun sürdürülebilir olmadığı netleşti. Daha fazla bilgi için HTTP Durum Kodları: 36 Kodu Tek Ekranda Topladım yazımıza bakabilirsiniz.
| Yaklaşım | Artısı | Eksiği |
|---|---|---|
| Django kütüphanesini zorlamak | Hızlı başlangıç | Kod bağımlılığı yüksek |
| Kendi SSO katmanını yazmak | Tam kontrol hissi verir | Bakıma boğabilir |
| Cognito merkezli mimari | Sağlayıcı eklemek kolaylaşır | AWS karmaşıklığı artar |
Neden AWS Cognito’ya Geçtim?
Açık konuşayım: bu kararın güzel tarafı romantik değildi, pratikti. AWS Cognito uygulamayla dış kimlik sağlayıcılarının arasına oturuyor ve aradaki tercümeyi üstleniyor — böyle düşünün. Siz Django tarafında sakin sakin duruyorsunuz, Cognito ise Azure AD’den de beslenebiliyor, Okta’dan da, Google’dan da, OIDC/SAML dünyasından da. Yani yeni oyuncu sahneye girdiğinde sistemin omurgasını yıkmanız gerekmiyor. Bu küçük bir fark değil, hani gerçekten değil.
Durun, bir saniye.
Bunu ilk kez büyükçe bir SaaS geçişinde test ettiğimde fark ettim (ilk duyduğumda inanamadım). Ekipteki bir arkadaş Eylül 2024’te Berlin ofisindeki demo sırasında bana döndü: “Bunu yeni tenant’a gerçekten elle kod atmadan bağladınız mı?” diye sordu. Evet, sordular. Cevap evetti ve yüzündeki rahatlama bayağı belirgindi — bu tür anlar insanı motive ediyor doğrusu.
Cognito neyi sadeleştiriyor?
- Dış IdP bağlantısını merkezi hale getiriyor.
- Kullanıcıyı uygulamaya tek biçimde sokuyor. — ciddi fark yaratıyor
- Token’ı ve federasyonu standartlaştırıyor.
- Pek çok durumda yeni provider eklemek için server koduna dokunma ihtiyacını ciddi ölçüde azaltıyor.
Tabi ki sihirli değnek değil bu. Cognito’nun kendisi de bazen sinir bozuyor — dokümantasyon her zaman pürüzsüz değil, bazı köşe durumlar kafa karıştırabiliyor, rol ve claim eşleşmesini düzgün tasarlamazsanız iş yine dağılıyor. Hmm, nasıl desem… araç iyi ama pişmemiş yerleri var. En çok da enterprise senaryoda sabırlı olmak şart, bunu atlamamak lazım.
Mimaride Asıl Kazanç Nerede?
Kazanç sadece teknik borcun azalması değilmiş — bunu sonradan anladım. En büyük kazanç operasyonel rahatlık oldu. Yeni müşteri geldiğinde “hangi provider?” sorusu artık kod değişikliği anlamına gelmiyor; çoğu zaman ayar açıp kapatıyorsunuz. Bitiyor. Küçük startup için bu hız altın değerindeyken enterprise tarafta asıl değer denetlenebilirlikte ortaya çıkıyor. Farklı ihtiyaçlar, farklı öncelikler — bunu şimdi çok daha iyi görüyorum.
E tabi her şey güllük gülistanlık değil. Organizasyonunuz çok sık özel claim dönüşümü istiyorsa veya uçtan uca audit beklentisi yüksekse bazı parçaları yine siz yönetmek zorunda kalıyorsunuz. Mesela grup senkronizasyonu hızlı olsun ama yanlış veri gelirse ne olacak? İşte tam orada ekstra doğrulama katmanı şart oluyor — kaçış yok.
Küçük ekip vs kurumsal ekip
# Basit bakış
Küçük startup:
- Az ayar
- Hızlı onboarding
- Daha az süreç
Enterprise:
- Ayrıntılı audit
- Tenant izolasyonu
- Rol eşleşmesinde sıkılık
- Güvenlik onayı
- Değişiklik yönetimi
Küçük ekipte hedef genelde “çalışsın yeter” olurken enterprise seviyede mesele “yarın biri gruptan çıkarılırsa erişim gerçekten kapanıyor mu?” sorusuna dayanıyor. Bu ayrımı atlayan projeler genelde ilk denetimde tökezliyor. Ben bunu iki farklı müşteride gördüm; biri hızlı geçti ama kontrolsüz kaldı, diğeri yavaş başladı ama sonradan çok daha temiz yürüdü. Hangisinin daha az baş ağrısı verdiğini tahmin etmek zor değil (ciddiyim) Afriex SDK ile Freelancer Ödeme Platformu: Next.js Rehberi yazımızda da bu konuya değinmiştik. GitHub Copilot mu Cursor mı? 2026’da Paranı Nereye Koymalı? yazımızda da bu konuya değinmiştik.
Derslerim: İdare Eden Çözümle Uzun Yol Gitmek Zorunda Değilsiniz!
Lafı gevelemeden söyleyeyim: hazır kütüphaneyle başlanır, hatta başlanmalı da — boş sayfa korkusu diye gerçek bir şey var ve bunu küçümsememek lazım. Ama ihtiyaçlar büyüdüğünde sırf alışkanlık yüzünden aynı yapıya tutunursanız maliyet artıyor. Ben burada önce direndim, sonra mecburen kabul ettim. Neyse uzatmayalım.
Cognito’ya geçince takımın nefesi açıldı. Yeni provider entegrasyonu için server code churn azaldı, rollout süresi kısaldı, tenant izolasyonu daha anlaşılır hale geldi. En önemlisi de ekip artık her yeni istek duyduğunda panikle “bunu nasıl yetiştiririz?” demedi — çünkü temel çatı daha sağlamdı (ki bu çoğu kişinin gözünden kaçıyor). Küçük ama ciddi fark.
Nerede dikkat etmek gerekir?
- Cognito kurulumu basit sanmayın; IAM ve policy tarafını düzgün planlayın.
- Email domain ile provider eşlemesini edge case’lerle test edin.
- Rol senkronizasyonunda gecikme toleransınızı baştan belirleyin.
- Ayrık tenant verisini loglarda bile karıştırmayın — bu önemli, gerçekten.
- Migrasyonda eski oturumların nasıl biteceğini netleştirin.
💡 Bilgi: Enterprise SSO projelerinde en pahalı hata çoğu zaman kimlik doğrulama değildir; yanlış tenant’a yanlış rol vermektir.
Bu yüzden geçiş öncesi küçük veri setleriyle birkaç kuru test yapmak çoğu vakada hayat kurtarır.
Benden Kalan Pratik Notlar
Bu yüzden geçiş öncesi küçük veri setleriyle birkaç kuru test yapmak çoğu vakada hayat kurtarır.
Bak şimdi, Eğer bugün aynı işi yeniden yapsam önce şunu yapardım: provider listesini teknik ihtiyaç listesine göre sınıflandırırım, sonra hangi kısmın gerçekten server code istediğine bakarım. Çünkü bazen problem sandığınız kadar büyük değildir — dur bir saniye — bazen de tam tersi, küçücük görünen detay devasa entegrasyon yüküne dönüşür. İnsan onu ancak masanın üstüne dökünce görüyor, başka türlü görmek mümkün değil pek.
Bi saniye — Bir arkadaşım Kasım 2024’te Amsterdam’daki fintech projesinde benzer geçiş yaptı. AWS Cognito’ya geçince destek taleplerinin ciddi bir kısmını azalttığını anlattı — rakam vermeyeyim ama yaklaşık üç ay sonra operasyon ekibi belirgin şekilde rahatlamıştı. Ben bu tür hikayelere hemen inanmam aslında, şüphecilik mesleğin gereği biraz (ki bu çoğu kişinin gözünden kaçıyor). Ama sahada defalarca benzer sonuç görünce insan fikrini değiştiriyor işte (en azından benim deneyimim böyle). Maalesef öyle.
Son cümlem şu: SSO’yu sadece login problemi olarak görürseniz proje sizi şaşırtır. Ama onu kimlik yaşam döngüsü, — itiraz edebilirsiniz tabi — rol yönetimi ve tenant izolasyonu olarak ele alırsanız işler toparlanıyor. Kağıt üstünde basit duran şeylerin pratikte niye can yakabildiğini böyle projeler güzel gösteriyor — bunu yaşamadan tam anlamak zor.
Sıkça Sorulan Sorular
AWS Cognito kurumsal SSO için uygun mu？
Evet,özellikle çoklu kimlik sağlayıcısı olan yapılarda bayağı işe yarıyor. Ancak kullanım senaryosu karmaşıksa kurulumu hafife almamak lazım; IAM,claim mapping ve tenant ayrımı iyi planlanmalı.
Django uygulamasında SSO için neden doğrudan kütüphane yetmeyebilir？
Daha basit senaryolarda yetebilir.tenant bazlı çoklu IdP,otomatik rol eşleme ve sık değişen müşteri taleplerinde kütüphane sınırı çabuk görünür hale gelir.
Cognito ile yeni identity provider eklemek zor mu？
Pek değil,doğru mimari kurulursa çoğu durumda konfigürasyonla halledilir. Yine de legacy sistemlerde test erişimi almak zor olabilir; esas uğraş bazen teknikten çok süreçtedir.
Kullanıcı grup değişiklikleri uygulamaya ne kadar hızlı yansır？
Büyük ölçüde token yenileme stratejinize bağlıdır. Dakikalara indirebilirsiniz ama cache,session ömrü ve sync mekanizmasını doğru tasarlamanız gerekir.
Kaynaklar ve İleri Okuma
AWS Cognito Resmi Dokümantasyonu
Cognito User Pools Federation Rehberi
Django GitHub Sayfası
django-simple-sso GitHub Sayfası
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
