WebAuthn İlişkili Kaynaklar: Alan Adları Arası Passkey Rehberi

Passkey'ler, güvenli ve kullanıcı dostu kimlik doğrulama için yeni standarttır. FIDO/WebAuthn standartları üzerine inşa edilen bu anahtarlar, açık anahtar kriptografisinden yararlanarak phishing ve kimlik bilgisi doldurma saldırılarına karşı doğal bir direnç sunar, güvenlik duruşunu önemli ölçüde iyileştirirken kullanıcılar için giriş deneyimini basitleştirir. Kurumlar için bu durum, somut iş faydalarına dönüşür: şifre sıfırlama ve SMS OTP'lerinden kaynaklanan operasyonel maliyetlerin azalması, hesap ele geçirme sahtekarlığından kaynaklanan finansal risklerin hafifletilmesi ve daha yüksek dönüşüm oranları sayesinde artan gelir.

Ancak, WebAuthn'in en büyük güvenlik güçlerinden biri olan katı, kaynağa bağlı doğası, küresel markalar ve çeşitli dijital ayak izlerine sahip şirketler için önemli bir gerçek dünya zorluğu yaratır. Tasarım gereği, belirli bir web alanı için oluşturulan bir passkey, o alana kriptografik olarak kilitlenir. Bu, phishing saldırılarını önleyen temel bir prensiptir. Bu güçlü bir güvenlik özelliği olsa da, tek bir markanın birden fazla alan adında faaliyet göstermesi durumunda parçalanmış ve kafa karıştırıcı bir kullanıcı deneyimine yol açar.

Bu zorluğun önde gelen bir örneği, Twitter'ın X olarak yeniden markalaşmasıdır. twitter.com'da bir passkey oluşturan bir kullanıcı, bunu x.com'da kullanamayacağını fark eder. Bu durum, şirketi hantal yönlendirmeler uygulamaya veya kullanıcılardan yeniden kaydolmalarını istemeye zorlayarak, benimsemeyi doğrudan engelleyen bir sürtünme yaratır. Bu, münferit bir sorun değildir. Amazon gibi büyük işletmeler, amazon.com, amazon.de ve amazon.co.uk gibi çok sayıda ülke kodu üst düzey alan adında (ccTLD) faaliyet gösterir ve hepsi ortak bir kullanıcı hesabı sistemini paylaşır. Passkey öncesi dünyada, şifre yöneticileri bu karmaşıklığı ustaca ele alırken, WebAuthn'in varsayılan davranışı her alan için ayrı bir passkey gerektirerek kullanıcıları hayal kırıklığına uğratır ve kesintisiz bir giriş vaadini baltalar.

Bu kritik benimseme engelini çözmek için W3C, WebAuthn standardında yeni bir özellik sundu: İlişkili Kaynak Talepleri (Related Origin Requests - ROR). Bu güçlü mekanizma, güvenilir bir alan adı setinin tek bir passkey'i paylaşması için standartlaştırılmış, güvenli bir yol sunarak bir markanın tüm dijital ekosisteminde birleşik ve kesintisiz bir kimlik doğrulama deneyimi yaratır. Bu derinlemesine inceleme, ROR'un teknik temellerini araştırıyor, uygulanması için pratik bir rehber sunuyor ve modern kimlik doğrulama mimarisi için stratejik sonuçlarını analiz ediyor.

ROR'un tanıtımı, WebAuthn standardının önemli bir olgunlaşma sürecini işaret ediyor. İlk şartnameler, temel kriptografik ve güvenlik ilkelerinin oluşturulmasına öncelik vermişti. Bir kimlik bilgisinin bir Relying Party ID'sine (rpID) sıkı bir şekilde bağlanması, anti-phishing tasarımının temel taşıydı. Amazon ve Google gibi şirketlerin büyük ölçekli kurumsal dağıtımları gerçeğe dönüştükçe, bu katılığın neden olduğu pratik sürtünme belirgin hale geldi. Bu sürtünme, herhangi bir passkey projesinin nihai başarı ölçüsü olan yüksek kullanıcı benimsemesine ulaşmanın önünde doğrudan bir engeldir. ROR'un geliştirilmesi, bu kurumsal geri bildirime doğrudan bir yanıttır ve standardın pragmatik bir evrimini göstermektedir. Bir güvenlik protokolünün yaygın başarıya ulaşması için, kullanılabilirliğinin, onu dağıtan kuruluşların karmaşık iş gerçeklerini ve markalaşma stratejilerini karşılayacak şekilde ölçeklenmesi gerektiğini kabul eder.

Bu kapsamlı rehber, WebAuthn İlişkili Kaynak Talepleri'ni uygulamak için beş kritik soruyu yanıtlıyor:

