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.
Product & Design
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.comauth.company.comaccounts.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ı
Kimlik doğrulama özel alan adı nedir?
Basit tutalım.
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.
Neden alt alan adı, kök alan adı değil?
Logto'da özel alan adları, alt alan adları olarak çalışacak şekilde tasarlanmıştır, örneğin:
auth.example.comauth.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.
Neden “sadece CNAME ekle ve bitti” değil?
Çok yaygın bir yanlış anlama:
“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çinhttps://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, yoksaredirect_uri_mismatchgibi 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 birendpointkullanı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.comadresinde Giriş yap’a tıklar. https://auth.example.com/sign-inadresine yönlendirilir.
- Kullanıcı
- Yetkilendirme sunucusu & keşif dökümanı
- Uygulaman OpenID yapılandırma endpoint’ini kullanır:
https://auth.example.com/oidc/.well-known/openid-configuration - Bu, uygulamana kimlik doğrulama isteklerinin nereye gönderileceğini ve token'ların nerelerde beklenmesi gerektiğini söyler.
- Uygulaman OpenID yapılandırma endpoint’ini kullanır:
- 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ı.
- Kullanıcı giriş yaptıktan sonra Logto, uygulamana şöyle bir adrese yönlendirir:
- 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.
Tekli vs. çoklu özel alan adı
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. |
| Bölgesel deneyimler | auth.us.example.com, auth.eu.example.com, auth.apac.example.com | İçerik, onay akışları ve uyumluluk uyarılarını coğrafya bazında tek tenant içinde özelleştir. |
| Ortam güvenlik duvarları | auth.staging.example.com, auth.example.com | Her tenant veya bağlantıyı çoğaltmadan QA ve önizleme trafiğini yalıt. |
| Kuruluş başına markalama | auth.customer-a.com, auth.customer-b.com | Kurumsal müşterilere beyaz etiketli giriş noktası sunarken, kullanıcıları, kuruluşları ve SSO’yu merkezi yönet. |
| Marka veya ürün hatları | auth.shop.example.com, auth.app.example.com, auth.studio.example.com | Her markaya bütünlüklü bir giriş deneyimi sun; kimlik altyapını bölmeden. |
| Birden fazla TLD | auth.foo.com, auth.foo.co.uk, auth.foo.dev | Ülke sitelerini veya amaç odaklı alan adlarını konfigürasyonu bölge bölge kopyalamadan destekle. |
| Altyapı odaklı | auth.edge.example.com, auth.api.example.com | CDN veya edge yönlendirme kurallarıyla örtüş; Logto ise bu hostların arkasında kalan kimlik altyapısı olur. |
Logto’nun özel alan adlarını kolaylaştırması
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.comeklesen de,{{tenant-id}}.app.logtodevre 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.
Buradan sonra ne yapmalı
Buraya kadar okuduysan, muhtemelen iki gruptan birindesin.
Halihazırda Logto kullanıyor musun?
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.
Logto’da yeni misin?
Daha yeni başlıyorsan:
- Logto için kaydol ve bir tenant oluştur.
- 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.logtoalan 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.