--- url: 'https://www.corbado.com/tr/blog/webauthn-relying-party-id-rpid-passkeys' title: 'WebAuthn Relying Party ID (rpID) ve Geçiş Anahtarları: Etki Alanları ve Yerel Uygulamalar' description: 'Bu blog yazısı, geçiş anahtarı kimlik doğrulaması için WebAuthn Relying Party ID''sini açıklamaktadır. Doğru yapılandırmayı, etki alanı eşleştirmesini ve yerel uygulama yapılandırmalarını özetler.' lang: 'tr' author: 'Vincent Delitz' date: '2026-06-15T13:56:39.876Z' lastModified: '2026-06-16T06:08:15.183Z' keywords: 'relying party id, geçiş anahtarı kimlik doğrulaması, webauthn, rpid, passkeys' category: 'WebAuthn Know-How' --- # WebAuthn Relying Party ID (rpID) ve Geçiş Anahtarları: Etki Alanları ve Yerel Uygulamalar ## Key Facts - **Relying Party ID**, her geçiş anahtarına gömülü bir etki alanıdır (domain). Tarayıcı kaynağı eşleşmezse kimlik doğrulama başarısız olur, bu da geçiş anahtarlarını kimlik avına (phishing) karşı oldukça dirençli hale getirir. - **RP ID**, **Genel Son Ek Listesinde (Public Suffix List)** yer almamalıdır ve bunu değiştirmek, mevcut tüm geçiş anahtarlarını geçersiz kılar. Geleceğe dönük bir yapı için varsayılan olarak kök etki alanını kullanın. - iOS uygulamaları, RP ID altındaki `/.well-known/` dizininde bir **apple-app-site-association** dosyasına ihtiyaç duyar. Android, aynı yolda **assetlinks.json** dosyası gerektirir. Yeni dosyaların önbelleğe alınması 24 saate kadar sürebilir. - Birden fazla kök etki alanının geçiş anahtarı paylaşımı için `.well-known/webauthn` aracılığıyla **Related Origin Requests** yapılandırmasına ihtiyacı vardır. Tüm uygulamalar (web ve yerel) için tek bir RP ID ile tek bir WebAuthn sunucusu kullanın. ## 1. Giriş [TikTok](https://www.corbado.com/blog/tiktok-passkeys), GitHub, [WhatsApp](https://www.corbado.com/blog/whatsapp-passkeys), X (Twitter), [LinkedIn](https://www.corbado.com/blog/linkedin-passkeys) ve Amazon gibi teknoloji devleri [geçiş anahtarları](https://www.corbado.com/tr/glossary/cda)nı kullanıma sundukça veya zaten sunmuş oldukları için, geçiş anahtarı kimlik doğrulaması hızla standart haline geliyor. Teknoloji dünyasının basit ve güvenli kimlik doğrulamanın önemini anladığı ortada. [Face ID](https://www.corbado.com/faq/is-face-id-passkey), Touch ID veya [Windows Hello](https://www.corbado.com/glossary/windows-hello) ile kimlik doğrulamanın kusursuz kullanıcı deneyiminin ötesinde, geçiş anahtarları, parolalar gibi geleneksel [kimlik doğrulama](https://www.corbado.com/tr/blog/digital-credentials-api) yöntemleriyle karşılaştırıldığında benzersiz bir güvenlik sunar. Öne çıkan özelliklerinden biri kimlik avına karşı güçlü dirençleridir. Kimlik avı (phishing) saldırısı, kurbanın orijinal siteyi taklit eden sahte bir siteye kimlik bilgilerini sağlaması için kandırıldığı bir saldırıdır. Örneğin, bankanızdan gelmiş gibi görünen ve giriş yapmanızı isteyen bir e-posta aldığınızı hayal edin. Bağlantıya tıklarsınız, web sitesi meşru görünür, bu nedenle kimlik bilgilerinizi girersiniz ve saldırgan bunları orijinal siteye giriş yapmak için kullanabilir. Bu, dijital çağda giderek büyüyen bir sorun haline geliyor ve [Okta ](https://www.darkreading.com/application-security/okta-flaw-involved-mgm-resorts-breach-attackers-claim)(bir [kimlik doğrulama](https://www.corbado.com/tr/blog/digital-credentials-api) sağlayıcısı!) veya [Retool ](https://retool.com/blog/mfa-isnt-mfa/)gibi büyük şirketler bile hedef odaklı kimlik avı (spear-[phishing](https://www.corbado.com/glossary/phishing)) saldırılarının kurbanı olmuştur (tekil kurbanların çok kişisel kimlik avı hileleriyle özellikle hedeflendiği özel bir kimlik avı biçimi), bu da sağlam güvenlik önlemlerine olan ihtiyacı vurgulamaktadır. Aksine, bir geçiş anahtarı kullanırsanız ve site sahteyse, kimlik doğrulamanız başarısız olur. Bunun nedeni, [geçiş anahtarları](https://www.corbado.com/tr/glossary/cda)nın **Relying Party ID** aracılığıyla oluşturuldukları etki alanlarına bağlı olmalarıdır. > Bir [geçiş anahtarı](https://www.corbado.com/tr/blog/guvenli-belge-yonetimi)yla başka bir sitede oturum > açamazsınız, bu da [geçiş anahtarları](https://www.corbado.com/tr/glossary/cda)nı kimlik avına karşı oldukça > dirençli hale getirir (her ne kadar hiçbir sistem tüm saldırı vektörlerine karşı tamamen > bağışık olmasa da). Bu mekanizma, [parolasız kimlik doğrulama](https://www.corbado.com/tr/faq/passkeys-nedir) için geçiş anahtarlarının temelini oluşturan web standardı WebAuthn'e entegre edilmiştir. WebAuthn iki temel tören (ceremony) üzerine kuruludur: kayıt ve [kimlik doğrulama](https://www.corbado.com/tr/blog/digital-credentials-api) töreni. Kayıt (kaydolma) töreni sırasında, bir web veya [yerel uygulama](https://www.corbado.com/tr/blog/yerel-uygulama-passkeys) aracılığıyla çevrimiçi bir hizmet (Relying Party) için yeni bir geçiş anahtarı oluşturulur. Bu süreçte, [geçiş anahtarı](https://www.corbado.com/tr/blog/guvenli-belge-yonetimi)nın oluşturulduğu etki alanı (Relying Party ID) [geçiş anahtarı](https://www.corbado.com/tr/blog/guvenli-belge-yonetimi)nda saklanır. Bu, kimlik doğrulama (oturum açma) töreninin, web veya yerel uygulamanın ait olduğu çevrimiçi hizmetin (Relying Party), geçiş anahtarında saklanan [Relying Party](https://www.corbado.com/glossary/relying-party) ID ile eşleşip eşleşmediğini kontrol etmesini sağlar. Aşağıda, bu [etki alanı eşleme](#what-relying-party-id) sürecinin nasıl çalıştığını ve özellikle yerel uygulamaların nasıl güvence altına alındığını ayrıntılı olarak göreceğiz. ## 2. Relying Party ID Nedir? [**Relying Party ID**](https://www.w3.org/TR/webauthn-2/#relying-party-identifier), temel olarak geçiş anahtarı içinde saklanan bir etki alanıdır ve geçiş anahtarının yalnızca mevcut tarayıcı URL'si (her istekte otomatik olarak gönderilen kullanıcı kaynağı) ile eşleşmesi durumunda çalışmasını sağlar (aşağıdaki [yerel uygulama yaklaşımına](#integration-options-native-apps) bakın). Bu, WebAuthn spesifikasyonunun çok önemli bir bileşenidir ve [buradan](https://www.w3.org/TR/webauthn-2/) inceleyebilirsiniz. [Relying Party](https://www.corbado.com/glossary/relying-party) ID kök etki alanı (örn. `corbado.com`) veya bir alt alan adı (`auth.corbado.com`) olabilir. Genel son ek listesinde ise (listeyi ve genel son ek tespiti için kütüphaneleri [burada](https://publicsuffix.org/learn/) bulabilirsiniz) kök etki alanını [Relying Party](https://www.corbado.com/glossary/relying-party) ID olarak kaydedemezsiniz. Çevrimiçi bir hizmet için Relying Party ID'yi değiştirmek mevcut geçiş anahtarlarını bozar (istisnalar: yeni Relying Party ID, eski Relying Party ID'nin bir alt alan adıdır veya geçiş anahtarının ilgili etki alanları arasında yeniden kullanımına izin vermek için `.well-known/webauthn` aracılığıyla Related Origin Requests yapılandırılmıştır). Kimlik doğrulama işlemi sırasında, eşleştiklerinden emin olmak için Relying Party ID, tarayıcı URL'sine (kullanıcının kaynağı) karşı kontrol edilir. Bu anlamda eşleştirme, aşağıdakilerden biri anlamına gelir: - Tarayıcı URL'si (kullanıcının kaynağı) tam olarak Relying Party ID ile eşleşiyor VEYA - Tarayıcı URL'si (kullanıcının kaynağı) Relying Party ID ile eşleşen bir alt alan adıdır ve ana etki alanı kaydedilebilir düzeydedir (örn. `com` veya Genel Son Ek Listesindeki herhangi bir etki alanı çalışmaz) Aşağıda, hangi _originalHost'un_ (ikinci sütun) ana etki alanına erişmesine izin verildiğini gösteren ayrıntılı bir taslak bulunmaktadır: ![relying party id table](https://www.corbado.com/website-assets/relying_party_id_table_4c98cc04f4.jpg) Aşağıda, ayrıştırılmış (parsed) [**PublicKeyCredentialCreationOptions**](https://www.w3.org/TR/webauthn-2/#iface-pkcredential) yapısını görüyorsunuz: ```json { "publicKey": { "attestation": "direct", "authenticatorSelection": { "authenticatorAttachment": "platform", "requireResidentKey": false, "userVerification": "preferred" }, "challenge": "qNqrdXUrk5S7dCM1MAYH3qSVDXznb-6prQoGqiACR10=", "excludeCredentials": [], "pubKeyCredParams": [ { "alg": -7, "type": "public-key" } ], "rp": { "id": "corbado.com", "name": "Corbado" }, "timeout": 30000, "user": { "displayName": "Corbado user", "id": "bz9ZDfHzOBLycqISTAdWwWIZt8VO-6mT3hBNXS5jwmY=" } } } ``` `rp`, Relying Party'yi temsil eder. Relying Party ID'nin en önemli faydalarından biri kimlik avı saldırılarının önlenmesidir. Aşağıdaki senaryoyu hayal edin: 1. Bir saldırgan, sizin adınıza giriş yapmak ve saldırganın hesabına para göndermek için [PayPal](https://www.corbado.com/blog/paypal-passkeys) kimlik bilgilerinizi çalmaya çalışan sahte bir web sitesi olan bir [PayPal](https://www.corbado.com/blog/paypal-passkeys) klonu geliştirir. Bu sahte [PayPal](https://www.corbado.com/blog/paypal-passkeys) web sitesi paybal.com alan adında barındırılır (bu nedenle ilk bakışta farklı bir alan adı olduğu genellikle fark edilmez). 2. Geçmişte yasal PayPal sitesi için zaten bir geçiş anahtarı oluşturdunuz. Bu geçiş anahtarı, paypal.com Relying Party ID'sini sakladı. 3. paybal.com adresindeki sahte PayPal web sitesini ziyaret edersiniz (bu siteyi ziyaret ettiğinizde, isteğinizin kaynağı paybal.com'dur\*) ve site, cihazınıza (kimlik doğrulayıcıya) Relying Party ID `paypal.com` için bir meydan okuma (challenge) gönderir (burada sizi kandırmaya çalışır) ve sizden onu paypal.com Relying Party ID'si için geçiş anahtarınızla imzalamanızı ister. 4. Cihazınız (kimlik doğrulayıcı), isteğin kaynağı (`paypal.com`) ile geçiş anahtarında sakladığı Relying Party ID'nin (`paypal.com`) eşleşip eşleşmediğini kontrol eder. 5. Bunlar açıkça eşleşmediğinden, kimlik doğrulama başarısız olur ve sizi bazı saldırganlara PayPal hesabınıza erişim izni vermekten kurtarır. Aşağıdaki diyagram, bu kimlik avı önleme mekanizmasını göstermektedir. _Yerel bir uygulama durumunda, kaynak (origin) işleme platforma göre farklılık gösterir: Android'de kaynak `android:apk-key-hash:` formatındadır. iOS'ta WebAuthn kaynağı, RP web kaynağıdır (örn. `https://paypal.com`). Her iki durumda da, yerel uygulamanız ile sunucu arasındaki güven, ilgili ilişkilendirme dosyası aracılığıyla doğrulanır (bkz. [aşağıda](#configuring-relying-party-native-apps)). Yerel uygulamalar için kaynak doğrulamasının nasıl çalıştığına dair ayrıntılı bilgi için, yerel uygulamalar için WebAuthn kaynak doğrulamasına ilişkin özel kılavuzumuza bakın._ ## 3. Yerel Uygulamalar için İki Farklı Entegrasyon Seçeneği Yerel bir uygulamada geçiş anahtarlarını uygulamak için bir geliştirici, bunları [WebView](https://www.corbado.com/blog/native-app-passkeys) aracılığıyla veya yerel olarak (natively) ekleme arasında karar verebilir. Aşağıda her iki yaklaşımın avantajlarını ve dezavantajlarını inceleyelim. ### 3.1 WebView Üzerinden Geçiş Anahtarı Entegrasyonu ![Passkey Integration WebView (GitHub)](https://www.corbado.com/website-assets/650c601b1eb462e25702a870_android_webview_passkey_github_8bc81d9852.jpg) Geçiş anahtarlarını entegre etmek için bir **WebView**\* kullanmak, kimlik doğrulama sürecini yönetmek için [yerel uygulama](https://www.corbado.com/tr/blog/yerel-uygulama-passkeys) içine bir web tarayıcısı gömmek anlamına gelir. Bu yaklaşım, temel olarak uygulama içinde bir web sayfası görüntüler ve web tabanlı kimlik doğrulama akışlarını yerel platform için yeniden yazmak zorunda kalmadan yeniden kullanmayı kolaylaştırır. Ancak bazı dezavantajları vardır. [WebView](https://www.corbado.com/blog/native-app-passkeys)'lar tüm geçiş anahtarı özelliklerini desteklemeyebilir ve güvenli bir şekilde uygulanmazsa "ortadaki adam" (man-in-the-middle) saldırısı riski potansiyeli taşır. Ayrıca, kullanıcı deneyimi yerel entegrasyonlardaki kadar pürüzsüz olmayabilir ve farklı cihazlar ve işletim sistemi sürümlerinde tutarlı davranış sağlamada zorluklar yaşanabilir. _\*Birden çok_ _WebView_ _türü vardır: iOS'ta (OAuth/OpenID Connect tabanlı kimlik doğrulama akışları için WKWebView, SFSafariViewController veya SFAuthenticationSession / ASWebAuthenticationSession) ve Android'de (WebView, CCT-Chrome Custom Tabs). Ayrıntılar için bu blog yazısına bakın. Yerel bir entegrasyon istemiyorsanız geçiş anahtarları bağlamında SFSafariViewController/ ASWebAuthenticationSession ve Chrome Custom Tabs kullanmanızı öneririz._ ### 3.2 Yerel Geçiş Anahtarı Entegrasyonu ![Native Passkey Integration (Kayak)](https://www.corbado.com/website-assets/650c625cac723f594137a029_android_native_passkey_kayak_0f689e761e.jpg) **Yerel entegrasyon**, platforma özgü API'leri ve kütüphaneleri kullanarak geçiş anahtarı işlevselliğini doğrudan [iOS](https://www.corbado.com/blog/how-to-enable-passkeys-ios) veya [Android](https://www.corbado.com/blog/how-to-enable-passkeys-android) uygulamasında oluşturmayı içerir. Bu yöntem, [yerel uygulama](https://www.corbado.com/tr/blog/yerel-uygulama-passkeys) ile bir [WebView](https://www.corbado.com/blog/native-app-passkeys) arasında geçiş yapma ihtiyacı olmadığı için daha pürüzsüz bir kullanıcı deneyimi sunar. Aynı zamanda daha iyi performans ve daha tutarlı bir görünüm ve his sağlar. Güvenlik açısından bakıldığında, yerel entegrasyon özellikle platforma özgü güvenlik özellikleriyle birleştirildiğinde belirli saldırı türlerine karşı artırılmış koruma sunabilir. Ancak, geliştiricilerin her platform (Android ve [iOS](https://www.corbado.com/blog/how-to-enable-passkeys-ios)) için ayrı kod yazması ve sürdürmesi gerektiğinden uygulama çabası daha yüksek olabilir. Ek olarak, en son geçiş anahtarı / WebAuthn spesifikasyonlarıyla güncel kalmak daha sık uygulama güncellemeleri gerektirebilir. Aşağıda, yerel geçiş anahtarı entegrasyonuna odaklanıyoruz. ## 4. Yerel Uygulamalar için Relying Party'yi Yapılandırma Yerel uygulamalar (örn. [iOS](https://www.corbado.com/blog/how-to-enable-passkeys-ios) veya [Android](https://www.corbado.com/blog/how-to-enable-passkeys-android) uygulamaları) web uygulamalarına kıyasla bir zorluk sunar. Web uygulamalarından farklı olarak, Relying Party ID ile eşleştirilecek bir tarayıcı URL'si yoktur. Bununla birlikte, aynı güvenlik seviyesini sağlamak için etki alanları yerel uygulamalara **ilişkilendirme dosyaları (association files)** aracılığıyla bağlanır, böylece bir etki alanı ile yerel bir uygulama arasında güven oluşturulur. Bu, özellikle bir geçiş anahtarı bir web uygulamasında oluşturulduysa ve yerel bir uygulamada aynı Relying Party ID için kullanılacaksa (ve tersi) önemlidir. ### 4.1 iOS'ta İlişkilendirme Dosyaları: apple-app-site-association iOS, apple-app-site-association dosyasını kullanır. Bu dosya çeşitli yetkilendirmeler (entitlements) içerir, ancak WebAuthn ve geçiş anahtarları için webcredentials yetkilendirmesi önemlidir. ```json { "webcredentials": { "apps": ["9RF9KY88B2.com.corbado.passkeys"] } } ``` webcredentials.apps içinde Uygulama Tanımlayıcı Ön Ekinizi (Application Identifier Prefix) (örn. `9RF9KY77B2`) ve Paket Tanımlayıcınızı (Bundle Identifier) (örn. `com.corbado.passkeys`) saklamanız gerekir. iOS yerel uygulamalarının çalışması için apple-app-site-association dosyasının Relying Party ID'lerinin `/.well-known` dizininde (`https:///.well-known/apple-app-site-association`) saklanması gerekir. Canlı bir örneği [buradan](https://pro-6244024196016258271.frontendapi.cloud.corbado.io/.well-known/apple-app-site-association) görebilirsiniz. ### 4.2 Android'de İlişkilendirme Dosyaları: assetlinks.json [Android](https://www.corbado.com/blog/how-to-enable-passkeys-android), `assetlinks.json` dosyasını kullanır, bu dosya iOS muadili gibi WebAuthn ve geçiş anahtarları için belirli yapılandırmalar gerektirir. ```json [ { "relation": [ "delegate_permission/common.handle_all_urls", "delegate_permission/common.get_login_creds" ], "target": { "namespace": "android_app", "package_name": "com.corbado.passkeys.pub", "sha256_cert_fingerprints": [ "F8:90:4E:9A:99:01:71:75:25:38:D5:36:16:2D:B3:65:EB:41:51:D4:53:9A:72:BC:4B:56:C5:16:43:62:E2:C0" ] } } ] ``` `delegate_permission/common.handle_all_urls` ve `delegate_permission/common.get_login_creds` ilişki değerlerinin (relation values) ayarlanmış olması gerekir. Ayrıca paket adınızı ve imzalama sertifikanızın SHA-256 parmak izini eklemeniz gerekir. Bir geçiş anahtarının yerel bir uygulama ile bir web uygulaması arasında paylaşılmasına izin vermek için iki giriş (entry) eklemeniz gerekir. Biri namespace web için ve diğeri namespace android_app için. Canlı bir örneği [buradan](https://pro-6244024196016258271.frontendapi.cloud.corbado.io/.well-known/assetlinks.json) görebilirsiniz. Android uygulamalarının çalışması için assetlinks.json dosyasının Relying Party ID'lerinin `/.well-known` dizini altında `https:///.well- known/assetlinks.json` konumunda saklanması gerekir - yani iOS'taki gibi. Yerel bir Android / iOS uygulaması ile bir web uygulaması arasında geçiş anahtarlarını paylaşan örnek bir uygulamayı görmek için bu blog yazısına göz atın. ## 5. Yerel Bir Uygulama ile Web Uygulaması Arasında Güven Oluşturma ### 5.1 iOS Bir iOS uygulaması ile web uygulaması arasında güven oluşturma süreci şu şekildedir: 1. iOS uygulaması geliştiricisinin yerel uygulama ile ilişkilendirmek istediği etki alanlarının bir listesini belirtmesi gerekir. Bu etki alanları, iOS uygulamasının yetkilendirmelerine kodlanmıştır (hardcoded), örneğin: - webcredentials:auth.Corbado.com - webcredentials:\*.Corbado.com 2. iOS uygulaması her yüklendiğinde veya güncellendiğinde, iOS, iOS uygulaması yetkilendirme listesinin her girişi için apple-app-site-association dosyasını indirir. 3. Bir iOS uygulaması içinde bir kimlik bilgisi (örn. geçiş anahtarı) oluşturulduğunda, iOS uygulaması aşağıdaki iki yönü kontrol ederek ilgili taraf sunucusunun etki alanının iOS uygulamasıyla ilişkili olup olmadığını doğrular: - Cihazda bu ilgili taraf (relying party) sunucusunun etki alanı için bir `apple-app-site-association` dosyası mevcut mu? - iOS uygulaması o `apple-app-site-association` dosyasında listeleniyor mu? Eğer, ve sadece eğer, her iki soruya da evet yanıtı verilebiliyorsa, iOS uygulaması içinde bir geçiş anahtarı oluşturulabilir. ### 5.2 Android Bir Android uygulaması ile web uygulaması arasında güven oluşturma süreci şu şekildedir: 1. Android uygulaması geliştiricisinin Android uygulaması ile ilişkilendirmek istediği etki alanlarının bir listesini belirtmesi gerekir. Bu etki alanları assetlinks.json dosyasında namespace web'e sahip hedefler (targets) olarak saklanır. Android uygulamaları ve web uygulamalarının kimlik bilgilerini paylaştığını beyan etmek için `delegate_permission/common.get_login_creds` belirtilmelidir. Ayrıntıları [burada](https://developer.android.com/training/sign-in/passkeys#add-support-dal) bulabilirsiniz. 2. Android uygulaması içinde bir geçiş anahtarı oluşturulursa, Android uygulaması `assetlinks.json` dosyasını kontrol ederek Relying Party ID'nin Android uygulamasıyla ilişkili olup olmadığını doğrular: - `https://./well-known/assetlinks.json` adresinde bu Relying Party ID için bir `assetlinks.json` dosyası var mı - Android uygulaması bir hedef olarak doğru bir şekilde tanımlanmış mı. 3. Eğer, ve sadece eğer, her iki soruya da evet yanıtı verilebiliyorsa, Android uygulaması içinde bir geçiş anahtarı oluşturulabilir. Aşağıdaki diyagram, bu güven oluşturma süreçlerini yan yana karşılaştırmaktadır. ## 6. Android, iOS ve Flutter Ayarlarına Genel Bakış Aşağıda, yerel uygulamalar için geçiş anahtarı kimlik doğrulamasını doğru bir şekilde ayarlamak için gereken farklı ayarların ayrıntılı bir özetini sunuyoruz. | Özellik | iOS | Android | | ------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Yerel geçiş anahtarı kimlik doğrulaması için resmi uygulama rehberi | Apple Developer | Google Developer | | Web uygulamaları ile geçiş anahtarlarının paylaşılmasına izin verir | Evet, apple-app-site-association dosyası ile | Evet, assetlinks.json ile | | İlişkilendirme dosyasının konumu | [https://acme.com/.well-known/apple-app-site-association](https://acme.com/.well-known/apple-app-site-association) | [https://acme.com/.well-known/assetlinks.json](https://acme.com/.well-known/assetlinks.json) | | Dosya önbelleğe alındı | Evet (iOS 14'ten beri), ilk senkronizasyon 24 saati bulabilir | Evet (Play Services tarafından) | | Atlamak (By-pass) mümkün | Evet, alternate mode bölümü ile | Hayır | | Şununla test edilebilir | apple-app-site-association test | assetlinks.json test | | Örnekle uygulama tanımlayıcısı | `.`, örn. `T84QZS65DQ.com.facebook.Messenger` | SHA256 fingerprint,örn. `E3:F9:E1:E0:CF:99:D0:E5:6A:05:5B:A6: 5E:24:1B:33:99: 7F:CE:A5:24:32: 6B:0C:DD:6E:C1:32: 7E:D0:FD:C1` | | Uygulama tanımlayıcısı nerede bulunur | Team Application Identifier Prefix, developer.apple.com'daki geliştirici hesabında bulunabilir ve Bundle Identifier, XCode projesi içindeki tam addır | Halihazırda yüklendiğinde: Google Play Console > Release management > App signing Yerel: `keytool -list -v -keystore -alias -storepass -keypass ` | | Uygulamayı web'e bağlayan bölümün adı | applinks (geçiş anahtarları için gerekli değildir) | `delegate_permission/common.handle_all_urls` (geçiş anahtarları için gereklidir) | | Uygulama / web arasında kimlik bilgisi paylaşımına izin veren bölüm | webcredentials | `delegate_permission/common.get_login_creds` | | Tüm ilişkilendirme dosyalarının kaydı | XCode geliştirme ortamında etkinleştirin ve ilişkilendirilmiş etki alanını ekleyin (entitlements dosyası oluşturmak için özelliğin ayarlanması) | Credential Manager API kullanıldığında, bildirimdeki assetlinks.json kaydı geçiş anahtarları için gerekli değildir (ancak parolalar için gereklidir). Credential Manager API kullanmıyorsanız, belirli aktivitede (Android App Kaynak Kodunun bir parçası) AndroidManifest.xml içindeki `` girişiyle ana bilgisayar adlarını listelemeniz gerekir. ``'in autoVerify=true olması gerekir. | [Flutter](https://www.corbado.com/blog/flutter-passkeys-package) için, ilgili Android veya iOS kuralı geçerlidir. Tek [Flutter](https://www.corbado.com/blog/flutter-passkeys-package)'a özgü ayar, ilişkilendirme dosyalarının kaydıdır; şunları eklemelisiniz: - Android için:[ flutter_deeplinking_enabled to AndroidManifest.xml](https://docs.flutter.dev/cookbook/navigation/set-up-app-links) - iOS için: [FlutterDeepLinkingEnabled true to Info.plist](https://docs.flutter.dev/cookbook/navigation/set-up-universal-links) ## 7. Geçerli ve Geçersiz Relying Party ID ve İlişkilendirme Dosyalarına Örnekler Relying Party ID'lerle, farklı seviyelerdeki (alt) alan adları ve CNAME'lerle çalışmanın oldukça zorlayıcı bir görev olabileceğini deneyimlediğimizden, dört farklı örnek sunuyor ve bunların neden ve nasıl çalıştıklarını açıklıyoruz. CNAME tablo satırının geçiş anahtarı kimlik doğrulaması için gerekli olmadığını ve yalnızca eklemek istediğimiz araştırmamızın bir sonucu olduğunu unutmayın. ### 7.1 Örnek 1: Relying Party Kök Etki Alanıdır | **Relying Party ID** | corbado.com | | ------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------ | | **Entitlements (yalnızca iOS)** | webcredentials:corbado.com | | **apple-app-site-association dosyasının konumu** | [https://corbado.com/.well-known/apple-app-site-association](https://corbado.com/.well-known/apple-app-site-association) | | **assetlinks.json dosyasının konumu** | [https://corbado.com/.well-known/assetlinks.json](https://corbado.com/.well-known/assetlinks.json) | | **CNAME** | n/a | Bu örnekte, Corbado.com için `apple-app-site-association` / `assetlinks.json` dosyası, yerel uygulama yüklendiğinde / güncellendiğinde hiçbir sorun olmadan indirilebilir, çünkü dosya Relying Party ID ile aynı konumdadır. **Relying Party ID için bir geçiş anahtarı oluşturulabilir.** ### 7.2 Örnek 2: Relying Party Bir Alt Alan Adıdır ve CNAME Ayarlanmıştır | Relying Party ID | auth.corbado.com | | ------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------- | | **Entitlements (yalnızca iOS)** | webcredentials:auth.corbado.com | | **apple-app-site-association dosyasının konumu** | [https://pro-123.passkeys.eu/.well-known/apple-app-site-association](https://pro-123.passkeys.eu/.well-known/apple-app-site-association) | | **assetlinks.json dosyasının konumu** | [https://pro-123.passkeys.eu/.well-known/assetlinks.json](https://pro-123.passkeys.eu/.well-known/assetlinks.json) | | **CNAME** | auth.corbado.com => pro-123.passkeys.eu | Bu örnekte, auth.corbado.com için `apple-app-site-association` / `assetlinks.json` dosyası, yerel uygulama yüklendiğinde / güncellendiğinde hiçbir sorun olmadan indirilebilir; çünkü dosya, Relying Party ID ile aynı konumdadır, zira CNAME Relying Party ID'den saklanan konuma işaret eder. **Relying Party ID için bir geçiş anahtarı oluşturulabilir.** ### 7.3 Örnek 3: Relying Party Kök Etki Alanıdır ve CNAME Ayarlanmıştır | Relying Party ID | corbado.com | | ------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------- | | **Entitlements (yalnızca iOS)** | webcredentials:corbado.com; webcredentials:auth.corbado.com | | **apple-app-site-association dosyasının konumu** | [https://pro-123.passkeys.eu/.well-known/apple-app-site-association](https://pro-123.passkeys.eu/.well-known/apple-app-site-association) | | **assetlinks.json dosyasının konumu** | [https://pro-123.passkeys.eu/.well-known/assetlinks.json](https://pro-123.passkeys.eu/.well-known/assetlinks.json) | | **CNAME** | auth.corbado.com => pro-123.passkeys.eu | Bu örnekte, auth.corbado.com için `apple-app-site-association` / `assetlinks.json` dosyası, yerel uygulama yüklendiğinde / güncellendiğinde hiçbir sorun olmadan indirilebilir, çünkü CNAME nedeniyle dosya `auth.corbado.com`'un beklediği konumdadır. FAKAT: corbado.com için `apple-site-association-file` / `assetlinks.json`, yerel uygulama yüklendiğinde / güncellendiğinde indirilemez; çünkü dosya beklenen yer olan `https://corbado.com/.well-known/apple-app-site-association` / `https://corbado.com/.well-known/assetlinks.json` adresinde değildir ve ona işaret eden hiçbir CNAME yoktur. **Relying Party ID için bir geçiş anahtarı oluşturulamaz.** ### 7.4 Örnek 4: Relying Party Bir Alt Alan Adıdır ve Wildcard Entitlement Ayarlanmıştır | Relying Party ID | auth.corbado.com | | ------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------ | | **Entitlements (yalnızca iOS)** | webcredentials:\*.corbado.com | | **apple-app-site-association dosyasının konumu** | [https://corbado.com/.well-known/apple-app-site-association](https://corbado.com/.well-known/apple-app-site-association) | | **assetlinks.json dosyasının konumu** | [https://corbado.com/.well-known/assetlinks.json](https://corbado.com/.well-known/assetlinks.json) | | **CNAME** | n/a | Bu örnekte, corbado.com için `apple-app-site-association` dosyası, yerel uygulama yüklendiğinde / güncellendiğinde hiçbir sorun olmadan indirilebilir, çünkü dosya beklendiği yerdedir ve webcredentials yetkilendirmesi (`*.corbado.com`) Relying Party ID'si (`auth.corbado.com`) ile eşleşir. Android (wildcard) yetkilendirmeler gibi bir şeyle çalışmadığı için bu örneğin Android'de çalışmadığını unutmayın. Genel olarak, Relying Party ID'lerini bu şekilde tanımlamak önerilmez. **Relying Party ID için bir geçiş anahtarı oluşturulabilir.** ## 8. Yaygın Relying Party ID Hataları ve Bunlardan Nasıl Kaçınılır ### 8.1 Relying Party ID'sini Alt Alan Adından Kök Etki Alanına Değiştirme **Hata:** Geliştirmeye başladınız ve Relying Party ID'niz olarak bir alt alan adı (örn. `login.acme.com`) tanımladınız. İlk kullanıcılar bu Relying Party ID için bir geçiş anahtarı oluşturdu. Ardından, bu geçiş anahtarlarına başka bir alt alan adında (örn. `app.acme.com`) kimlik doğrulama için de ihtiyacınız olduğunu fark edersiniz. Yeni alt alan adı için bir kullanıcının kaynağı ve Relying Party ID eşleşmediğinden, kullanıcı geçiş anahtarıyla oturum açamaz. WebAuthn ayarlarınızdaki Relying Party ID'yi `acme.com` olarak değiştirmek, yeni kaynak ile mevcut geçiş anahtarlarında saklanan Relying Party ID eşleşmeyeceği için mevcut tüm geçiş anahtarlarını geçersiz kılar. **Çözüm:** Relying Party ID'nizi tanımlarken başlangıçta iki kez kontrol edin çünkü bu az çok kalıcıdır. Emin değilseniz ve geleceğe hazır olmak istiyorsanız, yani gelecekte diğer alt alan adlarının kimlik doğrulama için geçiş anahtarına ihtiyaç duyabileceğini düşünüyorsanız, [Genel Son Ek Listesinde](https://publicsuffix.org/learn/) (Public Suffix List) yer almadığı sürece Relying Party ID olarak kök etki alanını (örn. acme.com) kullanmanızı öneririz. ### 8.2 Yerel ve Web Uygulaması için Farklı Relying Party ID'leri **Hata:** Eşzamanlı olarak yerel ve web uygulaması geliştiriyorsunuz. İşleri hızlandırmak için iki farklı WebAuthn sunucusu (yerel ve web uygulaması için farklı Relying Party ID'leri ile) kullanıyorsunuz. Kullanıcılarınız ilk geçiş anahtarlarını oluşturdukça, ilgili Relying Party ID geçiş anahtarında saklanır. Aynı geçiş anahtarıyla cihazlar arası / platformlar arası oturum açmaya izin vermek, örn. bir web uygulamasında oluşturulan bir geçiş anahtarı ile ve yerel bir uygulamada oturum açmaya çalışmak artık mümkün değildir. İki WebAuthn sunucusunu birleştirmek, eski WebAuthn sunucusuna (eski Relying Party ID) kayıtlı geçiş anahtarlarını terk edecek ve kullanıcılarınız bu geçiş anahtarlarıyla oturum açamayacaktır. **Çözüm:** Birden fazla uygulamanız varsa (örn. bir web uygulaması ve yerel bir uygulama), her zaman tek bir WebAuthn sunucunuz olsun ve tüm uygulamalarınız için yalnızca bir Relying Party ID tanımlayın. Bu uygulamalar arasındaki bağlantı, yukarıda açıklanan adımlarla yapılabilir. ### 8.3 Geçersiz ve Erişilemeyen İlişkilendirme Dosyaları **Hata:** Uygulamanızı geliştirmeye başladınız, ilişkilendirme dosyalarını yapılandırdınız ve bunları sunucunuza dağıttınız. Bazı nedenlerden dolayı hala hata mesajları alıyorsunuz ve temel nedeni bulamıyorsunuz. **Çözüm:** Hata mesajının olası bir nedeni, hatalı biçimlendirilmiş veya ulaşılamaz bir ilişkilendirme dosyası olabilir. Herhangi bir ilişkilendirme dosyasını sunucuya dağıtmadan önce, [iOS ](https://branch.io/resources/aasa-validator/)ve Android için sağlanan araçlar aracılığıyla bir ilişkilendirme dosyasının geçerliliğini ve erişilebilirliğini (genellikle bu dosyalar Apple ve Google'ın tarayıcıları için uygun erişimi engelleyen [sağlam bir VPN](https://cybernews.com/best-vpn/most-secure-vpns/) veya güvenlik duvarı arkasında olabilir) kontrol etmenizi şiddetle tavsiye ederiz. ### 8.4 apple-app-site-association Dosyası Henüz Apple CDN Tarafından Önbelleğe Alınmadı **Hata:** apple-app-site-association dosyanızı sunucunuza dağıttınız ve test cihazınızda hemen bir geçiş anahtarı oluşturmaya başlamak istiyorsunuz. Bazı nedenlerden dolayı geçiş anahtarını oluşturamıyorsunuz ve hata mesajları alıyorsunuz. **Çözüm:** Bu hata mesajlarının arkasındaki neden, iOS cihazlarının Relying Party'yi doğrulamak için `apple- app-site-association` dosyasını indirmesidir. Bunu yapmak için, iOS cihazları sunucunuza doğrudan bir istek göndermez, bunun yerine bir CDN kullanır. Hem cihaz hem de CDN, başarıyla alındıktan sonra `apple-app-site- association` dosyasını önbelleğe alır. Bu önbelleğe alma işlevi nedeniyle, `apple-app-site-association` dosyanızdaki yeni değişiklikler uygulamanıza doğrudan yansıtılmaz. CDN'nin `apple-app-site-association` dosyasını önbelleğe alması 24 saati bulabilir. Geliştirme sırasında bu kısıtlamayı aşmak için, Relying Party ID'sine `?mode=developer` ekleyebilir ve önbelleğe almayı tamamen devre dışı bırakabilirsiniz (örn. Relying Party ID `acme.com?mode=developer` olacaktır). ### 8.5 Android Emülatörü ve API Sürümü Uyumsuzluğu **Hata:** Bir Android uygulaması geliştirmeye başlıyorsunuz ve bunu bir Android emülatöründe test etmek istiyorsunuz. Bazı nedenlerden dolayı, Android emülatörünü düzgün bir şekilde kurmuş olmanıza ve diğer uygulamalar üzerinde sorunsuz çalışıyor gibi görünmesine rağmen hata mesajları alıyorsunuz. **Çözüm:** Bir geçiş anahtarı uygulamasını test ederken Android sürümleri, Play Store desteği ve API sürümleri önemli bir rol oynar. Ayrıca, bir Google hesabına giriş yapmış olmanız gerekir. Ayrıntılar için lütfen sorun giderme bölümümüze bakın. ## 9. Tavsiye ### 9.1 Genel Tavsiye Genel tavsiyemiz, Relying Party ID'nizi uygulama ortamınıza ve gereksinimlerinize göre dikkatlice seçmenizdir. Aşağıda, en yaygın kullanım durumlarını derledik, ancak genel tavsiyemiz **kök etki alanınızı Relying Party ID olarak seçmeyi hedeflemeniz** ve kimlik doğrulamanızı bu şekilde yapılandırmanız gerektiğidir. Corbado ile, bunu sizin için önceden de bu şekilde yapılandırdık (tüm teknik kurulumlar için sorunsuz geçiş anahtarı kimlik doğrulaması sunma yaklaşımımızın bir parçası olduğu için. UI bileşenlerimiz ve SDK'larımız, kök etki alanınızla Relying Party ID olarak kullanılmaya hazırdır). | Durum | Tavsiye | | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **A) Bir kök etki alanınız var:**