1. Passkey'ler neden birden fazla alan adında başarısız oluyor? WebAuthn'in kaynağa bağlı güvenlik modelini ve gerçek dünyadaki sürtünme noktalarını anlamak
2. İlişkili Kaynak Talepleri teknik olarak nasıl çalışır? Tarayıcı doğrulama akışına ve .well-known URI mekanizmasına derinlemesine bir bakış
3. ROR'u uygulamak için ne gerekir? Pratik kod örnekleriyle adım adım sunucu ve istemci tarafı yapılandırması
4. Ne zaman ROR'u birleşik girişe tercih etmelisiniz? ROR'u OIDC/SAML yaklaşımlarıyla karşılaştıran stratejik karar çerçevesi
5. Tarayıcı uyumluluğunu ve güvenlik konularını nasıl ele alırsınız? Mevcut destek matrisi ve en iyi güvenlik uygulamaları

Daha fazla teknik ayrıntı için, resmi WebAuthn İlişkili Kaynak Talepleri Açıklayıcısı'na bakın.

İlişkili Kaynak Talepleri çözümünün zarafetini tam olarak takdir etmek için, öncelikle onun varlığını gerektiren temel teknik kavramları anlamak esastır: web'in Aynı-Kaynak Politikası ve WebAuthn'in Relying Party ID (rpID) kapsam kuralları. Bu mekanizmalar web güvenliğinin temelini oluşturur, ancak ROR'un hafifletmek için tasarlandığı sürtünmeyi de yaratır.

Bir web "kaynağı", içeriğin sunulduğu protokol (örneğin, https), alan adı (örneğin, app.example.com) ve portun (örneğin, 443) benzersiz kombinasyonuyla tanımlanan kritik bir güvenlik kavramıdır. Aynı-Kaynak Politikası, bir kaynaktan yüklenen bir betiğin başka bir kaynaktan bir kaynakla nasıl etkileşime girebileceğini kısıtlayan, tarayıcılar tarafından uygulanan bir güvenlik mekanizmasıdır. Web güvenliğinin önemli bir unsurudur, potansiyel olarak kötü amaçlı belgeleri etkili bir şekilde izole eder ve örneğin sahte bir web sitesinin, bir kullanıcının başka bir sekmedeki kimliği doğrulanmış web postası oturumundan hassas verileri okumasını önler.

WebAuthn ekosisteminde, "Relying Party" (RP), bir kullanıcının kimliğini doğrulamaya çalıştığı web sitesi veya uygulamadır. Her passkey, oluşturulduğu anda kriptografik olarak bir Relying Party ID (rpID)'ye bağlanır. rpID, o kimlik bilgisinin kapsamını ve sınırını tanımlayan bir alan adıdır.

Varsayılan olarak, rpID, passkey'in oluşturulduğu kaynağın etkin alan adıdır. WebAuthn'in kapsam kuralları, bir kaynağın kendi alan adına eşit veya kaydedilebilir bir alan adı soneki olan bir rpID ayarlamasına izin verir. Örneğin, https://www.accounts.example.co.uk üzerinde çalışan bir betik, aşağıdaki rpID'lerden biriyle bir passkey oluşturabilir:

• www.accounts.example.co.uk (tam alan adı)
• accounts.example.co.uk
• example.co.uk

Bu esneklik, bir alt alanda oluşturulan bir passkey'in aynı ana alanın diğer alt alanlarında kullanılmasına olanak tanır, ki bu yaygın ve gerekli bir modeldir. Ancak kurallar, bir sonek olmayan bir rpID ayarlanmasını kesinlikle yasaklar. www.accounts.example.co.uk üzerindeki aynı betik, example.com rpID'si ile bir passkey oluşturamazdı, çünkü .com farklı bir üst düzey alan adıdır.

Bu katı bağlama, önemli bir amaca hizmet eder: kimlik bilgilerini alan adı kapsamına göre ayırmak. mybank.com için oluşturulan bir passkey, phishing-site.com üzerinde kullanılamaz çünkü kötü amaçlı site, mybank.com'un meşru rpID'sini talep edemez. Tarayıcı, passkey'i bir seçenek olarak bile sunmaz.

Ancak, rpID'nin kendisi birincil anti-phishing kontrolü değildir. WebAuthn'in phishing koruması aslında clientDataJSON nesnesindeki kaynak doğrulamasından gelir. Her WebAuthn işlemi sırasında, tarayıcı, isteği başlatan tam kaynağı da içeren kritik bağlamı barındıran bir JSON nesnesi oluşturur. Bu nesnenin tamamı daha sonra kimlik doğrulayıcının özel anahtarı ile kriptografik olarak imzalanır. Sunucu (Relying Party), bu imzayı doğrulamalı ve en önemlisi, imzalanan clientDataJSON'daki kaynak alanının beklenen, güvenilir bir değerle eşleştiğini onaylamalıdır. Phishing saldırılarını önleyen şey bu kaynak doğrulamasıdır.

