Kimlik doğrulama özel alan adı nedir ve neden birden fazla alan adı önemlidir
Kimlik doğrulama için özel alan adlarının ve birden fazla alan adının dönüşüm, güvenlik ve marka kimliğini nasıl geliştirdiğini öğrenin; ayrıca Logto'nun bunları DNS sorunları olmadan nasıl yönetmenizi sağladığını keşfedin.
Eğer bir ürünü biraz fazla hızlı bir şekilde yayına aldıysan, bu hikaye sana tanıdık gelecek.
Uygulaman başı rahat şekilde example.com adresinde çalışıyor. Pazarlama kampanyalar yürütüyor, kullanıcılar kayıt oluyor, her şey çok şık görünüyor. Sonra yeni bir kullanıcı Giriş yap butonuna tıklıyor.
Tanıdık bir URL olan auth.example.com yerine, tarayıcı bir test ortamına benzeyen bir yere atlıyor: my-tenant-123.app.logto
Teknik olarak hiçbir sıkıntı yok. Sayfa güvende. Giriş hala çalışıyor.
Ama kullanıcının ilk tepkisi şu oluyor:
“Bekle, az önce nereye gittim?”
İşte o bir saniyelik şüphe anı, kayıpların yaşandığı yer.
Dönüşüm açısından, giriş ve kayıt işlemleri huni'nin en dar kısmı. Her ekstra "Bu alan adı ne?" anı, sürtünme yaratır.
Güvenlik açısından, kullanıcılara yıllardır "URL'yi kontrol et" deniyor. Eğer giriş alan adı markanla uyuşmazsa, üretime kıyasla daha çok oltalama gibi görünür.
Neredeyse her büyük şirketin bir şekilde kullandığı şu örneklerin bir sebebi var:
login.company.com
auth.company.com
accounts.company.com
Bunu eğlencesine yapmıyorlar. Login alan adı ürün deneyiminin bir parçası olduğu için yapıyorlar.
Bu yazıda şunlara bakacağız:
Kimlik doğrulama özel alan adı gerçekte nedir
Tek bir giriş alan adının ne zaman yeterli olduğu — ve ne zaman birden fazla planlaman gerektiği
Giriş alan adlarında en sık yapılan hatalar (ve "redirect URI does not match" cehenneminden nasıl kaçınacağın)
Logto’nun özel alan adı desteğinin sana bunların hepsini tam zamanlı bir DNS mühendisi olmadan nasıl yapabileceğini sağlaması
Her Logto tenant'ı bir varsayılan alan adıyla birlikte gelir: {{tenant-id}}.app.logto. Yani kullanıcıların gönderildiği an: https://my-tenant-123.app.logto/sign-in.
Bir kimlik doğrulama özel alan adı, o görünen URL'yi sana ait olanla değiştirir—mesela auth.example.com. Böylece kullanıcılar marka içinde kalır: https://auth.example.com/sign-in.
Alttaki kimlik doğrulama servisi aynı. Ama ilk izlenim bambaşka.
Logto'da özel alan adları, alt alan adları olarak çalışacak şekilde tasarlanmıştır, örneğin:
auth.example.com
auth.us.example.com
Pratikte, kimlik doğrulama için istenen de budur:
Kök alan adları genellikle ana siten için ayrılmıştır (example.com).
DNS “zone apex” bir CNAME kullanamaz ve Logto’nun barındırılan giriş sayfası trafiğin yönlendirilmesi için bir CNAME’i domains.logto.app'e ister.
Logto sertifikaları Cloudflare üzerinden yönetir. Kök bir alan adında TLS sonlandırmak için o tüm zone üzerinde (mevcut A, MX, TXT, vs. dahil) kontrolümüz olması gerekir, bu da çok-kiracılı SaaS için uygun değildir.
Apex-flattening kayıtları (ALIAS/ANAME) yine de sahip olmadığımız IP’lere çözümler; bu yüzden yönetilen sertifikalarımız için kullanılamazlar. Kısacası, barındırılan giriş sayfası bir alt alan adı üzerinde olmalıdır. O alt alan adını bir CNAME ile Logto’ya yönlendir, doğrulama, SSL ve çalışma süresiyle ilgileniriz—kök alan adın sitenin geri kalanına hizmet etmeye devam eder.
“DNS'ime bir CNAME ekleyeyim, işim bitti, değil mi?”
Maalesef, hayır.
Görünen giriş alan adını değiştirmek hikayenin yalnızca bir kısmı. Bir özel kimlik doğrulama alan adı eklediğinde şu konulara da dokunmuş olursun:
Giriş ve kayıt sayfası URL'si
Kullanıcılar artık barındırılan sayfalar için https://auth.example.com/... adresini ziyaret ediyor.
OIDC / OAuth yönlendirme URI'ları
Uygulamalar ve bağlayıcıların yönlendirme/geri arama URL'lerinde aynı alan adını kullanması gerekir, yoksa redirect_uri_mismatch gibi hatalar alırsın.
Sosyal girişler & kurumsal SSO (IdP’ler)
Google, GitHub, Azure AD, Okta, vs. yönlendirme URI’sini veya ACS URL’sini (alan adını da içeren) doğrular.
Parola anahtarları (WebAuthn)
Parola anahtarları kaydedildikleri tam alan adına bağlıdır. Alan adını değiştirirsen, o anahtarlar artık çalışmaz.
SDK yapılandırması
Logto SDK’ların, tenant alan adını gösteren bir endpoint kullanır. Endpoint yanlış alan adını kullanıyorsa, uygulaman ve kimlik katmanında kopukluk olur.
Peki, işin içinde DNS var mı? Kesinlikle.
Ama sadece “Bir CNAME ekledim, işim bitti” diye düşünüyorsan, neredeyse kesinlikle başka bir şeyi bozarsın.
Hızlı bir zihinsel model: giriş alan adı stack’te nasıl akar#
Hayalinde bir diyagram düşün: Kullanıcının tarayıcısı şuradan başlar:
Tarayıcı adres çubuğu
Kullanıcı https://example.com adresinde Giriş yap’a tıklar.
Bu, uygulamana kimlik doğrulama isteklerinin nereye gönderileceğini ve token'ların nerelerde beklenmesi gerektiğini söyler.
Yönlendirme URI’ları (OIDC/OAuth callback’leri)
Kullanıcı giriş yaptıktan sonra Logto, uygulamana şöyle bir adrese yönlendirir: https://app.example.com/callback
Hem IdP hem uygulaman bu URL’ler üzerinde anlaşmalı.
Sosyal giriş / kurumsal SSO sıçramaları
auth.example.com’dan kullanıcı Google, Microsoft Entra ID, Okta vs.’ye geçebilir.
Bu sağlayıcılar da özel kimlik doğrulama alan adını içeren yönlendirme URI’larını görüp doğrular.
E-postalar ve sihirli linkler / şifre sıfırlama linkleri
E-postadaki linkler kafa karışıklığını önlemek için daima özel alan adına işaret etmelidir.
Bu adımlardan her birinde, alan adının önemi vardır. Özel bir giriş alan adı eklediğinde, o alan adının tüm zincirde tutarlı biçimde akmasını istersin.
İşte bu nedenle iyi düşünülmüş bir özel alan adı stratejisi DNS hilelerinden çok bütünlüklü bir kimlik tasarımı meselesidir.
Birçok ekip için, auth.example.com gibi tek bir özel alan adı gayet yeterlidir. Ama ürünün, coğrafyan ve müşteri tabanın büyüdükçe, önden planlamazsan hızla sınırlarına takılırsın.
Farklı ekipler genellikle alan adlarını kimlik doğrulama deneyimlerine şu şekilde eşler:
Senaryo
Örnek alan adları
Ne işe yarar
Tek markalı giriş
auth.example.com, account.example.com
Adres çubuğunu markada tutar, varsayılan {{tenant-id}}.app.logto ise test için kullanılabilir.
DNS veya PKI uzmanına dönüşmeden Logto’nun sana doğrudan sunduğu şeyler:
Bir tenant, birden çok alan adı. Bölgeleri, ortamları, müşterileri veya markaları kendi giriş alan adlarına yönlendir; tenant çoğaltmaya gerek yok. Plan limitleri geçerli olsa da temel prensip değişmez: tek bir kimlik omurgası, birçok giriş noktası.
Varsayılan aktif kalır.auth.example.com eklesen de, {{tenant-id}}.app.logto devre dışı kalmaz. Varsayılanı dahili araçlarda veya kademeli geçişlerde kullan, üretim kullanıcıları ise markalı alan adıyla giriş yapar.
Bağlayıcılar otomatik uyarlanır. SDK’lar doğru endpoint’a yönelir, sosyal ve SSO bağlayıcıları her alan adı için geçerli tüm yönlendirme URI’larını ya da ACS URL’lerini listeler—manuel URL uğraşmaktan kurtulursun.
Otomatik SSL. CNAME ekledikten sonra, Logto DNS’i doğrular, sertifikaları oluşturur ve yeniler. Anahtar yönetimi yok, sürpriz bitiş tarihleri yok.
Hemen şimdi birden fazla özel alan adını test etmeye başlayabilirsin:
Konsol > Ayarlar > Alan Adları adresine git. Yakında açacağın yeni bir bölge için veya markalı giriş isteyen önemli bir kurumsal müşteri için ikinci bir özel alan adı ekle, vs.
Gerekli yerlerde SDK endpoint’ını güncelle.
Sosyal ya da SSO bağlayıcılarında Logto’nun sunduğu, alan adı hassas yönlendirme URI’larını ve ACS URL’lerini kimlik sağlayıcına ekle.
Giriş deneyimini sadeleştirmenin ve kullanıcı güveni ile dönüşüm üzerindeki etkisini ölçmenin kolay yolu.
Konsol > Ayarlar > Alan Adları adresine git. Ücretsiz özel alan adı hakkını kullanarak ilk günden auth.example.com’u herkese açık giriş alan adın yap.
Varsayılan {{tenant-id}}.app.logto alan adını iç kullanım veya test için elinin altında tut.
Böylece baştan “burası sanki staging gibi” giriş URL’si sorunundan kurtulmuş olursun ve ileride büyüme aşamasındayken alan adı göçüyle boğuşmak zorunda kalmazsın.
Adım adım kurulum detayları, DNS kayıtları ve sorun giderme dahil mi istiyorsun?
Dökümanlarımızda tam rehbere göz atabilirsin: Özel alan adları Logto Cloud için.
