--- url: 'https://www.corbado.com/hi/blog/webauthn-relying-party-id-rpid-passkeys' title: 'WebAuthn Relying Party ID (rpID) और पासकी (Passkeys): डोमेन और नेटिव ऐप्स' description: 'यह ब्लॉग पोस्ट पासकी ऑथेंटिकेशन के लिए WebAuthn Relying Party ID के बारे में बताता है। इसमें सही कॉन्फ़िगरेशन, डोमेन मिलान और नेटिव ऐप कॉन्फ़िगरेशन शामिल हैं।' lang: 'hi' author: 'Vincent Delitz' date: '2026-06-15T13:56:40.704Z' lastModified: '2026-06-16T06:07:43.300Z' keywords: 'relying party id, webauthn, पासकी, डोमेन मिलान, नेटिव ऐप, पासकी ऑथेंटिकेशन' category: 'WebAuthn Know-How' --- # WebAuthn Relying Party ID (rpID) और पासकी (Passkeys): डोमेन और नेटिव ऐप्स ## Key Facts - **Relying Party ID** प्रत्येक पासकी में एम्बेडेड एक डोमेन है। यदि ब्राउज़र ऑरिजिन मेल नहीं खाता है, तो ऑथेंटिकेशन विफल हो जाता है, जिससे पासकी अत्यधिक फ़िशिंग-प्रतिरोधी बन जाती है। - **RP ID** **Public Suffix List** में नहीं होना चाहिए और इसे बदलने से सभी मौजूदा पासकी अमान्य हो जाती हैं। भविष्य की सुरक्षा के लिए डिफ़ॉल्ट रूप से रूट डोमेन का उपयोग करें। - iOS ऐप्स के लिए RP ID के अंतर्गत `/.well-known/` पर एक **apple-app-site-association** फ़ाइल की आवश्यकता होती है। Android के लिए उसी पथ पर **assetlinks.json** की आवश्यकता होती है। नई फ़ाइलों को कैश होने में 24 घंटे तक का समय लग सकता है। - पासकी साझा करने के लिए कई रूट डोमेन को `.well-known/webauthn` के माध्यम से **Related Origin Requests** की आवश्यकता होती है। वेब और नेटिव, सभी ऐप्स के लिए एक RP ID के साथ एक ही WebAuthn सर्वर का उपयोग करें। ## 1. परिचय पासकी ऑथेंटिकेशन तेज़ी से आदर्श बनता जा रहा है क्योंकि [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) और Amazon जैसी तकनीकी दिग्गज कंपनियाँ इन्हें लागू कर रही हैं या पहले ही कर चुकी हैं। यह स्पष्ट है कि तकनीकी दुनिया सरल और सुरक्षित ऑथेंटिकेशन के महत्व को पहचान रही है। [Face ID](https://www.corbado.com/faq/is-face-id-passkey), Touch ID या [Windows Hello](https://www.corbado.com/glossary/windows-hello) के साथ ऑथेंटिकेट करने के सहज उपयोगकर्ता अनुभव से परे, पासकी पासवर्ड जैसे पारंपरिक ऑथेंटिकेशन तरीकों की तुलना में अद्वितीय सुरक्षा प्रदान करती हैं। इसकी एक प्रमुख विशेषता अत्यधिक फ़िशिंग-प्रतिरोध है। फ़िशिंग एक ऐसा हमला है जिसमें पीड़ित को एक नकली साइट पर क्रेडेंशियल प्रदान करने के लिए धोखा दिया जाता है जो मूल साइट होने की नकल करती है। उदाहरण के लिए, कल्पना करें कि आपको अपने बैंक से एक ईमेल प्राप्त होता है, जिसमें आपको लॉग इन करने के लिए कहा जाता है। आप लिंक पर क्लिक करते हैं, और वेबसाइट वैध लगती है, इसलिए आप अपने क्रेडेंशियल दर्ज करते हैं और हमलावर उनका उपयोग मूल साइट पर लॉग इन करने के लिए कर सकता है। डिजिटल युग में यह एक लगातार बढ़ती समस्या बनती जा रही है और यहाँ तक कि [Okta](https://www.darkreading.com/application-security/okta-flaw-involved-mgm-resorts-breach-attackers-claim) (एक ऑथेंटिकेशन प्रदाता!) या [Retool](https://retool.com/blog/mfa-isnt-mfa/) जैसी प्रमुख कंपनियाँ भी स्पीयर-फ़िशिंग हमलों (फ़िशिंग का एक विशेष रूप जहाँ लक्षित पीड़ितों को बहुत व्यक्तिगत फ़िशिंग चालों से फंसाया जाता है) का शिकार हुई हैं, जो मजबूत सुरक्षा उपायों की आवश्यकता पर जोर देती हैं। इसके विपरीत, यदि आप पासकी का उपयोग करते हैं, और साइट नकली है, तो आपका ऑथेंटिकेशन विफल हो जाएगा। ऐसा इसलिए है क्योंकि पासकी **Relying Party ID** के माध्यम से उन डोमेन से बंधी होती हैं जिनके लिए उन्हें बनाया गया था। > आप किसी अन्य साइट पर पासकी के साथ लॉग इन नहीं कर सकते हैं जिससे पासकी अत्यधिक > फ़िशिंग-प्रतिरोधी बन जाती है (हालाँकि कोई भी सिस्टम सभी हमले वैक्टर से पूरी तरह > प्रतिरक्षित नहीं है)। यह तंत्र WebAuthn में बेक किया गया है, जो पासवर्डलेस ऑथेंटिकेशन के लिए पासकी-आधारित वेब मानक है। WebAuthn दो मुख्य समारोहों पर बनाया गया है: पंजीकरण और ऑथेंटिकेशन समारोह। पंजीकरण (साइन-अप) समारोह के दौरान वेब या नेटिव ऐप के माध्यम से एक ऑनलाइन सेवा (Relying Party) के लिए एक नई पासकी बनाई जाती है। इस प्रक्रिया में, वह डोमेन (Relying Party ID) जिसके लिए पासकी बनाई जाती है, पासकी में सेव हो जाता है। यह ऑथेंटिकेशन (लॉगिन) समारोह को यह जांचने की अनुमति देता है कि क्या ऑनलाइन सेवा (Relying Party), जिससे वेब या नेटिव ऐप संबंधित है, पासकी में सेव की गई [Relying Party](https://www.corbado.com/glossary/relying-party) ID से मेल खाती है। निम्नलिखित में, हम विस्तार से देखेंगे कि यह [डोमेन मिलान](#what-relying-party-id) प्रक्रिया कैसे काम करती है और विशेष रूप से, नेटिव ऐप्स कैसे सुरक्षित हैं। ## 2. Relying Party ID क्या है? [**Relying Party ID**](https://www.w3.org/TR/webauthn-2/#relying-party-identifier) अनिवार्य रूप से पासकी के भीतर सेव किया गया एक डोमेन है, जो यह सुनिश्चित करता है कि पासकी तभी काम करती है जब वर्तमान ब्राउज़र URL (उपयोगकर्ता का ऑरिजिन जो स्वचालित रूप से प्रत्येक अनुरोध पर भेजा जाता है) इससे मेल खाता है (नीचे नेटिव ऐप दृष्टिकोण [देखें](#integration-options-native-apps))। यह WebAuthn विनिर्देश का एक महत्वपूर्ण घटक है, जिसके बारे में आप [यहाँ](https://www.w3.org/TR/webauthn-2/) अधिक जान सकते हैं। [Relying Party](https://www.corbado.com/glossary/relying-party) ID रूट डोमेन (उदा. `corbado.com`) या सबडोमेन (`auth.corbado.com`) हो सकता है। यदि यह पब्लिक सफिक्स लिस्ट में है तो आप रूट डोमेन को [Relying Party](https://www.corbado.com/glossary/relying-party) ID के रूप में सेव नहीं कर सकते (पब्लिक सफिक्स डिटेक्शन के लिए सूची और लाइब्रेरी [यहाँ](https://publicsuffix.org/learn/) खोजें)। किसी ऑनलाइन सेवा के लिए Relying Party ID बदलने से मौजूदा पासकी टूट जाएंगी (अपवाद: नई Relying Party ID पुरानी Relying Party ID का एक सबडोमेन है, या संबंधित डोमेन में पासकी के पुन: उपयोग की अनुमति देने के लिए `.well-known/webauthn` के माध्यम से Related Origin Requests कॉन्फ़िगर किए गए हैं)। ऑथेंटिकेशन प्रक्रिया के दौरान, Relying Party ID को ब्राउज़र URL (उपयोगकर्ता का ऑरिजिन) के विरुद्ध जांचा जाता है ताकि यह सुनिश्चित हो सके कि वे मेल खाते हैं। इस अर्थ में मिलान का अर्थ है कि या तो: - ब्राउज़र URL (उपयोगकर्ताओं का ऑरिजिन) Relying Party ID से पूरी तरह मेल खाता है या - ब्राउज़र URL (उपयोगकर्ता का ऑरिजिन) एक सबडोमेन है जो Relying Party ID से मेल खाता है और पैरेंट डोमेन पंजीकृत करने योग्य है (उदा. `com` या Public Suffix List पर कोई भी डोमेन काम नहीं करता है) यहाँ एक विस्तृत रूपरेखा दी गई है कि किस _originalHost_ (दूसरा कॉलम) को अपने पैरेंट डोमेन तक पहुँचने की अनुमति है: ![relying party id table](https://www.corbado.com/website-assets/relying_party_id_table_4c98cc04f4.jpg) निम्नलिखित में, आप पार्स किए गए [**PublicKeyCredentialCreationOptions**](https://www.w3.org/TR/webauthn-2/#iface-pkcredential) देखते हैं: ```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 है। Relying Party ID के प्रमुख लाभों में से एक फ़िशिंग हमलों की रोकथाम है। निम्नलिखित परिदृश्य की कल्पना करें: 1. एक हमलावर एक [PayPal](https://www.corbado.com/blog/paypal-passkeys) क्लोन विकसित करता है जो एक नकली वेबसाइट है जो आपकी ओर से लॉग इन करने के लिए आपके [PayPal](https://www.corbado.com/blog/paypal-passkeys) क्रेडेंशियल चुराने का प्रयास करती है और हमलावरों के खाते में पैसे भेजती है। यह नकली [PayPal](https://www.corbado.com/blog/paypal-passkeys) वेबसाइट डोमेन paybal.com पर होस्ट की गई है (इसलिए पहली नज़र में यह अक्सर दिखाई नहीं देता है कि यह एक अलग डोमेन है)। 2. आपने पहले ही वैध PayPal साइट के लिए पासकी बना ली है। इस पासकी ने Relying Party ID paypal.com को सेव कर लिया है। 3. आप paybal.com पर PayPal नकली वेबसाइट पर जाते हैं (चूंकि आप इस साइट पर जाते हैं, आपके अनुरोध का ऑरिजिन paybal.com\* है) और साइट आपके डिवाइस (ऑथेंटिकेटर) को Relying Party ID `paypal.com` के लिए एक चुनौती भेजती है (यहाँ यह आपको धोखा देने की कोशिश करती है) और आपको Relying Party ID paypal.com के लिए अपनी पासकी के साथ इस पर हस्ताक्षर करने के लिए कहती है। 4. आपका डिवाइस (ऑथेंटिकेटर) जांचता है कि क्या अनुरोध का ऑरिजिन (`paypal.com`) और पासकी में सेव की गई Relying Party ID (`paypal.com`) मेल खाती है। 5. चूंकि वे स्पष्ट रूप से मेल नहीं खाते हैं, इसलिए ऑथेंटिकेशन विफल हो जाता है और यह आपको किसी हमलावर को आपके PayPal खाते तक पहुंच देने से बचाता है। निम्नलिखित आरेख इस फ़िशिंग रोकथाम तंत्र को दर्शाता है। _नेटिव ऐप के मामले में, ऑरिजिन हैंडलिंग प्लेटफ़ॉर्म द्वारा भिन्न होती है: Android पर, ऑरिजिन को `android:apk-key-hash:` के रूप में स्वरूपित किया जाता है। iOS पर, WebAuthn ऑरिजिन RP वेब-ऑरिजिन (उदा., `https://paypal.com`) है। दोनों मामलों में, आपके नेटिव ऐप और सर्वर के बीच विश्वास को संबंधित एसोसिएशन फ़ाइल (नीचे [देखें](#configuring-relying-party-native-apps)) के माध्यम से सत्यापित किया जाता है। नेटिव ऐप्स के लिए ऑरिजिन सत्यापन कैसे काम करता है, इस बारे में विस्तृत जानकारी के लिए, नेटिव ऐप्स के लिए WebAuthn ऑरिजिन सत्यापन पर हमारी समर्पित मार्गदर्शिका देखें।_ ## 3. नेटिव ऐप्स के लिए दो अलग-अलग इंटीग्रेशन विकल्प किसी नेटिव ऐप में पासकी लागू करने के लिए, कोई डेवलपर उन्हें [WebView](https://www.corbado.com/blog/native-app-passkeys) के माध्यम से या मूल रूप से जोड़ने के बीच निर्णय ले सकता है। आइए निम्नलिखित में दोनों दृष्टिकोणों के लाभों और नुकसानों की जांच करें। ### 3.1 WebView के माध्यम से पासकी इंटीग्रेशन ![Passkey Integration WebView (GitHub)](https://www.corbado.com/website-assets/650c601b1eb462e25702a870_android_webview_passkey_github_8bc81d9852.jpg) पासकी को इंटीग्रेट करने के लिए **WebView**\* का उपयोग करने का अर्थ है ऑथेंटिकेशन प्रक्रिया को संभालने के लिए नेटिव ऐप के भीतर एक वेब ब्राउज़र एम्बेड करना। यह दृष्टिकोण अनिवार्य रूप से ऐप के अंदर एक वेब पेज प्रदर्शित करता है, जिससे नेटिव प्लेटफ़ॉर्म के लिए उन्हें फिर से लिखे बिना वेब-आधारित ऑथेंटिकेशन फ़्लो का पुन: उपयोग करना आसान हो जाता है। हालाँकि, कुछ कमियाँ हैं। [WebView](https://www.corbado.com/blog/native-app-passkeys) सभी पासकी सुविधाओं का समर्थन नहीं कर सकता है, और यदि सुरक्षित रूप से लागू नहीं किया जाता है तो "मैन-इन-द-मिडल" हमलों का संभावित जोखिम है। इसके अतिरिक्त, उपयोगकर्ता अनुभव नेटिव इंटीग्रेशन के जितना सहज नहीं हो सकता है, और विभिन्न उपकरणों और OS संस्करणों में सुसंगत व्यवहार बनाए रखने में चुनौतियां हो सकती हैं। _\*कई प्रकार के WebView हैं: iOS पर (WKWebView, SFSafariViewController या SFAuthenticationSession / ASWebAuthenticationSession OAuth/OpenID Connect आधारित ऑथेंटिकेशन फ़्लो के लिए) और Android (WebView, CCT-Chrome Custom Tabs)। विवरण के लिए यह ब्लॉग पोस्ट देखें। यदि आप नेटिव इंटीग्रेशन नहीं चाहते हैं तो हम पासकी के संदर्भ में SFSafariViewController/ ASWebAuthenticationSession और Chrome Custom Tabs का उपयोग करने की सलाह देते हैं।_ ### 3.2 नेटिव पासकी इंटीग्रेशन ![Native Passkey Integration (Kayak)](https://www.corbado.com/website-assets/650c625cac723f594137a029_android_native_passkey_kayak_0f689e761e.jpg) **नेटिव इंटीग्रेशन** में प्लेटफ़ॉर्म-विशिष्ट API और लाइब्रेरी का उपयोग करके पासकी कार्यक्षमता को सीधे [iOS](https://www.corbado.com/blog/how-to-enable-passkeys-ios) या [Android](https://www.corbado.com/blog/how-to-enable-passkeys-android) ऐप में बनाना शामिल है। यह विधि अधिक सहज उपयोगकर्ता अनुभव प्रदान करती है, क्योंकि नेटिव ऐप और [WebView](https://www.corbado.com/blog/native-app-passkeys) के बीच संक्रमण की कोई आवश्यकता नहीं है। यह बेहतर प्रदर्शन और अधिक सुसंगत लुक और फील की भी अनुमति देता है। सुरक्षा के दृष्टिकोण से, नेटिव इंटीग्रेशन कुछ प्रकार के हमलों के खिलाफ बेहतर सुरक्षा प्रदान कर सकता है, खासकर जब प्लेटफ़ॉर्म-विशिष्ट सुरक्षा सुविधाओं के साथ संयुक्त हो। हालाँकि, कार्यान्वयन प्रयास अधिक हो सकता है, क्योंकि डेवलपर्स को प्रत्येक प्लेटफ़ॉर्म (Android और [iOS](https://www.corbado.com/blog/how-to-enable-passkeys-ios)) के लिए अलग-अलग कोड लिखने और बनाए रखने की आवश्यकता होती है। इसके अतिरिक्त, नवीनतम पासकी / WebAuthn विनिर्देशों के साथ अपडेट रहने के लिए अधिक लगातार ऐप अपडेट की आवश्यकता हो सकती है। निम्नलिखित में, हम नेटिव पासकी इंटीग्रेशन पर ध्यान केंद्रित करते हैं। ## 4. नेटिव ऐप्स के लिए Relying Party को कॉन्फ़िगर करना वेब ऐप्स की तुलना में नेटिव ऐप्स (उदा. iOS या [Android](https://www.corbado.com/blog/how-to-enable-passkeys-android) ऐप्स) एक चुनौती पेश करते हैं। वेब ऐप्स के विपरीत, Relying Party ID से मिलान करने के लिए कोई ब्राउज़र URL नहीं है। फिर भी, समान स्तर की सुरक्षा सुनिश्चित करने के लिए, डोमेन को **एसोसिएशन फ़ाइलों** के माध्यम से नेटिव ऐप्स से जोड़ा जाता है, ताकि डोमेन और नेटिव ऐप के बीच विश्वास स्थापित हो सके। यह विशेष रूप से महत्वपूर्ण है यदि कोई पासकी किसी वेब ऐप पर बनाई गई थी और उसे नेटिव ऐप पर उसी Relying Party ID के लिए उपयोग किया जाना चाहिए (और इसके विपरीत)। ### 4.1 iOS पर एसोसिएशन फ़ाइलें: apple-app-site-association iOS apple-app-site-association फ़ाइल का उपयोग करता है। इस फ़ाइल में विभिन्न एंटाइटेलमेंट होते हैं, लेकिन WebAuthn और पासकी के लिए, webcredentials एंटाइटेलमेंट महत्वपूर्ण है। ```json { "webcredentials": { "apps": ["9RF9KY88B2.com.corbado.passkeys"] } } ``` webcredentials.apps में, आपको अपना Application Identifier Prefix (उदा. `9RF9KY77B2`) और अपना Bundle Identifier (उदा. `com.corbado.passkeys`) सेव करना होगा। iOS नेटिव ऐप्स के काम करने के लिए, apple-app-site-association फ़ाइल को Relying Party IDs `/.well-known` निर्देशिका (`https:///.well-known/apple-app-site-association`) के अंतर्गत सेव किया जाना चाहिए। एक लाइव उदाहरण [यहाँ](https://pro-6244024196016258271.frontendapi.cloud.corbado.io/.well-known/apple-app-site-association) देखें। ### 4.2 Android पर एसोसिएशन फ़ाइलें: assetlinks.json [Android](https://www.corbado.com/blog/how-to-enable-passkeys-android) `assetlinks.json` फ़ाइल का उपयोग करता है, जिसमें अपने iOS समकक्ष की तरह, WebAuthn और पासकी के लिए विशेष कॉन्फ़िगरेशन की आवश्यकता होती है। ```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` और `delegate_permission/common.get_login_creds` सेट करने होंगे। इसके अलावा, आपको अपना पैकेज नाम और अपने साइनिंग प्रमाणपत्र का SHA-256 फिंगरप्रिंट जोड़ना होगा। नेटिव ऐप और वेब ऐप के बीच पासकी साझा करने की अनुमति देने के लिए, आपको दो प्रविष्टियाँ जोड़नी होंगी। एक नेमस्पेस web के लिए और एक नेमस्पेस android_app के लिए। एक लाइव उदाहरण [यहाँ](https://pro-6244024196016258271.frontendapi.cloud.corbado.io/.well-known/assetlinks.json) देखें। Android ऐप्स के काम करने के लिए, assetlinks.json फ़ाइल को Relying Party IDs `/.well-known` निर्देशिका `https:///.well- known/assetlinks.json` के अंतर्गत सेव किया जाना चाहिए - इसलिए काफी हद तक iOS की तरह)। एक नेटिव Android / iOS ऐप और एक वेब ऐप के बीच पासकी साझा करने वाले एक नमूना कार्यान्वयन को देखने के लिए इस ब्लॉग पोस्ट को देखें। ## 5. नेटिव ऐप और वेब ऐप के बीच विश्वास स्थापित करें ### 5.1 iOS iOS ऐप और वेब ऐप के बीच विश्वास स्थापित करने की प्रक्रिया इस प्रकार है: 1. iOS ऐप डेवलपर को उन डोमेन की सूची निर्दिष्ट करनी होगी जिन्हें वह नेटिव ऐप के साथ जोड़ना चाहता है। ये डोमेन iOS ऐप्स एंटाइटेलमेंट में हार्डकोड किए गए हैं, उदा.: - webcredentials:auth.Corbado.com - webcredentials:\*.Corbado.com 2. हर बार जब iOS ऐप इंस्टॉल या अपडेट किया जाता है, iOS ऐप की एंटाइटेलमेंट सूची की प्रत्येक प्रविष्टि के लिए apple-app-site-association फ़ाइल डाउनलोड करेगा। 3. जब iOS ऐप के अंदर कोई क्रेडेंशियल (उदा. पासकी) बनाया जाता है, तो iOS ऐप मान्य करता है कि क्या Relying Party सर्वर का डोमेन निम्नलिखित दो पहलुओं की जांच करके iOS ऐप से जुड़ा है: - क्या डिवाइस पर इस Relying Party सर्वर डोमेन के लिए कोई `apple-app-site-association` फ़ाइल मौजूद है? - क्या iOS ऐप उस `apple-app-site-association` फ़ाइल में सूचीबद्ध है? यदि, और केवल यदि, दोनों प्रश्नों का उत्तर हाँ में दिया जा सकता है, तो iOS ऐप के भीतर एक पासकी बनाई जा सकती है। ### 5.2 Android Android ऐप और वेब ऐप के बीच विश्वास स्थापित करने की प्रक्रिया इस प्रकार है: 1. Android ऐप डेवलपर को उन डोमेन की सूची निर्दिष्ट करनी होगी जिन्हें वह Android ऐप के साथ जोड़ना चाहता है। ये डोमेन assetlinks.json फ़ाइल में नेमस्पेस web के साथ लक्ष्य के रूप में सेव किए जाते हैं। यह घोषित करने के लिए कि Android ऐप्स और वेब ऐप्स क्रेडेंशियल साझा करते हैं, `delegate_permission/common.get_login_creds` निर्दिष्ट किया जाना चाहिए। विवरण [यहाँ](https://developer.android.com/training/sign-in/passkeys#add-support-dal) खोजें। 2. यदि Android ऐप के अंदर एक पासकी बनाई जाती है, तो Android ऐप मान्य करता है कि क्या Relying Party ID `assetlinks.json` की जांच करके Android ऐप से जुड़ा है: - क्या `https://./well-known/assetlinks.json` पर इस Relying Party ID के लिए कोई `assetlinks.json` फ़ाइल है - क्या Android ऐप को लक्ष्य के रूप में सही ढंग से परिभाषित किया गया है। 3. यदि, और केवल यदि, दोनों प्रश्नों का उत्तर हाँ में दिया जा सकता है, तो Android ऐप के भीतर एक पासकी बनाई जा सकती है। नीचे दिया गया आरेख इन विश्वास स्थापना प्रक्रियाओं की कंधे से कंधा मिलाकर तुलना करता है। ## 6. Android, iOS और Flutter सेटिंग्स के लिए अवलोकन निम्नलिखित में, हम नेटिव ऐप्स के लिए पासकी ऑथेंटिकेशन को ठीक से सेट करने के लिए आवश्यक विभिन्न सेटिंग्स के लिए एक विस्तृत अवलोकन प्रदान करते हैं। | फ़ीचर | iOS | Android | | ------------------------------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | नेटिव पासकी ऑथेंटिकेशन के लिए आधिकारिक कार्यान्वयन मार्गदर्शन | Apple Developer | Google Developer | | वेब ऐप्स के साथ पासकी साझा करने की अनुमति देता है | हाँ, apple-app-site-association फ़ाइल के माध्यम से | हाँ, assetlinks.json के माध्यम से | | एसोसिएशन फ़ाइल का स्थान | [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) | | फ़ाइल कैश की गई | हाँ (iOS 14 के बाद से), प्रारंभिक सिंक में 24 घंटे तक का समय लग सकता है | हाँ (Play Services द्वारा) | | बाय-पास संभव | हाँ, वैकल्पिक मोड अनुभाग के साथ | नहीं | | के साथ परीक्षण योग्य | apple-app-site-association परीक्षण | assetlinks.json परीक्षण | | नमूने के साथ ऐप आइडेंटिफायर | `.`, उदा. `T84QZS65DQ.com.facebook.Messenger` | SHA256 फ़िंगरप्रिंट, उदा. `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` | | ऐप आइडेंटिफायर कहाँ मिलेगा | Team Application Identifier Prefix को developer.apple.com पर डेवलपर खाते में पाया जा सकता है और Bundle Identifier XCode प्रोजेक्ट के भीतर से सटीक नाम है | जब पहले से अपलोड किया गया हो: Google Play Console > Release management > App signing स्थानीय: `keytool -list -v -keystore -alias -storepass -keypass ` | | अनुभाग का नाम जो ऐप को वेब से जोड़ता है | applinks (पासकी के लिए आवश्यक नहीं) | `delegate_permission/common.handle_all_urls` (पासकी के लिए आवश्यक) | | अनुभाग का नाम जो ऐप / वेब के बीच क्रेडेंशियल साझा करने की अनुमति देता है | webcredentials | `delegate_permission/common.get_login_creds` | | सभी एसोसिएशन फ़ाइलों की रजिस्ट्री | XCode विकास परिवेश में संबद्ध डोमेन सक्षम करें और जोड़ें (एंटाइटेलमेंट फ़ाइल जनरेट करने के लिए प्रॉपर्टी की सेटिंग) | Credential Manager API का उपयोग करते समय, पासकी के लिए मेनिफेस्ट में assetlinks.json की रजिस्ट्री आवश्यक नहीं है (पासवर्ड के लिए यह है)। यदि Credential Manager API का उपयोग नहीं कर रहे हैं, तो आपको विशिष्ट गतिविधि (Android-ऐप स्रोत कोड का हिस्सा) में AndroidManifest.xml में ``-एंट्री के साथ होस्टनाम सूचीबद्ध करने होंगे। `` को autoVerify=true होना चाहिए। | [Flutter](https://www.corbado.com/blog/flutter-passkeys-package) के लिए, Android या iOS का संबंधित नियम लागू होता है। केवल [Flutter](https://www.corbado.com/blog/flutter-passkeys-package)-विशिष्ट सेटिंग एसोसिएशन फ़ाइलों की रजिस्ट्री है, जहाँ आपको जोड़ना चाहिए: - Android के लिए: [AndroidManifest.xml में flutter_deeplinking_enabled](https://docs.flutter.dev/cookbook/navigation/set-up-app-links) - iOS के लिए: [Info.plist में FlutterDeepLinkingEnabled true](https://docs.flutter.dev/cookbook/navigation/set-up-universal-links) ## 7. मान्य और अमान्य Relying Party ID और एसोसिएशन फ़ाइलों के उदाहरण जैसा कि हमने खुद अनुभव किया है, Relying Party IDs, (उप-)डोमेन के विभिन्न स्तरों और CNAMEs के साथ काम करना काफी चुनौतीपूर्ण काम हो सकता है, हम चार अलग-अलग उदाहरण प्रस्तुत करते हैं और समझाते हैं कि वे क्यों और कैसे काम करते हैं। ध्यान दें, कि CNAME टेबल पंक्ति पासकी ऑथेंटिकेशन के लिए आवश्यक नहीं है और यह केवल हमारे शोध का परिणाम है जिसे हम जोड़ना चाहते थे। ### 7.1 उदाहरण 1: Relying Party रूट डोमेन है | **Relying Party ID** | corbado.com | | --------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------ | | **एंटाइटेलमेंट (केवल iOS)** | webcredentials:corbado.com | | **apple-app-site-association फ़ाइल का स्थान** | [https://corbado.com/.well-known/apple-app-site-association](https://corbado.com/.well-known/apple-app-site-association) | | **assetlinks.json फ़ाइल का स्थान** | [https://corbado.com/.well-known/assetlinks.json](https://corbado.com/.well-known/assetlinks.json) | | **CNAME** | लागू नहीं | इस उदाहरण में, Corbado.com के लिए `apple-app-site-association` / `assetlinks.json` फ़ाइल को बिना किसी समस्या के डाउनलोड किया जा सकता है जब नेटिव ऐप इंस्टॉल / अपडेट किया जाता है, क्योंकि फ़ाइल Relying Party ID के समान स्थान पर है। **Relying Party ID के लिए एक पासकी बनाई जा सकती है।** ### 7.2 उदाहरण 2: Relying Party एक सबडोमेन है और CNAME सेट है | Relying Party ID | auth.corbado.com | | --------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------- | | **एंटाइटेलमेंट (केवल iOS)** | webcredentials:auth.corbado.com | | **apple-app-site-association फ़ाइल का स्थान** | [https://pro-123.passkeys.eu/.well-known/apple-app-site-association](https://pro-123.passkeys.eu/.well-known/apple-app-site-association) | | **assetlinks.json फ़ाइल का स्थान** | [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 | इस उदाहरण में, auth.corbado.com के लिए `apple-app-site-association` / `assetlinks.json` फ़ाइल को बिना किसी समस्या के डाउनलोड किया जा सकता है जब नेटिव ऐप इंस्टॉल / अपडेट किया जाता है, क्योंकि फ़ाइल Relying Party ID के रूप में स्थान पर है, क्योंकि CNAME Relying Party ID से संग्रहीत स्थान पर इंगित करता है। **Relying Party ID के लिए एक पासकी बनाई जा सकती है।** ### 7.3 उदाहरण 3: Relying Party रूट डोमेन है और CNAME सेट है | Relying Party ID | corbado.com | | --------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------- | | **एंटाइटेलमेंट (केवल iOS)** | webcredentials:corbado.com; webcredentials:auth.corbado.com | | **apple-app-site-association फ़ाइल का स्थान** | [https://pro-123.passkeys.eu/.well-known/apple-app-site-association](https://pro-123.passkeys.eu/.well-known/apple-app-site-association) | | **assetlinks.json फ़ाइल का स्थान** | [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 | इस उदाहरण में, auth.corbado.com के लिए `apple-app-site-association` / `assetlinks.json` फ़ाइल को बिना किसी समस्या के डाउनलोड किया जा सकता है जब नेटिव ऐप इंस्टॉल / अपडेट किया जाता है, क्योंकि फ़ाइल, CNAME के कारण, उस स्थान पर है, जहाँ `auth.corbado.com` इसे अपेक्षित करता है। लेकिन: corbado.com के लिए `apple-site-association-file` / `assetlinks.json` को डाउनलोड नहीं किया जा सकता है, जब नेटिव ऐप इंस्टॉल / अपडेट किया जाता है, क्योंकि फ़ाइल `https://corbado.com/.well-known/apple-app-site-association` / `https://corbado.com/.well-known/assetlinks.json` पर नहीं है, जहाँ यह अपेक्षित है और कोई CNAME इसकी ओर इशारा नहीं कर रहा है। **Relying Party ID के लिए एक पासकी नहीं बनाई जा सकती है।** ### 7.4 उदाहरण 4: Relying Party एक सबडोमेन है और वाइल्डकार्ड एंटाइटेलमेंट सेट है | Relying Party ID | auth.corbado.com | | --------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------ | | **एंटाइटेलमेंट (केवल iOS)** | webcredentials:\*.corbado.com | | **apple-app-site-association फ़ाइल का स्थान** | [https://corbado.com/.well-known/apple-app-site-association](https://corbado.com/.well-known/apple-app-site-association) | | **assetlinks.json फ़ाइल का स्थान** | [https://corbado.com/.well-known/assetlinks.json](https://corbado.com/.well-known/assetlinks.json) | | **CNAME** | लागू नहीं | इस उदाहरण में, corbado.com के लिए `apple-app-site-association` फ़ाइल को बिना किसी समस्या के डाउनलोड किया जा सकता है, जब नेटिव ऐप इंस्टॉल / अपडेट किया जाता है, क्योंकि फ़ाइल वह है जहाँ इसकी अपेक्षा की जाती है और webcredentials एंटाइटेलमेंट (`*.corbado.com`) Relying Party ID (`auth.corbado.com`) से मेल खाता है। ध्यान दें कि यह उदाहरण Android के लिए काम नहीं करता है, क्योंकि Android (वाइल्डकार्ड) एंटाइटेलमेंट जैसी किसी चीज़ के साथ काम नहीं करता है। सामान्य तौर पर, Relying Party IDs को परिभाषित करने के इस तरीके की अनुशंसा नहीं की जाती है। **Relying Party ID के लिए एक पासकी बनाई जा सकती है।** ## 8. सामान्य Relying Party ID गलतियाँ और उनसे कैसे बचें ### 8.1 Relying Party ID को सबडोमेन से रूट डोमेन में बदलना **गलती:** आपने विकास शुरू किया और अपने Relying Party ID के रूप में एक सबडोमेन (उदा. `login.acme.com`) परिभाषित किया। पहले उपयोगकर्ताओं ने इस Relying Party ID के लिए एक पासकी बनाई। फिर, आप देखते हैं कि आपको किसी अन्य सबडोमेन (उदा. `app.acme.com`) पर ऑथेंटिकेशन के लिए भी इन पासकी की आवश्यकता है। चूंकि उपयोगकर्ता का ऑरिजिन और नए सबडोमेन के लिए Relying Party ID मेल नहीं खाते हैं, इसलिए उपयोगकर्ता पासकी के साथ साइन-इन नहीं कर सकता है। अपने WebAuthn सेटिंग्स में Relying Party ID को `acme.com` में बदलने से सभी मौजूदा पासकी अमान्य हो जाएंगी, क्योंकि नया ऑरिजिन और मौजूदा पासकी में सेव की गई Relying Party ID मेल नहीं खाती हैं। **समाधान:** अपनी Relying Party ID को परिभाषित करते समय शुरू में दो बार जांच लें क्योंकि यह कमोबेश अंतिम है। यदि आप अनिश्चित हैं और भविष्य के लिए तैयार रहना चाहते हैं, जिसका अर्थ है कि भविष्य में अन्य सबडोमेन को ऑथेंटिकेशन के लिए पासकी की आवश्यकता हो सकती है, तो हम आपको रूट डोमेन (उदा. acme.com) को Relying party ID के रूप में उपयोग करने की सलाह देते हैं जब तक कि यह [Public Suffix List](https://publicsuffix.org/learn/) में न हो। ### 8.2 नेटिव और वेब ऐप के लिए अलग-अलग Relying Party IDs **गलती:** आप एक साथ एक नेटिव और वेब ऐप विकसित कर रहे हैं। चीजों को गति देने के लिए, आप दो अलग-अलग WebAuthn सर्वर (नेटिव और वेब ऐप के लिए अलग-अलग Relying Party IDs के साथ) का उपयोग करते हैं। जैसे ही आपके उपयोगकर्ता पहली पासकी बनाते हैं, संबंधित Relying Party ID पासकी में सेव हो जाती है। उसी पासकी के साथ क्रॉस-डिवाइस / क्रॉस-प्लेटफ़ॉर्म लॉगिन की अनुमति देना, उदा. वेब ऐप में बनाई गई पासकी के साथ और नेटिव ऐप में साइन-इन करने का प्रयास करना, अब संभव नहीं है। दो WebAuthn सर्वर को मर्ज करने से वे पासकी छोड़ दी जाएंगी जो पुराने WebAuthn सर्वर (पुराने Relying Party ID) के साथ पंजीकृत थीं और आपके उपयोगकर्ता इन पासकी के साथ लॉगिन नहीं कर सकते। **समाधान:** यदि आपके पास कई एप्लिकेशन (उदा. एक वेब ऐप और एक नेटिव ऐप) हैं, तो हमेशा केवल एक WebAuthn सर्वर रखें और अपने सभी ऐप्स के लिए केवल एक Relying Party ID परिभाषित करें। इन ऐप्स के बीच लिंकिंग ऊपर बताए गए चरणों के माध्यम से की जा सकती है। ### 8.3 अमान्य और अगम्य एसोसिएशन फ़ाइलें **गलती:** आप अपना एप्लिकेशन विकसित करना शुरू करते हैं, एसोसिएशन फ़ाइलों को कॉन्फ़िगर करते हैं और उन्हें अपने सर्वर पर तैनात करते हैं। किसी कारण से, आपको अभी भी त्रुटि संदेश मिल रहे हैं और आपको मूल कारण नहीं मिल रहा है। **समाधान:** त्रुटि संदेश का एक संभावित कारण एक विकृत या अगम्य एसोसिएशन फ़ाइल हो सकता है। सर्वर पर किसी भी एसोसिएशन फ़ाइल को तैनात करने से पहले, हम [iOS](https://www.corbado.com/blog/how-to-enable-passkeys-ios) और Android के लिए प्रदान किए गए टूल के माध्यम से एसोसिएशन फ़ाइल की वैधता और पहुंच (अक्सर ये फ़ाइलें [एक मजबूत VPN](https://cybernews.com/best-vpn/most-secure-vpns/) या फ़ायरवॉल के पीछे हो सकती हैं जो Apple और Google के क्रॉलर के लिए उचित पहुंच को रोकती हैं) की जांच करने की अत्यधिक अनुशंसा करते हैं। ### 8.4 apple-app-site-association फ़ाइल Apple CDN द्वारा अभी तक कैश नहीं की गई **गलती:** आपने अपनी apple-app-site-association फ़ाइल को अपने सर्वर पर तैनात कर दिया है और तुरंत अपने परीक्षण उपकरण पर एक पासकी बनाना शुरू करना चाहते हैं। किसी कारण से, आप पासकी नहीं बना सकते और आपको त्रुटि संदेश मिलते हैं। **समाधान:** इन त्रुटि संदेशों के पीछे का कारण यह है कि iOS डिवाइस Relying Party को मान्य करने के लिए `apple-app-site-association` फ़ाइल डाउनलोड करते हैं। ऐसा करने के लिए, iOS डिवाइस आपके सर्वर पर सीधा अनुरोध नहीं भेजते हैं बल्कि इसके बजाय CDN का उपयोग करते हैं। इसके सफलतापूर्वक प्राप्त होने के बाद डिवाइस और CDN दोनों `apple-app-site-association` फ़ाइल को कैश करते हैं। इस कैशिंग कार्यक्षमता के कारण, आपकी `apple-app-site-association` फ़ाइल में नए परिवर्तन सीधे आपके ऐप में परिलक्षित नहीं होते हैं। CDN द्वारा `apple-app-site-association` फ़ाइल को कैश करने में 24 घंटे तक का समय लग सकता है। विकास के दौरान इस प्रतिबंध को दरकिनार करने के लिए, आप Relying Party ID में `?mode=developer` जोड़ सकते हैं और कैशिंग को पूरी तरह से अक्षम कर सकते हैं (उदा. Relying Party ID `acme.com?mode=developer` होगा)। ### 8.5 Android एम्यूलेटर और API संस्करण असंगतता **गलती:** आप एक Android ऐप विकसित करना शुरू करते हैं और इसे Android एम्यूलेटर पर परीक्षण करना चाहते हैं। कुछ के लिए, कारण आपको त्रुटि संदेश मिल रहे हैं, भले ही आपने Android एम्यूलेटर को ठीक से सेट किया हो और अन्य ऐप इस पर सुचारू रूप से काम करते प्रतीत होते हों। **समाधान:** पासकी एप्लिकेशन का परीक्षण करते समय Android संस्करण, Play Store समर्थन और API संस्करण एक प्रमुख भूमिका निभाते हैं। इसके अलावा, आपको Google खाते में लॉग इन होना चाहिए। विवरण के लिए कृपया हमारे समस्या निवारण अनुभाग को देखें। ## 9. सिफ़ारिश ### 9.1 सामान्य सिफ़ारिश हमारी समग्र सिफ़ारिश यह है कि आप अपने एप्लिकेशन परिदृश्य और आवश्यकताओं के आधार पर अपनी Relying Party ID का सावधानीपूर्वक चुनाव करें। नीचे, हमने सबसे सामान्य उपयोग के मामलों को एकत्र किया है, लेकिन हमारी सामान्य सिफ़ारिश यह है कि आपको **अपनी Relying Party ID के रूप में अपना रूट डोमेन चुनने का लक्ष्य रखना चाहिए** और इस तरह से अपना ऑथेंटिकेशन कॉन्फ़िगर करना चाहिए। Corbado के साथ, हमने इसे आपके लिए पहले से ही इस तरह से पूर्व-कॉन्फ़िगर कर दिया है (क्योंकि यह सभी तकनीकी सेटअप के लिए सहज पासकी ऑथेंटिकेशन प्रदान करने के हमारे दृष्टिकोण का हिस्सा है। हमारे UI घटक और SDK आपके रूट डोमेन के साथ Relying Party ID के रूप में उपयोग करने के लिए तैयार हैं)। | मामला | सिफ़ारिश | | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | **A) आपके पास एक रूट डोमेन है:**