İlişkili Kaynak Talepleri ile, rpID kapsamı gevşetilir—tarayıcının .well-known/webauthn dosyasını doğrulamasının ardından bar.com'un foo.com'un rpID'sini meşru bir şekilde talep etmesine izin verilir—ancak kaynak doğrulama gereksinimi değişmeden kalır. clientDataJSON yine de kaynağı dürüstçe bar.com olarak bildirecektir. foo.com'daki sunucu bu imzalı veriyi alır, doğrular ve isteğin bar.com'dan geldiğini görür. Sunucu daha sonra kimlik doğrulamayı kabul etmeden önce bar.com'un beklenen bir ilişkili kaynak olup olmadığını kontrol etmelidir. Bu, kaynak doğrulamasının temel ilkesinden ödün vermeden daha fazla esneklik sağlayan çok katmanlı bir yaklaşımı gösterir.

İlişkili Kaynak Talepleri mekanizması, alan adlarının passkey paylaşımı amacıyla bir güven ilişkisini herkese açık bir şekilde beyan etmeleri için zarif ve standartlaştırılmış bir yol sunar. Tarayıcıların danışabileceği, doğrulanabilir ve makine tarafından okunabilir bir "izin listesi" oluşturmak için köklü bir web deseni olan /.well-known/ URI'sinden yararlanır.

Temel konsept basittir: İlişkili siteler kümesi için birincil, kanonik rpID olarak hizmet veren bir alan adı, standartlaştırılmış, "iyi bilinen" bir URL'de özel bir JSON dosyası barındırabilir: https://{rpID}/.well-known/webauthn. Bu dosya, o birincil rpID altında passkey oluşturma ve kullanma yetkisi resmi olarak verilmiş diğer tüm kaynakları açıkça listeleyen bir kamu manifestosu görevi görür.

Tarayıcının doğrulama akışı, mevcut kaynak ile talep edilen rpID arasında bir uyuşmazlık tespit ettiğinde tetiklenir:

1. https://example.co.uk gibi "ilişkili" bir sitedeki bir kullanıcı, istemci tarafı kodunun rpID olarak farklı bir alan adını, örneğin example.com'u belirttiği bir passkey işlemi (oluşturma veya kimlik doğrulama) başlatır.
2. Tarayıcı bu uyuşmazlığı algılar. Eski kurallara göre, bu hemen bir SecurityError ile sonuçlanırdı.
3. ROR desteğiyle, tarayıcı, başarısız olmadan önce, iddia edilen rpID'nin iyi bilinen URL'sine güvenli bir HTTPS GET isteği yapar: https://example.com/.well-known/webauthn. Bu istek, kullanıcı gizliliğini korumak ve izlemeyi önlemek için kullanıcı kimlik bilgileri (çerezler gibi) ve bir yönlendiren başlığı olmadan yapılır.
4. Tarayıcı, sunucudan JSON yanıtını alır. Dosyayı ayrıştırır ve mevcut kaynağın (https://example.co.uk) JSON nesnesi içindeki origins dizisinde bulunup bulunmadığını kontrol eder.
5. Kaynak izin listesinde bulunursa, WebAuthn işleminin example.com'u geçerli rpID olarak kullanarak devam etmesine izin verilir. Kaynak bulunmazsa veya dosya eksik ya da hatalı biçimlendirilmişse, işlem daha önce olduğu gibi başarısız olur.

/.well-known/ URI'si kullanma tercihi kasıtlıdır ve ROR'u hizmet keşfi ve alan adı kontrolü doğrulaması için yerleşik web standartlarıyla uyumlu hale getirir. RFC 8615 tarafından tanımlanan bu URI yolu, Let's Encrypt SSL sertifikası verilmesi için acme-challenge ve web sitelerini Android uygulamalarına bağlamak için assetlinks.json dahil olmak üzere çok sayıda kritik protokol tarafından zaten kullanılmaktadır. W3C, bu geleneği benimseyerek, doğal olarak alan adı sahipliğini ima eden bir desenden yararlanır. Bu özel, standartlaştırılmış yola bir dosya yerleştirmek için, o alan adının web sunucusu üzerinde idari kontrole sahip olmak gerekir. Bu, basit ama etkili bir kontrol kanıtı sağlar ve güven beyanını doğrulanabilir kılar. example.com'un sahibi, example.co.uk'u ilişkili bir kaynak olarak listeleyen bir dosya sunduğunda, bu doğrulanabilir bir iddiadır. Bu web tabanlı yaklaşım, standardizasyon sürecinde düşünülen ve reddedilen, yetkilendirmeleri imzalamak için kriptografik anahtarlar (RP Anahtarları) veya alan adı tabanlı olmayan rastgele tanımlayıcılar (RP UUID'leri) kullanmak gibi alternatiflerden çok daha basit ve sağlamdır. ROR, güven ilişkisini web'in mevcut, iyi anlaşılmış alan adı kontrol modeline dayandırır.