Örnek: acme.com

Tüm uygulamalar ve kimlik doğrulama bu kök etki alanında veya bunun alt alan adlarında çalışır | ✔️ Web veya yerel uygulamalar için herhangi bir soruna neden olmayacağından, Relying Party ID'niz olarak kök etki alanını seçin. | | **B) Birden fazla kök etki alanınız var:**

Örnek: kayak.com, kayak.co.uk, kayak.de

Kullanıcılarınıza farklı uluslararası üst düzey alan adlarından (top-level domains) hizmet veriyorsunuz. ABD için Kayak.com ve İngiltere için kayak.co.uk veya aynı kullanıcıların aynı geçiş anahtarlarıyla oturum açmasına izin vermesi gereken tamamen farklı kök etki alanlarına sahipsiniz. | ⚠️ Web uygulamalarınızda geçiş anahtarlarını paylaşmak, belirtilen kaynakların ortak bir RP ID kullanmasına izin vermek için `.well-known/webauthn` aracılığıyla Related Origin Requests yapılandırmasını gerektirir (tarayıcı desteği değişir; uyumluluğu doğrulayın). Alternatif olarak, ortak bir kimlik doğrulama kök etki alanı seçin.

✔️ Kök ilişkilendirme dosyaları üzerinde kontrole sahip olduğunuz sürece yerel uygulamalarınızı istediğiniz sayıda kök etki alanına bağlayabilirsiniz.