उदाहरण: acme.com

सभी एप्लिकेशन और ऑथेंटिकेशन इस रूट डोमेन या इसके सबडोमेन पर चलते हैं | ✔️ अपने Relying Party ID के रूप में रूट डोमेन चुनें क्योंकि इससे वेब या नेटिव ऐप्स के लिए कोई समस्या नहीं होगी। | | **B) आपके पास कई रूट डोमेन हैं:**

उदाहरण: kayak.com, kayak.co.uk, kayak.de

आप अपने उपयोगकर्ताओं को विभिन्न अंतरराष्ट्रीय टॉप-लेवल डोमेन से सेवा प्रदान करते हैं। अमेरिका के लिए Kayak.com और यूके के लिए kayak.co.uk या आपके पास पूरी तरह से अलग रूट डोमेन हैं जो समान उपयोगकर्ताओं को समान पासकी के साथ लॉगिन करने की अनुमति देनी चाहिए। | ⚠️ आपके वेब ऐप्स पर, पासकी साझा करने के लिए निर्दिष्ट ऑरिजिन को एक सामान्य RP ID का उपयोग करने की अनुमति देने के लिए `.well-known/webauthn` के माध्यम से Related Origin Requests को कॉन्फ़िगर करने की आवश्यकता होती है (ब्राउज़र समर्थन भिन्न होता है; अनुकूलता सत्यापित करें)। वैकल्पिक रूप से, एक सामान्य ऑथेंटिकेशन रूट डोमेन चुनें।