İlişkili Kaynak Talepleri'ni uygulamak, hem kaynakları yetkilendirmek için sunucu tarafında hem de paylaşılan rpID'yi çağırmak için istemci tarafında koordineli değişiklikler gerektirir. Bu bölüm, alan adlarınız arasında birleşik bir passkey deneyimi sağlamak için gereken pratik kod ve yapılandırma ayrıntılarını sunar.

Birincil rpID'yi barındıran sunucu, ilişkili kaynakların izin listesini yayınlamaktan sorumludur.

Yetkilendirme dosyası, birincil rpID alan adının köküne göre tam olarak /.well-known/webauthn yoluna yerleştirilmelidir. Bu dosyanın aşağıdaki koşullar altında sunulması kritik öneme sahiptir:

• Protokol: HTTPS üzerinden sunulmalıdır.
• Content-Type: HTTP yanıt başlığı Content-Type, application/json olarak ayarlanmalıdır.
• Dosya Uzantısı: URL, .json uzantısı içermemelidir. Doğru yol /webauthn'dir, /webauthn.json değil.

Dosya, tek bir anahtarı olan tek bir JSON nesnesi içermelidir: origins. Bu anahtarın değeri bir dize dizisidir. Dizideki her dize, yetkilendirilen tam kaynaktır (protokol, alan adı ve isteğe bağlı port).

{
    "origins": ["https://example.co.uk", "https://example.de", "https://example.fr"]
}

Örnek: example.com rpID'si için dosya https://example.com/.well-known/webauthn adresinde sunulmalıdır (not: .json uzantısı yok).

Sunucu .well-known/webauthn dosyasıyla yapılandırıldıktan sonra, tüm ilişkili alan adları WebAuthn API çağrılarında tutarlı bir şekilde aynı paylaşılan rpID'yi kullanmalıdır. Bu koordinasyon, ROR'un doğru çalışması için kritik öneme sahiptir.

Önemli koordinasyon gereksinimleri:

1. Arka uç sorumluluğu: Sunucu, kriptografik challenge oluşturur ve hem kimlik bilgisi oluşturma hem de kimlik doğrulama isteklerinde paylaşılan rpID'yi belirtir.
2. Ön uç sorumluluğu: Tüm istemci uygulamaları (example.com, example.co.uk, example.de), tarayıcının navigator.credentials API'sine aynı paylaşılan rpID'yi geçmelidir.
3. Yapılandırma yönetimi: Paylaşılan rpID, tüm ilişkili sitelerde tutarlı bir şekilde uygulanan kritik bir küresel yapılandırma değeri olarak ele alınmalıdır.

Tek bir sitede bile, paylaşılan değer yerine kendi kaynağını rpID olarak varsayılan olarak kullanan bir yanlış yapılandırma, o alandaki kullanıcılar için birleşik passkey deneyimini bozar.

Önemli: Sunucu, her istek için clientDataJSON'daki origin alanını doğrulamalı ve bunun yetkili ilişkili kaynaklardan biriyle eşleştiğinden emin olmalıdır. Bu kaynak doğrulaması, birincil phishing koruma mekanizmasıdır.

İlişkili Kaynak Talepleri (ROR) ve birleşik kimlik protokolleri (OIDC/SAML) farklı sorunları çözer. ROR, Tek Oturum Açma (Single Sign-On) yerine geçmez—belirli dar bir kullanım durumunu ele alan bir tamamlayıcıdır.

ROR, aynı kullanıcı veritabanını paylaşan birden çok ilişkili alan adına dağıtılmış tek bir mantıksal uygulama için uygundur:

• Birden çok ülke kodu TLD'si işleten tek bir marka (örneğin, amazon.com, amazon.de, amazon.co.uk)
• Tüm alan adlarının aynı arka uç kimlik doğrulama sistemini ve kullanıcı veritabanını paylaşması
• Yönlendirme tabanlı akışlardan kaçınmak ve kimlik doğrulamayı her alan adına bağlamsal tutmak istemeniz
• Alan adlarınızın 5 etiket sınırı içinde olması
• Kullanıcıların tüm alan adlarını tek bir bütünleşik hizmet olarak deneyimlemesi gerektiği durumlar

ROR ne sağlar: Aynı passkey tüm ilişkili alan adlarında çalışır ve kullanıcıların her bölgesel site için ayrı passkey oluşturma ihtiyacını ortadan kaldırır.

Farklı uygulamalar arasında gerçek Tek Oturum Açma için birleşik kimlik protokollerini kullanın:

• Ayrı kullanıcı veritabanlarına veya kimlik sistemlerine sahip birden çok hizmet
• Kullanıcıların birçok farklı uygulamaya (Salesforce, Office 365, şirket içi araçlar) erişmesi gereken kurumsal senaryolar
• Üçüncü taraf uygulama entegrasyonu
• Merkezi erişim kontrolü, denetim izleri ve kimlik yönetimine ihtiyacınız olması
• İlişkili kaynaklar için 5 etiket sınırını aşmanız

