Bakın şimdi, WordPress tarafında SSO konuşunca iş genelde “tek giriş, her yerde geçerli olsun” hayaline gidiyor (inanın bana). Kağıt üstünde çok temiz duruyor. Gerçekte ise ayrı domain’ler devreye girince tablo biraz dağılıyor; çerezler, yönlendirmeler, token süreleri, logout senkronu derken konu bir anda basit görünmekten çıkıyor. Geçen yıl Kasım 2025’te İstanbul’da bir e-ticaret müşterisiyle çalışırken bunu birebir yaşadım: ana site ayrı, blog ayrı, destek portalı ayrıydı ve kullanıcılar sürekli “Neden tekrar giriş yapıyorum?” diye yazıyordu. İşin aslı şu ki, bu soru sadece UX meselesi değil; güvenlik ve operasyon meselesi de.
Ben bu tür yapılarda en çok şuna takılıyorum: İnsanlar önce plugin arıyor, sonra mimariyi düşünmeye başlıyor. Yanlış sıra. Önce kim otorite olacak, sonra hangi veri nerede tutulacak, en son araç seçilecek — bu kadar basit aslında, ama pratikte neredeyse kimse böyle yapmıyor. Aksi halde elinizde şık görünen ama içi dağınık bir sistem kalıyor. Neyse uzatmayayım; aşağıda ayrıntıya gireceğim ama kısa cevap şu: Ayrı domain’lerde sağlam SSO için merkezî kimlik yönetimi şart.
Neden tek bir ana site kurmak gerekiyor?
Ayrı WordPress kurulumlarıyla büyüyen ekiplerin ilk yaptığı hata şu oluyor: Her site kendi kendine kullanıcı kabul ediyor. Başta sorun yok gibi görünüyor… ta ki müşteri sayısı artana kadar. Bir kullanıcının üç farklı sitede üç farklı hesabı olunca destek ekibi de yoruluyor, kullanıcı da sıkılıyor. Hani market kartınız var ama her şubede yeniden kayıt istiyorlar — kim uğraşacak bununla?
Şimdi gelelim işin can alıcı noktasına.
Bakın, Benim 2024 yazında Ankara’daki bir SaaS denemesinde gördüğüm şey tam buydu. Ana ürün sitesi ile eğitim portalı ayrıydı ve ekip “sonradan bağlarız” demişti. Sonra işler karıştı; profil güncellemesi bir sitede yapılıyor, diğerinde eski bilgi kalıyor, rol değişikliği gecikiyor (bizzat test ettim). Açık konuşayım, bu küçük detaylar büyüdükçe bayağı can sıkıcı oluyor. Küçük görünüyor, ama büyüdükçe operasyonun tam ortasına düşüyor.
Burada en mantıklı model tek bir master authentication site belirlemek. Kimliğin kaynağı orası. Diğer siteler de oradan doğrulama isteyecek (yanlış duymadınız). Mantıklı değil mi? Bu yapı hem hesap karmaşasını azaltıyor hem de loglama ve erişim kontrolünü bir arada tutuyor.
| Yaklaşım | Artısı | Eksiği |
|---|---|---|
| Her sitede ayrı login | Kurması kolay gibi görünür | Kullanıcı deneyimi kötüleşir, hesap çoğalır |
| Merkezî ana site | Düzenli kimlik yönetimi sağlar | İlk kurulumda mimari dikkat ister |
| Dağıtık ama senkronlu yapı | Büyümeye uygun olabilir | Senkron hataları can sıkabilir |
Token tabanlı akış neden çerezden daha iyi?
Ayrı domain’lerde oturum taşımak için token tabanlı yaklaşım bence hâlâ en temiz yol. Neden? Çünkü tarayıcı güvenlik modeli sizi zaten sınırlandırıyor; Same-Origin Policy boşuna konmadı sonuçta (buna dikkat edin). Burada amaç çerezi zorla paylaşmaya çalışmak değil, kısa ömürlü ve imzalı bir doğrulama parçası üretmek.
Kendi test ortamımda bunu ilk kez Haziran 2023’te denediğimde şaşırmıştım açıkçası: Kullanıcı ana sitede giriş yapınca alt siteler sessizce token çekebiliyor ve yerel oturum açabiliyordu — yani kullanıcıya tekrar tekrar giriş ekranı göstermek yerine arkada işleyen, neredeyse görünmez bir akış kuruluyordu. Tabi burada kilit nokta süreyi kısa tutmak; token uzun yaşarsa güvenlik riski artar, bu kısmı atlamayın (ben de ilk duyduğumda şaşırmıştım)
Sessiz doğrulama, kullanıcının fark etmediği geçiş demek olabilir ama genelde yeterli değil. Bazen açık yönlendirme daha iyi olur — mesela finansal işlemler yapan ya da hassas içerik sunan sitelerde kullanıcıya net şekilde “ana sisteme yönlendiriliyorsun” demek daha sağlıklı duruyor.
Sessiz akış mı açık akış mı?
Bakın, Sessiz akış güzel şey. Ama her projede cuk diye oturmuyor. Küçük bir startup için gayet pratik olabilir; kullanıcı azdır, edge case sayısı düşüktür ve hız önemli.
Enterprise seviyede işler değişiyor tabii: Denetim izi lazım olur, compliance ekibi sorar, güvenlik onayı ister, hukuk departmanı devreye girer… Orada bazen birkaç ekstra adım koymak gerekebilir. Yavaşlatıyor mu? Evet, biraz. Ama seçenek yok. HTTP’yi Yanlış Okuyoruz: Hız Sırrı Sandığınız Gibi Değil yazımızda bu konuya da değinmiştik.
// Basit akış örneği
1) Kullanıcı sub-site'a gelir
2) Sub-site master auth endpoint'ine kısa ömürlü token ister
3) Master site kimliği doğrular
4) İmzalı token döner
5) Sub-site local session oluşturur
6) Token süresi dolunca yeniden doğrulama yapılır
7) Logout olduğunda tüm sitelere bildirim gider
Ayrı domain’de çalışan WordPress sitelerinde asıl mesele giriş ekranını güzel yapmak değil; oturumu doğru taşımak ve çıkışı eksiksiz kapatmaktır.
Kullanıcı ve rol senkronu neden ihmal edilmemeli?
Burası genelde sonradan düşünülen kısım oluyor. Bence en kritik parçalardan biri bu — ama insanlar login çalışınca “tamam bitti” deyip geçiyor. Kullanıcı ana sitede oluşup alt sitede yoksa SSO ne kadar düzgün olursa olsun ilk temas anında tökezliyorsunuz. Hatta geçen mart ayında İzmir’de konuştuğum bir ajans ekibi tam da bundan şikâyet ediyordu: Giriş var (ben de ilk duyduğumda şaşırmıştım). Rol eşleşmesi olmadığı için forum alanına erişim verilemiyormuş. Küçük şey gibi görünüyor değil mi? Ama kullanıcı açısından bakınca sinir bozucu.
Kullanıcı senkronu dediğimiz şey sadece yeni hesap açmak değil; profil güncellemesi, parola değişikliği ve rol dönüşümlerini de kapsamalı (inanın bana). Siz hiç denediniz mi? Mesela mağaza müşterisini forumda abonelik rolüne çevirmek istiyorsanız bunu manuel yapmak saçma derecede yorucu olurdu. MCP’de Asıl Dönüşüm: Stdio’dan HTTP’ye Geçiş yazımızda bu konuya da değinmiştik.
- Kayıt oluştuğu an: Kullanıcı diğer sistemlere yayılır.
- Profil güncellendiğinde: Ad-soyad, e-posta gibi bilgiler eşitlenir.
- Rol değiştiğinde: Yetki haritası otomatik güncellenir.
- Password reset olduğunda: Tüm bağlı sistemlere bilgi gider.
- User disable edildiğinde: Erişimler zincirleme kapatılır.
Bilmem anlatabiliyor muyum, Açık konuşayım, rol eşlemesi kısmında “her şeyi birebir taşıyalım” yaklaşımı çoğu zaman yanlış olur. Bir blog okuyucusu ile premium (söylemesi ayıp) müşteri aynı yetkiye sahip olmaz ki zaten… O yüzden mapping katmanı şart; yani kaynak rolden hedef role çevrim yapan ince bir köprü gibi düşünün bunu. Daha fazla bilgi için iPad ve iMac’i Oyun Ekranına Çeviren Küçük Hile yazımıza bakabilirsiniz.
Eklenti mi özel çözüm mü? Kararı nasıl vermeli?
NEXU WP gibi araçlar burada hayat kurtarabiliyor çünkü setup işini bayağı hafifletiyorlar: master-sub bağlantıları, token yönetimi ve gözlemleme panelleri tek yerde toplanıyor. Ama ben yine de şunu söylüyorum — önce ihtiyaç analizi yapın, sonra araç alın. Araç seçimi mimarinin önüne geçerse sonra pahalıya mal oluyor. Kurulum mu Dağıtım mı? Yeni Başlayanların Sıkıştığı Nokta yazımızda da bu konuya değinmiştik. AOC Agon Pro’nun Yeni OLED Canavarı: Fiyatı Belli Oldu yazımızda da bu konuya değinmiştik.
İşte tam da bu noktada devreye giriyor.
Bir startup hızlıca ayağa kalkmak istiyorsa hazır eklenti mantıklı olabilir. Ama yüksek regülasyonlu kurumlarda özel geliştirme ya da hibrit çözüm daha doğru durur. Kısacası araç değil mimari kazanır.
Şunu fark ettim: Bir de şu var: Eğer çok sayıda bağımsız sub-site yönetiyorsanız log takibi olmadan yürümek kumar oynamaya benzer. Kim ne zaman giriş yaptı? Hangi token reddedildi? Logout gerçekten tüm sisteme gitti mi? Bu soruların cevabı yoksa sorun çıkar — ve çıktığında da nerede çıktığını bulmak çok zorlaşır.
Ha bu arada, benim deneyimimde dashboard’u olan sistemler ekip içi tartışmayı da azaltıyor (inanın bana). “Bende çalıştı” / “bende bozuk” kavgasından çok hızlı kurtarıyor insanları.
Neye göre karar vermelisiniz?
- Eğer trafik düşükse hazır eklenti yeterli olabilir.
- Eğer veri hassassa merkezi kontrol öncelikli olmalı.
- Eğer çok marka varsa domain stratejisi baştan çizilmeli.
- Eğer destek yükü fazlaysa logout ve sync izlenmeli.
Logout senkronu niye genelde sonradan hatırlanıyor?
Aslında, Dürüst olayım mı? Çoğu ekip login’i çözdüğünde rahatlıyor. Ama asıl problem logout tarafında çıkıyor (bizzat test ettim). Kullanıcı bir yerden çıkış yapıp başka sekmede hâlâ oturumunun açık kaldığını görünce güven kırılıyor —. Bir kez kırıldı mı, toparlamak zor.
Ben bunu Ekim 2024’te Berlin’de küçük bir ürün demo’sunda canlı gördüm; satış ekibi “tamamdır” dedi ama ben ikinci sekmede hâlâ hesabın açık olduğunu fark ettim. Ufak görünüyor belki. Ama büyük işlerde bu tür delikler itibar yorar — hem de fark edilmeden, sessiz sedasız.
“Logout all sessions” mantığı burada önemli. Çıkışı sadece lokal siteden silmek yetmez; master site’ye haber verip bağlı alt siteleri de kapatmanız gerekir (inanın bana). Neden önemli bu? Bunu düzgün yapan sistemlerde kullanıcı deneyimi toparlanıyor, destek talepleri azalıyor, güven hissi artıyor.
Peki gerçek hayatta nasıl kurulur?
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.