✔️ आप अपने नेटिव ऐप्स को कितनी भी संख्या में रूट डोमेन से कनेक्ट कर सकते हैं, जब तक कि आपका रूट एसोसिएशन फ़ाइलों पर नियंत्रण हो।

❌ यदि आप अपनी वेबसाइट को होस्ट करने के लिए बाद में किसी अन्य रूट डोमेन पर माइग्रेट करना चाहते हैं, तो आप अपनी पहले से बनाई गई पासकी का उपयोग नहीं कर पाएंगे, क्योंकि आपको डोमेन (Relying Party ID) को रीब्रांड करना और बदलना होगा। | | **C) आपके पास अभी तक कोई रूट डोमेन नहीं है, आप केवल बैकएंड या किसी सार्वजनिक सबडोमेन पर चल रहे हैं। ऐसे कुछ मामले हैं जहाँ ऐसा हो सकता है:**

1. आप एक स्वतंत्र रूप से उपलब्ध सबडोमेन पर काम करते हैं, जहाँ रूट डोमेन आपके नियंत्रण में नहीं है (रूट डोमेन [https://publicsuffix.org/](https://publicsuffix.org/) में सूचीबद्ध है) उदाहरण के लिए CDN URL

2. आप एक नेटिव ऐप पर काम करते हैं। | ❌ सार्वजनिक सबडोमेन पर, आप रूट डोमेन के रूट स्तर पर एसोसिएशन फ़ाइलों को नियंत्रित नहीं कर सकते इसलिए, पासकी मूल रूप से काम नहीं करेंगी।

⚠️ कुछ सेवाओं के लिए इसे ठीक करने का एकमात्र तरीका सशुल्क योजना में बदलना है, जहाँ आप CNAME परिभाषित कर सकते हैं या अपने लिए एक कस्टम रूट डोमेन प्राप्त कर सकते हैं। | ### 9.2 Corbado का उपयोग करते समय सिफ़ारिश निम्नलिखित में, हम एक बहुत ही विशिष्ट निर्णय ट्री प्रदान करते हैं जो आपको सही Relying Party ID निर्धारित करने में मदद करेगा और अपने पासकी समाधान के रूप में Corbado का उपयोग करते समय आपको एसोसिएशन फ़ाइलों को कैसे संभालना / होस्ट करना चाहिए। पहला निर्णय यह है कि क्या आप विकास या उत्पादन परिवेश में हैं। निर्णय का अगला स्तर जो आपको करना है वह आपके एप्लिकेशन परिदृश्य पर आधारित है: क्या आपके पास केवल एक नेटिव ऐप है या एक नेटिव और वेब ऐप है। #### A) विकास विकास परिवेश के लिए, हम मानते हैं कि आप जल्दी से विकास और परीक्षण शुरू करना चाहते हैं। यदि आप लाइव जाना चाहते हैं तो Relying Party ID को बाद में बदला जा सकता है। ##### A1) केवल नेटिव - Relying Party ID सेट करें = `pro-XXX.frontendapi.cloud.corbado.io` (डिफ़ॉल्ट मान) - Corbado आपके लिए एसोसिएशन फ़ाइल होस्ट करता है - आपके लिए कोई DNS ToDo नहीं ##### A2) नेटिव ऐप और वेब ऐप एक ही समय में वेब ऐप और नेटिव ऐप दोनों का परीक्षण करना आसानी से संभव नहीं है **विकल्प 1:** या तो आप Relying Party ID = `pro-XXX.frontendapi.cloud.corbado.io` सेट करें (नेटिव ऐप काम करता है) या Relying Party ID = `localhost` सेट करें (वेब ऐप काम करता है) **विकल्प 2:** नेटिव और वेब ऐप को एक ही समय में काम करने का एकमात्र समाधान स्थानीय रिवर्स प्रॉक्सी का उपयोग करना है (यह एक बल्कि हैकी समाधान है): - Relying Party ID सेट करें = `acme-dev.com` - `acme-dev.com` से CNAME सेट करें => `pro-XXX.frontendapi.cloud.corbado.io` - स्थानीय `/etc/hosts` प्रविष्टि `localhost acme-dev.com` जोड़ें - `acme-dev.com` => `localhost:3000` के लिए नियम के साथ रिवर्स प्रॉक्सी (nginx) जोड़ें (उदाहरण के तौर पर) #### B) उत्पादन उत्पादन परिवेश में, आपको यह तय करना होगा कि क्या आप Relying Party ID (उदा. `auth.acme.com`) के रूप में एक सबडोमेन के साथ ठीक हैं या यदि आप Relying Party ID (उदा. `acme.com`) के रूप में एक रूट डोमेन चाहते हैं। ##### B1) Relying Party ID के रूप में सबडोमेन ###### B1.1) केवल नेटिव - Relying Party ID सेट करें = `auth.acme.com` - Corbado आपके लिए एसोसिएशन फ़ाइल होस्ट करता है - `auth.acme.com` से CNAME सेट करें => `pro-XXX.frontendapi.cloud.corbado.io` ###### B1.2) नेटिव ऐप और वेब ऐप - Relying Party ID सेट करें = `auth.acme.com` - Corbado आपके लिए एसोसिएशन फ़ाइल होस्ट करता है - `auth.acme.com` से CNAME सेट करें => `pro-XXX.frontendapi.cloud.corbado.io` (कुकीज़ के काम करने के लिए भी आवश्यक है यदि आप Corbado के सत्र प्रबंधन का उपयोग करते हैं) ##### B2) Relying Party ID के रूप में रूट डोमेन ###### B2.1) केवल नेटिव - Relying Party ID सेट करें = `acme.com` - एसोसिएशन फ़ाइल को अपने सर्वर पर `acme.com/.well-known/` पर स्वयं होस्ट करें - आपके लिए कोई DNS ToDo नहीं ###### B2.2) नेटिव ऐप और वेब ऐप - Relying Party ID सेट करें = `acme.com` - एसोसिएशन फ़ाइल को अपने सर्वर पर `acme.com/.well-known/` पर स्वयं होस्ट करें - यदि आप, Corbado के सत्र प्रबंधन का उपयोग करते हैं, तो आपको कुकीज़ को काम करने के लिए `auth.acme.com` => `pro-XXX.frontendapi.cloud.corbado.io` से CNAME सेट करने की आवश्यकता है (यह CNAME पूरी तरह से सत्र प्रबंधन के लिए Relying Party ID के लिए आवश्यक नहीं है) निम्नलिखित निर्णय ट्री सभी कॉन्फ़िगरेशन पथों को सारांशित करता है। ## 10. निष्कर्ष Relying Party ID WebAuthn और पासकी-आधारित ऑथेंटिकेशन की एक आधारशिला है और मजबूत फ़िशिंग-प्रतिरोध प्रदान करती है। इसे ठीक से कॉन्फ़िगर करना, डोमेन मिलान की जटिलताओं को समझना, और नेटिव ऐप्स के लिए सही परिनियोजन सुनिश्चित करना महत्वपूर्ण है। इस ब्लॉग पोस्ट ने आपको दिखाया कि उन्हें सही तरीके से कैसे सेट किया जाए और विभिन्न गलतियों को कैसे संभाला जाए। एक बार आपका rpID कॉन्फ़िगरेशन ठोस हो जाने पर, वास्तविक अपनाने को गति देने के लिए अपने पासकी निर्माण प्रवाह और पासकी लॉगिन प्रवाह को अनुकूलित करने पर ध्यान केंद्रित करें। नेटिव ऐप के लिए पासकी सेट करने के बारे में अधिक जानकारी के लिए, हम [Flutter](https://www.corbado.com/blog/flutter-passkeys-package) में पासकी के बारे में पढ़ने की सलाह देते हैं। यदि आपके कोई और प्रश्न हैं या सहायता की आवश्यकता है, तो बेझिझक [संपर्क करें](https://bit.ly/passkeys-community)। ## अक्सर पूछे जाने वाले प्रश्न ### Relying Party ID पासकी ऑथेंटिकेशन में फ़िशिंग को कैसे रोकता है? ऑथेंटिकेटर पासकी में सेव की गई Relying Party ID के विरुद्ध ब्राउज़र के वास्तविक ऑरिजिन की तुलना करता है। यदि कोई हमलावर किसी अलग डोमेन पर एक नकली साइट होस्ट करता है, तो ऑरिजिन बेमेल के कारण ऑथेंटिकेशन स्वचालित रूप से विफल हो जाता है, भले ही जाली चुनौती वैध RP ID का दावा करती हो। इस बाइंडिंग का अर्थ है कि paypal.com पर पंजीकृत पासकी का उपयोग paybal.com जैसे दिखने वाले डोमेन पर नहीं किया जा सकता है। ### क्या होगा यदि मैं उपयोगकर्ताओं द्वारा पहले से ही पासकी पंजीकृत करने के बाद अपना WebAuthn Relying Party ID बदल दूं? RP ID को बदलने से सभी मौजूदा पासकी अमान्य हो जाती हैं क्योंकि प्रत्येक क्रेडेंशियल में सेव की गई RP ID अब नए मान से मेल नहीं खाएगी। केवल अपवाद तब होते हैं जब नया RP ID पुराने का सबडोमेन होता है या जब Related Origin Requests `.well-known/webauthn` के माध्यम से कॉन्फ़िगर किए जाते हैं। इस अपरिवर्तनीय समस्या से बचने के लिए शुरू से ही रूट डोमेन को RP ID के रूप में चुनें। ### apple-app-site-association फ़ाइल को तैनात करने के तुरंत बाद मेरा iOS पासकी काम क्यों नहीं कर रहा है? iOS apple-app-site-association फ़ाइल को सीधे आपके सर्वर से प्राप्त नहीं करता है। यह Apple के CDN का उपयोग करता है, जिसमें नई तैनात या अद्यतन फ़ाइल को कैश करने में 24 घंटे तक का समय लग सकता है। विकास के दौरान, कैशिंग को पूरी तरह से बायपास करने के लिए Relying Party ID में `?mode=developer` जोड़ें। ### क्या मुझे पासकी के लिए अपने Relying Party ID के रूप में सबडोमेन या रूट डोमेन का उपयोग करना चाहिए? रूट डोमेन (उदा., acme.com) का उपयोग करने की अनुशंसा की जाती है क्योंकि किसी भी सबडोमेन पर बनाई गई पासकी उस रूट के सभी सबडोमेन में ऑथेंटिकेट कर सकती है। एक सबडोमेन RP ID पासकी के उपयोग को उस सबडोमेन और उसके बच्चों तक सीमित करता है, जो बाद में क्रॉस-सबडोमेन प्रवाह को तोड़ सकता है। यदि आपके पास कई रूट डोमेन हैं जैसे acme.com और acme.co.uk, तो उनके बीच पासकी के पुन: उपयोग की अनुमति देने के लिए `.well-known/webauthn` के माध्यम से Related Origin Requests कॉन्फ़िगर करें।