OIDC/SAML ne sağlar: Kullanıcıların bir Kimlik Sağlayıcıda (IdP) bir kez oturum açtığı ve güvenli token'lar aracılığıyla birden çok Hizmet Sağlayıcıya (SP) erişim kazandığı merkezi kimlik doğrulama.

Önemli: Passkey'ler her iki yaklaşımla da kullanılabilir. Birleşik SSO için merkezi bir IdP'de passkey uygulayabilir veya çok alan adlı tek bir uygulama için ROR kullanabilirsiniz. Seçiminizi kimlik doğrulama yönteminize değil, mimarinize göre yapın.

ROR güçlü bir teknik çözüm olsa da, uygulanması bilinçli bir stratejik karar olmalıdır. Mimarlar ve ürün yöneticileri, sağlam ve geleceğe dönük bir kimlik doğrulama sistemi oluşturmak için faydalarını alternatif modellere karşı tartmalı ve sınırlamalarını anlamalıdır.

ROR'un önemli bir kısıtlaması "etiket sınırı"dır. Bu bağlamda bir "etiket", bir alan adının kaydedilebilir kısmı olan etkin üst düzey alan adı artı bir seviyeyi (eTLD+1) ifade eder. Örneğin:

• shopping.com, shopping.co.uk ve shopping.ca hepsi tek bir "shopping" etiketini paylaşır
• myshoppingrewards.com yeni, farklı bir etiket sunar: "myshoppingrewards"
• travel.shopping.com hala "shopping" etiketinin altına düşer

WebAuthn Seviye 3 şartnamesi, tarayıcı uygulamalarının origins listesinde minimum beş benzersiz etiketi desteklemesini gerektirir. 2025 itibarıyla, bilinen hiçbir tarayıcı bu minimum beş etiketten fazlasını desteklememektedir. Bu nedenle, kuruluşlar ROR dağıtımlarını bu katı sınırı göz önünde bulundurarak tasarlamalıdır—beşi etkin maksimum olarak kabul edin.

Bu sınır, kötüye kullanımı önlemek için tasarlanmış kasıtlı bir mekanizmadır. Paylaşılan barındırma sağlayıcıları (örneğin, wordpress.com) gibi varlıkların, binlerce ilişkisiz müşteri alt alanında çalışabilecek ve güvenlik modelini baltalayabilecek evrensel bir passkey oluşturmasını engeller.

Çoğu kuruluş, hatta büyük çok uluslu markalar için bile, bu beş etiket sınırı yeterlidir. Örneğin, Amazon'un çeşitli ülke kodu TLD'leri (amazon.com, amazon.de, amazon.co.uk, vb.) hepsi "amazon" etiketini paylaşır ve portföylerindeki "audible" veya "zappos" gibi diğer markalar için dört ek etiket yuvası bırakır.

ROR'u uygulamanın karmaşıklığı, yeni bir sisteme mi yoksa mevcut bir sisteme mi eklendiğine büyük ölçüde bağlıdır.

• Yeni Dağıtımlar: Yeni projeler için strateji basittir. Başlangıçtan itibaren paylaşılan rpID olarak tek, kanonik bir alan adı seçilmelidir (örneğin, birincil .com alanı). Bu rpID daha sonra tüm ilişkili web sitelerinin ve uygulamaların yapılandırmasında ilk günden itibaren tutarlı bir şekilde kullanılmalıdır.
• Mevcut Dağıtımlar: Alan adları arasında farklı rpID'lerle zaten passkey dağıtılmış bir sisteme ROR'u sonradan eklemek önemli ölçüde daha karmaşıktır. Mevcut passkey'ler kalıcı olarak orijinal rpID'lerine bağlı olduğundan doğrudan bir geçiş mümkün değildir. Bu senaryoda önerilen yaklaşım, "tanımlayıcı öncelikli" bir giriş akışı uygulamaktır. Kullanıcıdan önce kullanıcı adını veya e-postasını girmesi istenir. Arka uç daha sonra mevcut passkey'lerinin hangi rpID ile ilişkili olduğunu belirlemek için bir arama yapar. Son olarak, kullanıcı kimlik doğrulama işlemini tamamlamak için o rpID'ye karşılık gelen doğru kaynağa yönlendirilir. Başarılı bir girişten sonra, orijinal sitelerine geri yönlendirilebilirler. Bu, dikkatli planlama ve uygulama gerektiren önemli bir mimari çabadır.

Kurulu şirketlerin İlişkili Kaynak Talepleri'ni nasıl uyguladığını anlamak, kendi dağıtım stratejiniz için değerli bilgiler sağlar. Aşağıda, gerçek uygulamalara dayanan örnekler bulunmaktadır (Ekim 2025 itibarıyla):