❌ Daha sonra web sitenizi barındırmak için başka bir kök etki alanına geçmek isterseniz, halihazırda oluşturulmuş geçiş anahtarlarınızı kullanamazsınız; çünkü yeniden markalaşmanız ve alan adını (Relying Party ID) değiştirmeniz gerekecektir. | | **C) Henüz bir kök etki alanınız YOK, yalnızca arka uçta (backend) veya genel bir alt alan adında (public subdomain) çalışıyorsunuz. Bunun olabileceği bazı durumlar vardır:**

1. Kök etki alanının kontrolünüz altında olmadığı (kök etki alanı [https://publicsuffix.org/](https://publicsuffix.org/) adresinde listelenmiştir) serbestçe kullanılabilen bir alt alan adında çalışıyorsunuz, örneğin CDN URL'leri

2. Yerel bir uygulama üzerinde çalışıyorsunuz. | ❌ Genel alt alan adlarında, kök etki alanının kök seviyesindeki ilişkilendirme dosyalarını kontrol edemezsiniz. Bu nedenle, geçiş anahtarları yerel olarak (natively) çalışmaz.

⚠️ Bazı hizmetler için bunu düzeltmenin tek yolu, bir CNAME tanımlayabileceğiniz veya kendiniz için özel bir kök etki alanı alabileceğiniz ücretli bir plana geçmektir. | ### 9.2 Corbado Kullanırken Tavsiye Aşağıda, geçiş anahtarı çözümünüz olarak Corbado'yu kullanırken doğru Relying Party ID'yi ve ilişkilendirme dosyalarını nasıl yöneteceğinizi / barındıracağınızı belirlemenize yardımcı olacak çok spesifik bir karar ağacı sunuyoruz. İlk karar, geliştirme veya üretim ortamında olup olmadığınızdır. Vermeniz gereken bir sonraki karar seviyesi, uygulama yapınıza (landscape) bağlıdır: yalnızca yerel bir uygulamanız mı var yoksa yerel ve web uygulamanız mı var. #### A) Geliştirme Geliştirme ortamı için, hızlı bir şekilde geliştirmeye ve test etmeye başlamak istediğinizi varsayıyoruz. Canlıya geçmek isterseniz Relying Party ID daha sonra değiştirilebilir. ##### A1) Yalnızca Yerel - Relying Party ID'yi Ayarla = `pro-XXX.frontendapi.cloud.corbado.io` (varsayılan değer) - Corbado ilişkilendirme dosyasını sizin için barındırır - Sizin için DNS Yapılacaklar (ToDo) yok ##### A2) Yerel Uygulama ve Web Uygulaması Hem web uygulamasını hem de yerel uygulamayı aynı anda test etmek kolayca mümkün değildir **1. Seçenek:** Ya Relying Party ID'yi = `pro-XXX.frontendapi.cloud.corbado.io` olarak ayarlarsınız (yerel uygulama çalışır) VEYA Relying Party ID'yi = `localhost` olarak ayarlarsınız (web uygulaması çalışır) **2. Seçenek:** Yerel ve web uygulamasının aynı anda çalışması için tek çözüm, yerel bir ters proxy (reverse proxy) kullanmaktır (oldukça hileli / hacky bir çözümdür): - Relying Party ID'yi Ayarla = `acme-dev.com` - `acme-dev.com`'dan CNAME'i şuna ayarla => `pro-XXX.frontendapi.cloud.corbado.io` - Yerel `/etc/hosts` girişine `localhost acme-dev.com` ekle - `acme-dev.com` => `localhost:3000` (örnek olarak) için kurallı ters proxy (nginx) ekle #### B) Üretim Üretim ortamında, Relying Party ID (örn. `auth.acme.com`) olarak bir alt alan adıyla ilgili bir sorununuz olup olmadığına veya Relying Party ID (örn. `acme.com`) olarak bir kök etki alanı isteyip istemediğinize karar vermelisiniz. ##### B1) Relying Party ID olarak Alt Alan Adı ###### B1.1) Yalnızca Yerel - Relying Party ID'yi Ayarla = `auth.acme.com` - Corbado ilişkilendirme dosyasını sizin için barındırır - `auth.acme.com`'dan CNAME'i şuna ayarla => `pro-XXX.frontendapi.cloud.corbado.io` ###### B1.2) Yerel Uygulama ve Web Uygulaması - Relying Party ID'yi Ayarla = `auth.acme.com` - Corbado ilişkilendirme dosyasını sizin için barındırır - `auth.acme.com`'dan CNAME'i şuna ayarla => `pro-XXX.frontendapi.cloud.corbado.io` (Corbado'nun oturum yönetimini kullanıyorsanız çerezlerin çalışması için de gereklidir) ##### B2) Relying Party ID olarak Kök Etki Alanı ###### B2.1) Yalnızca Yerel - Relying Party ID'yi Ayarla = `acme.com` - İlişkilendirme dosyasını kendi sunucunuzda `acme.com/.well-known/` adresinde kendiniz barındırın - Sizin için DNS Yapılacaklar (ToDo) yok ###### B2.2) Yerel Uygulama ve Web Uygulaması - Relying Party ID'yi Ayarla = `acme.com` - İlişkilendirme dosyasını kendi sunucunuzda `acme.com/.well-known/` adresinde kendiniz barındırın - Corbado'nun oturum yönetimini kullanıyorsanız, çerezlerin çalışmasını sağlamak için `auth.acme.com`'dan CNAME'i şuna ayarlamanız gerekir => `pro-XXX.frontendapi.cloud.corbado.io` (bu CNAME, yalnızca oturum yönetimi için Relying Party ID için gerekli değildir) Aşağıdaki karar ağacı tüm yapılandırma yollarını özetlemektedir. ## 10. Sonuç Relying Party ID, WebAuthn ve geçiş anahtarı tabanlı kimlik doğrulamanın temel taşıdır ve kimlik avına (phishing) karşı güçlü direnç sağlar. Bunu uygun şekilde yapılandırmak, etki alanı eşleştirme inceliklerini anlamak ve yerel uygulamalar için doğru dağıtımı sağlamak çok önemlidir. Bu blog yazısı size bunları nasıl doğru bir şekilde kuracağınızı ve farklı hatalarla nasıl başa çıkacağınızı gösterdi. rpID yapılandırmanız sağlamlaştığında, gerçek benimsemeyi artırmak için [geçiş anahtarı oluşturma](https://www.corbado.com/tr/blog/passkey-olusturma-en-iyi-uygulamalari) akışlarınızı ve geçiş anahtarı giriş akışlarınızı optimize etmeye odaklanın. Yerel uygulamalar için geçiş anahtarları ayarlama hakkında daha fazla bilgi edinmek için [Flutter](https://www.corbado.com/blog/flutter-passkeys-package)'da geçiş anahtarları hakkında okumanızı öneririz. Başka sorularınız varsa veya yardıma ihtiyacınız varsa, [bize ulaşmaktan](https://bit.ly/passkeys-community) çekinmeyin. ## Sıkça Sorulan Sorular (SSS) ### Relying Party ID, geçiş anahtarı kimlik doğrulamasında kimlik avını nasıl engeller? Kimlik doğrulayıcı, tarayıcının gerçek kaynağını (origin) geçiş anahtarında saklanan Relying Party ID ile karşılaştırır. Bir saldırgan farklı bir etki alanında sahte bir site barındırıyorsa, sahte meydan okuma (challenge) meşru bir RP ID iddia etse bile, kaynak uyuşmazlığı kimlik doğrulamanın otomatik olarak başarısız olmasına neden olur. Bu bağlayıcılık, paypal.com'a kayıtlı bir geçiş anahtarının paybal.com gibi benzer bir alanda kullanılamayacağı anlamına gelir. ### Kullanıcılar zaten geçiş anahtarları kaydettikten sonra WebAuthn Relying Party ID'mi değiştirirsem ne olur? RP ID'yi değiştirmek, mevcut tüm geçiş anahtarlarını geçersiz kılar çünkü her kimlik bilgisinde (credential) saklanan RP ID artık yeni değerle eşleşmeyecektir. Tek istisnalar, yeni RP ID'nin eskisinin bir alt alan adı olması veya `.well-known/webauthn` aracılığıyla Related Origin Requests'in yapılandırılmış olmasıdır. Bu geri döndürülemez sorunu önlemek için başından itibaren RP ID olarak kök etki alanını seçin. ### apple-app-site-association dosyasını dağıttıktan hemen sonra iOS geçiş anahtarım neden çalışmıyor? iOS, apple-app-site-association dosyasını doğrudan sunucunuzdan getirmez. Apple'ın CDN'ini kullanır, bu da yeni dağıtılan veya güncellenen bir dosyayı önbelleğe alması 24 saate kadar sürebilir. Geliştirme sırasında, önbelleğe almayı tamamen atlamak için Relying Party ID'sine `?mode=developer` ekleyin. ### Geçiş anahtarları için Relying Party ID'si olarak bir alt alan adı (subdomain) mı yoksa kök etki alanı (root domain) mı kullanmalıyım? Kök etki alanının (örn. acme.com) kullanılması önerilir, çünkü herhangi bir alt alan adında oluşturulan geçiş anahtarları, o kökün tüm alt alan adlarında kimlik doğrulaması yapabilir. Bir alt alan adı RP ID'si, geçiş anahtarı kullanımını o alt alan adı ve onun alt birimleriyle sınırlar; bu da daha sonra alt alan adları arası akışları (cross-subdomain flows) bozabilir. acme.com ve acme.co.uk gibi birden çok kök etki alanınız varsa, geçiş anahtarının bunlar arasında yeniden kullanılmasına izin vermek için `.well-known/webauthn` aracılığıyla Related Origin Requests yapılandırın.