--- url: 'https://www.corbado.com/tr/blog/webauthn-iliskili-kaynaklar-alan-adlari-arasi-passkey' title: 'WebAuthn İlişkili Kaynaklar: Alan Adları Arası Passkey Rehberi' description: 'WebAuthn İlişkili Kaynak Talepleri''nin birden fazla alan adında passkey''leri nasıl etkinleştirdiğini öğrenin. Gerçek dünya örnekleriyle eksiksiz bir uygulama rehberi.' lang: 'tr' author: 'Vincent Delitz' date: '2025-10-31T14:41:16.924Z' lastModified: '2026-03-27T07:08:52.575Z' keywords: 'ilişkili kaynaklar, webauthn ilişkili kaynak, ilişkili kaynak talebi, alan adları arası passkey''ler, .well-known/webauthn, ROR' category: 'WebAuthn Know-How' --- # WebAuthn İlişkili Kaynaklar: Alan Adları Arası Passkey Rehberi ## 1. Giriş: Passkey'ler için Dijital Sınırları Yıkmak [Passkey'ler](https://www.corbado.com/tr/blog/tamamen-sifresiz-sisteme-nasil-gecilir), güvenli ve kullanıcı dostu [kimlik doğrulama](https://www.corbado.com/tr/blog/digital-credentials-api) için yeni standarttır. FIDO/WebAuthn standartları üzerine inşa edilen bu anahtarlar, açık anahtar kriptografisinden yararlanarak [phishing](https://www.corbado.com/glossary/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](https://www.corbado.com/glossary/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](https://www.corbado.com/blog/x-twitter-passkeys)'ın X olarak yeniden markalaşmasıdır. [twitter](https://www.corbado.com/blog/x-twitter-passkeys).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](https://developer.chrome.com/blog/passkeys-updates-chrome-129) sunarak bir markanın tüm dijital ekosisteminde birleşik ve kesintisiz bir [kimlik doğrulama](https://www.corbado.com/tr/blog/digital-credentials-api) deneyimi yaratır. Bu derinlemesine inceleme, [ROR](https://www.corbado.com/blog/webauthn-related-origins-cross-domain-passkeys)'un teknik temellerini araştırıyor, uygulanması için pratik bir rehber sunuyor ve modern [kimlik doğrulama](https://www.corbado.com/tr/blog/digital-credentials-api) mimarisi için stratejik sonuçlarını analiz ediyor. [ROR](https://www.corbado.com/blog/webauthn-related-origins-cross-domain-passkeys)'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](https://www.w3.org/TR/webauthn-3/) oluşturulmasına öncelik vermişti. Bir kimlik bilgisinin bir [Relying Party](https://www.corbado.com/glossary/relying-party) ID'sine (rpID) sıkı bir şekilde bağlanması, anti-[phishing](https://www.corbado.com/glossary/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](https://www.corbado.com/blog/webauthn-related-origins-cross-domain-passkeys)'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ı](https://github.com/w3c/webauthn/wiki/Explainer:-Related-origin-requests)'na bakın. ## 2. Kök Sorun: WebAuthn'in Relying Party ID'si ve Kaynak Kapsamı İ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](https://www.corbado.com/glossary/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. ### 2.1 Web Kaynağı ve Aynı-Kaynak Politikası 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ı**](https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy), 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. ### 2.2 Relying Party ID (rpID) WebAuthn ekosisteminde, "[Relying Party](https://www.corbado.com/glossary/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](https://www.corbado.com/glossary/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](https://www.corbado.com/glossary/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. ## 3. Çözüm: İlişkili Kaynak Talepleri Nasıl Çalışır? İ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](https://www.corbado.com/blog/webauthn-errors) 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](https://www.corbado.com/blog/how-to-enable-passkeys-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. ## 4. İlişkili Kaynaklar için Pratik Uygulama Rehberi İ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. ### 4.1 Sunucu Tarafı: .well-known/webauthn ile Kaynakları Yetkilendirme Birincil rpID'yi barındıran sunucu, ilişkili kaynakların izin listesini yayınlamaktan sorumludur. #### 4.1.1 Dosya Konumu ve Biçimi 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. #### 4.1.2 JSON Yapısı 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). ```json { "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). ### 4.2 İstemci Tarafı: Paylaşılan bir rpID'yi Çağırma 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](https://www.corbado.com/glossary/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. ## 5. Öneri: Birleşik Marka Deneyimleri için ROR'u, Gerçek SSO için OIDC'yi seçin **İ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. ### 5.1 İlişkili Kaynak Talepleri Ne Zaman Kullanılı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. ### 5.2 Birleşik Giriş (OIDC/SAML) Ne Zaman Kullanılı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](https://www.corbado.com/tr/blog/tamamen-sifresiz-sisteme-nasil-gecilir) her iki yaklaşımla da kullanılabilir. Birleşik [SSO](https://www.corbado.com/blog/passkeys-single-sign-on-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. ## 6. Passkey Mimarisi için Stratejik Değerlendirmeler 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. ### 6.1 5 Etiket Sınırını Anlamak 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. ### 6.2 Dağıtım Stratejileri: Yeni Projeler ve Mevcut Sistemler 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](https://www.corbado.com/tr/blog/tamamen-sifresiz-sisteme-nasil-gecilir) 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. ## 7. Gerçek Dünya Örnekleri: Büyük Markalar İlişkili Kaynakları Nasıl Uyguluyor? 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): ### 7.1 Microsoft'un Uygulaması Microsoft, kimlik doğrulama [altyapısı](https://www.corbado.com/passkeys-for-critical-infrastructure) için ROR kullanır. `login.microsoftonline.com` adresindeki gerçek yapılandırma şunları içerir: ```json // 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. ### 7.2 Shopify'ın Uygulaması [Shopify](https://www.corbado.com/blog/shopify-passkeys), seçili alan adları arasında kimlik doğrulamayı birleştirmek için ROR uygular: ```json // https://shopify.com/.well-known/webauthn { "origins": ["https://shopify.com", "https://shop.app"] } ``` Bu yapılandırma, [Shopify](https://www.corbado.com/blog/shopify-passkeys)'ın ana platformunu Shop uygulamasıyla bağlamasına olanak tanır ve ilişkili kaynaklara odaklanmış bir yaklaşım sergiler. ### 7.3 Amazon'un Uygulaması Amazon'un oldukça büyük bir dosyası var: ```json // 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. ### 7.4 Uygulama Desenleri ve En İyi Uygulamalar 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. ## 8. Tarayıcı Desteği ve Güvenlik Duruşu Modern bir web standardı olarak ROR, güvenlik birincil öncelik olarak tasarlanmış ve büyük tarayıcılar arasında aktif olarak benimsenmektedir. ### 8.1 Güvenlik Modeli İ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](https://www.corbado.com/passkeys-for-critical-infrastructure) güvenliğini sağlamak son derece önemlidir. ### 8.2 Tarayıcı ve Platform Desteği İlişkili Kaynak Talepleri, [WebAuthn Seviye 3](https://www.corbado.com/tr/blog/passkeys-prf-webauthn-uctan-uca-sifreleme) şartnamesinin bir özelliğidir. Tarayıcı desteği 2024'ün sonlarında sunulmaya başlandı: | **İşletim Sistemi** | **Tarayıcı / Platform** | **Sürüm Desteği** | **Durum** | | ------------------- | ------------------------ | --------------------- | --------------------------- | | Android | Chrome, Edge | 128+ | ✅ Destekleniyor | | Chrome OS | Chrome, Edge | 128+ | ✅ Destekleniyor | | iOS / iPadOS | Tüm Tarayıcılar (Safari) | iOS 18+ | ✅ Destekleniyor | | macOS | Chrome, Edge | 128+ | ✅ Destekleniyor | | macOS | Safari | Safari 18 (macOS 15+) | ✅ Destekleniyor | | Ubuntu | Chrome, Edge | 128+ | ✅ Destekleniyor | | Windows | Chrome, Edge | 128+ | ✅ Destekleniyor | | Tüm Platformlar | Firefox | Desteklenmiyor | ⚠️ Yedek mekanizma kullanın | **Önemli bilgiler:** - **Chrome ve Edge:** ROR desteğini 128. sürümde (Ağustos 2024) ekledi. - **Safari:** ROR desteğini [Safari 18](https://www.corbado.com/blog/ios-18-passkeys-automatic-passkey-upgrades)'de ekledi, macOS 15 ve [iOS 18](https://www.corbado.com/blog/ios-18-passkeys-automatic-passkey-upgrades)'de (Eylül 2024) mevcut. - **Firefox:** Şu anda ROR desteği yok; özellik tespiti yapın ve yedek akışlar uygulayın. ### Özellik Tespiti ve Yedek Mekanizma 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. ## 9. Corbado nasıl yardımcı olabilir? İ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](https://www.corbado.com/tr/blog/passkey-benimseme-is-gerekcesi) platformu, çok alan adlı passkey dağıtımları için kurumsal düzeyde çözümler sunarak bu karmaşıklığı ortadan kaldırır. ### 9.1 Basitleştirilmiş ROR Uygulaması 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. ### 9.2 Kurumsal Düzeyde Güvenlik ve Uyumluluk 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. ### 9.3 Geçiş ve Entegrasyon Desteği 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](https://www.corbado.com/passkeys-for-critical-infrastructure) sorunsuz bir şekilde entegre olan RESTful API'ler ve SDK'lar. ### 9.4 Başlarken 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](https://www.corbado.com/contact). ## 10. Sonuç: Çok Alan Adlı Passkey'ler için Sorunsuz bir Gelecek 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](https://www.corbado.com/blog/passkeys-single-sign-on-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](https://www.corbado.com/blog/ios-18-passkeys-automatic-passkey-upgrades)+ 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. ### Önemli Çıkarımlar 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.