Microsoft, kimlik doğrulama altyapısı için ROR kullanır. login.microsoftonline.com adresindeki gerçek yapılandırma şunları içerir:

// https://login.microsoftonline.com/.well-known/webauthn
{
    "origins": ["https://login.microsoftonline.com", "https://login.live.com"]
}

Bu muhafazakar yaklaşım, Microsoft'un kurumsal ve tüketici giriş portalları arasında passkey paylaşımına olanak tanırken odaklanmış bir güvenlik çevresini korur.

Shopify, seçili alan adları arasında kimlik doğrulamayı birleştirmek için ROR uygular:

// https://shopify.com/.well-known/webauthn
{
    "origins": ["https://shopify.com", "https://shop.app"]
}

Bu yapılandırma, Shopify'ın ana platformunu Shop uygulamasıyla bağlamasına olanak tanır ve ilişkili kaynaklara odaklanmış bir yaklaşım sergiler.

Amazon'un oldukça büyük bir dosyası var:

// https://amazon.com/.well-known/webauthn
{
    "origins": [
        "https://www.amazon.com",
        "https://www.amazon.com.br",
        "https://www.amazon.com.mx",
        "https://www.amazon.ca",
        "https://www.amazon.co.uk",
        "https://www.amazon.de",
        "https://www.amazon.it",
        "https://www.amazon.es",
        "https://www.amazon.nl",
        "https://www.amazon.se",
        "https://www.amazon.sa",
        "https://www.amazon.pl",
        "https://www.amazon.com.tr",
        "https://www.amazon.fr",
        "https://www.amazon.com.au",
        "https://www.amazon.sg",
        "https://www.amazon.ae",
        "https://www.amazon.eg",
        "https://www.amazon.co.za",
        "https://www.amazon.in",
        "https://brandregistry.amazon.com",
        "https://sellercentral.amazon.com",
        "https://sellercentral.amazon.com.br",
        "https://sellercentral.amazon.com.mx",
        "https://sellercentral.amazon.ca",
        "https://sellercentral.amazon.co.uk",
        "https://sellercentral.amazon.de",
        "https://sellercentral.amazon.it",
        "https://sellercentral.amazon.es",
        "https://sellercentral.amazon.nl",
        "https://sellercentral.amazon.se",
        "https://sellercentral.amazon.sa",
        "https://sellercentral.amazon.pl",
        "https://sellercentral.amazon.com.tr",
        "https://sellercentral.amazon.fr",
        "https://sellercentral.amazon.com.au",
        "https://sellercentral.amazon.sg",
        "https://sellercentral.amazon.ae",
        "https://sellercentral.amazon.eg",
        "https://sellercentral.amazon.co.za",
        "https://sellercentral.amazon.in",
        "https://na.account.amazon.com",
        "https://vendorcentral.amazon.com",
        "https://vendorcentral.amazon.com.br",
        "https://vendorcentral.amazon.com.mx",
        "https://vendorcentral.amazon.ca",
        "https://vendorcentral.amazon.co.uk",
        "https://vendorcentral.amazon.de",
        "https://vendorcentral.amazon.it",
        "https://vendorcentral.amazon.es",
        "https://vendorcentral.amazon.nl",
        "https://vendorcentral.amazon.se",
        "https://vendorcentral.amazon.pl",
        "https://vendorcentral.amazon.com.tr",
        "https://vendorcentral.amazon.fr",
        "https://vendorcentral.amazon.com.au",
        "https://vendorcentral.amazon.co.za"
    ]
}

Bu model, bir markanın birincil .com alanını rpID olarak kullanırken bölgesel alan adları arasında birleşik passkey kimlik doğrulaması sağlamasına olanak tanır.

Bu gerçek dünya örnekleri birkaç önemli deseni ortaya koymaktadır:

1. rpID Olarak Birincil Alan Adı: Tüm şirketler birincil .com alan adlarını kanonik rpID olarak kullanır.
2. Mantıksal Gruplama: Kaynaklar, teknik mimariden ziyade iş fonksiyonuna göre gruplandırılmıştır.
3. Muhafazakar Kapsam: Çoğu uygulama, genellikle 3-4 kaynak kullanarak 5 etiket sınırının oldukça altında kalır.
4. Alt Alan Adı Stratejisi: Birçoğu, marka tutarlılığını korumak için birincil alan adının alt alan adlarını kullanır.

Modern bir web standardı olarak ROR, güvenlik birincil öncelik olarak tasarlanmış ve büyük tarayıcılar arasında aktif olarak benimsenmektedir.

İlişkili Kaynak Talepleri, WebAuthn'in temel anti-phishing garantilerinden ödün vermez. Mekanizma, güçlü bir güvenlik duruşunu sürdürmek için dikkatle tasarlanmıştır:

• Kaynak Doğrulaması: Tartışıldığı gibi, tarayıcı hala isteğin gerçek kaynağını imzalı clientDataJSON'a dahil eder. Relying Party sunucusu, isteğin beklenen bir kaynaktan geldiğinden emin olmak için bu kaynağı doğrulamalıdır, bu da ele geçirilmiş bir ilişkili kaynağın başka birini taklit etmesini önler.
• Güvenli Getirme: Tarayıcının .well-known/webauthn dosyasına yaptığı istek HTTPS üzerinden yapılır. Ayrıca, şartname bu getirmenin kimlik bilgileri (örneğin, çerezler) olmadan ve bir Referer başlığı olmadan yapılmasını zorunlu kılar. Bu, isteğin kullanıcı bilgilerini sızdırmak veya siteler arası izleme amaçlı kullanılmasını önler.
• Sunucu Güvenliği: .well-known/webauthn dosyasının kendisi kritik bir güvenlik varlığı haline gelir. Birincil rpID'yi barındıran web sunucusunun kontrolünü ele geçiren bir saldırgan, potansiyel olarak bu dosyayı kendi kötü amaçlı alan adını izin listesine eklemek için değiştirebilir. Bu nedenle, bu dosyayı sunan altyapının güvenliğini sağlamak son derece önemlidir.

İlişkili Kaynak Talepleri, WebAuthn Seviye 3 şartnamesinin bir özelliğidir. Tarayıcı desteği 2024'ün sonlarında sunulmaya başlandı:

Önemli bilgiler:

• Chrome ve Edge: ROR desteğini 128. sürümde (Ağustos 2024) ekledi.
• Safari: ROR desteğini Safari 18'de ekledi, macOS 15 ve iOS 18'de (Eylül 2024) mevcut.
• Firefox: Şu anda ROR desteği yok; özellik tespiti yapın ve yedek akışlar uygulayın.

Eski tarayıcıları veya Firefox'u desteklemesi gereken uygulamalar için bir yedek strateji uygulayın:

1. Özellik tespiti: PublicKeyCredential.getClientCapabilities() kullanarak ROR desteğini kontrol edin.
2. Tanımlayıcı öncelikli akış: Kullanıcı adı/e-posta isteyin, kullanıcının ilişkili rpID'sini arayın, ardından kimlik doğrulama için uygun kaynağa yönlendirin.
3. Zarif düşüş: ROR mevcut değilse kullanıcıların her alan adı için ayrı passkey oluşturmasına izin verin.

Veriler, Ekim 2025 itibarıyla mevcut destek matrislerine dayanmaktadır.

İlişkili Kaynak Talepleri'ni uygulamak, birden çok teknik ekip arasında dikkatli bir koordinasyon ve WebAuthn protokollerinde derin uzmanlık gerektirir. Corbado'nun passkey benimseme platformu, çok alan adlı passkey dağıtımları için kurumsal düzeyde çözümler sunarak bu karmaşıklığı ortadan kaldırır.

Corbado, İlişkili Kaynak Talepleri'nin teknik karmaşıklığını şu şekilde ele alır:

• Otomatik Yapılandırma: Platformumuz, gerekli .well-known/webauthn dosyalarını uygun güvenlik başlıkları ve JSON biçimlendirmesiyle otomatik olarak oluşturur ve barındırır.
• Çok Alan Adlı Gösterge Paneli: Tüm alan adı portföyünüzdeki ilişkili kaynakları yapılandırmak için merkezi yönetim arayüzü.
• Doğrulama Araçları: ROR yapılandırmanızın tüm tarayıcılarda ve platformlarda doğru çalıştığından emin olmak için yerleşik test ve doğrulama.

Teknik uygulamanın ötesinde, Corbado işletmelerin ihtiyaç duyduğu güvenlik çerçevesini sağlar:

• Kaynak Doğrulaması: İlişkili alan adı kötüye kullanımını önlemek için clientDataJSON kaynaklarının otomatik doğrulanması.
• Denetim Günlüğü: Uyumluluk ve güvenlik izlemesi için tüm ilişkili alan adlarında passkey kullanımının kapsamlı takibi.
• Olay Müdahalesi: Şüpheli alanlar arası kimlik doğrulama girişimleri için gerçek zamanlı uyarılar ve otomatik yanıtlar.

Mevcut passkey dağıtımlarına sahip kuruluşlar için Corbado şunları sunar:

• Eski Sistem Geçiş Araçları: Mevcut rpID yapılandırmalarının otomatik analizi ve geçiş yolu önerileri.
• Tanımlayıcı Öncelikli Akışlar: Geçiş dönemlerinde karmaşık çoklu rpID senaryolarını ele alan önceden oluşturulmuş giriş bileşenleri.
• API Entegrasyonu: Mevcut kimlik doğrulama altyapınızla sorunsuz bir şekilde entegre olan RESTful API'ler ve SDK'lar.

Kuruluşunuz için İlişkili Kaynak Talepleri'ni uygulamaya hazır mısınız? Corbado'nun uzman ekibi, tüm dijital ekosisteminizde birleşik bir passkey deneyimi tasarlamanıza ve dağıtmanıza yardımcı olabilir. Özel gereksinimlerinizi ve zaman çizelgenizi görüşmek için çözüm ekibimizle iletişime geçin.

Passkey'lerin vaadi, hem daha güvenli hem de kullanıcılar için dikkat çekici derecede daha basit bir gelecek sunma yeteneklerinde yatmaktadır. Ancak, bu geleceğin küresel ölçekte bir gerçeklik haline gelmesi için, standardın modern dijital markaların mimari karmaşıklıklarını barındırması gerekir. Kesinlikle alana bağlı passkey'lerin yarattığı sürtünme, çok yönlü çevrimiçi varlıklara sahip kuruluşlar için benimsemenin önünde önemli bir engel olmuştur.

WebAuthn İlişkili Kaynak Talepleri, bu soruna standartlaştırılmış, güvenli ve zarif bir çözüm sunar. Tek bir passkey'in güvenilir bir ilişkili alan adı kümesinde sorunsuz bir şekilde çalışmasına izin vererek, ROR, kullanıcı kafa karışıklığı ve hayal kırıklığının önemli bir noktasını ortadan kaldırır.

Bu rehber, WebAuthn İlişkili Kaynak Talepleri'ni uygulamak için beş kritik soruyu ele aldı:

1. Passkey'ler neden birden fazla alan adında başarısız olur? WebAuthn'in kaynağa bağlı güvenlik modeli, phishing'i önlemek için passkey'leri belirli alan adlarına kriptografik olarak kilitler, ancak bu, markalar farklı ülke TLD'leri gibi birden fazla alanda faaliyet gösterdiğinde sürtünme yaratır.
2. İlişkili Kaynak Talepleri teknik olarak nasıl çalışır? ROR, doğrulanabilir bir ilişkili alan adı izin listesi oluşturmak için standartlaştırılmış bir .well-known/webauthn dosyası kullanır ve tarayıcıların güvenli bir HTTPS getirme işlemiyle alanlar arası passkey kullanımını doğrulamasına olanak tanır.
3. ROR'u uygulamak için ne gerekir? Uygulama, .well-known/webauthn manifest dosyasının sunucu tarafı yapılandırmasını ve tüm ilişkili kaynaklarda tutarlı bir şekilde paylaşılan bir rpID kullanmak için istemci tarafı koordinasyonunu gerektirir.
4. Ne zaman ROR'u birleşik girişe tercih etmelisiniz? Paylaşılan kullanıcı veritabanlarına sahip ilişkili alan adları arasında birleşik marka deneyimleri için ROR'u kullanın; farklı uygulamalar arasında gerçek SSO için veya 5 etiket sınırını aştığınızda OIDC/SAML kullanın.
5. Tarayıcı uyumluluğunu ve güvenlik konularını nasıl ele alırsınız? ROR, Chrome/Firefox 128+, macOS 15+ üzerinde Safari ve iOS 18+ gibi büyük tarayıcılarda desteklenir ve eski tarayıcılar için tanımlayıcı öncelikli akışlar aracılığıyla yedek stratejiler mevcuttur.

Teknik ekipler ve ürün liderleri için temel noktalar şunlardır:

• ROR, farklı ülke kodu TLD'leri veya alternatif markalaşma gibi birden çok alana yayılmış tek bir mantıksal uygulama için birleşik bir passkey deneyimi sağlar.
• Uygulama, koordineli bir çaba gerektirir: Birincil rpID'nin alan adında sunucu tarafı bir .well-known/webauthn dosyası yayınlanmalı ve tüm istemci tarafı uygulamalar aynı paylaşılan rpID'yi kullanacak şekilde yapılandırılmalıdır.
• ROR kullanma kararı stratejik bir karardır. Belirli kullanım durumları için mükemmel bir araçtır, ancak özellikle farklı uygulamalar arasında gerçek Tek Oturum Açma içeren senaryolarda daha geleneksel bir birleşik giriş mimarisine (OIDC/SAML) karşı tartılmalıdır.

İlişkili Kaynak Talepleri gibi özellikler, şifresiz hareketin devam eden ivmesi için hayati öneme sahiptir. Standartlar kuruluşlarının, passkey'lerin faydalarının—benzersiz güvenlik ve zahmetsiz kullanıcı deneyimi—en büyük ve en karmaşık kuruluşlar için bile erişilebilir olmasını sağlamak amacıyla gerçek dünya uygulama zorluklarını ele alma taahhüdünü gösterirler. Bu özellik evrensel tarayıcı desteği kazandıkça, gerçekten küresel, şifresiz bir internetin önündeki son engelleri yıkmada çok önemli bir rol oynayacaktır.