WebAuthn Relying Party ID (rpID) और पासकी (Passkeys): डोमेन और नेटिव ऐप्स

पासकी ऑथेंटिकेशन तेज़ी से आदर्श बनता जा रहा है क्योंकि TikTok, GitHub, WhatsApp, X (Twitter), LinkedIn और Amazon जैसी तकनीकी दिग्गज कंपनियाँ इन्हें लागू कर रही हैं या पहले ही कर चुकी हैं। यह स्पष्ट है कि तकनीकी दुनिया सरल और सुरक्षित ऑथेंटिकेशन के महत्व को पहचान रही है।

Face ID, Touch ID या Windows Hello के साथ ऑथेंटिकेट करने के सहज उपयोगकर्ता अनुभव से परे, पासकी पासवर्ड जैसे पारंपरिक ऑथेंटिकेशन तरीकों की तुलना में अद्वितीय सुरक्षा प्रदान करती हैं। इसकी एक प्रमुख विशेषता अत्यधिक फ़िशिंग-प्रतिरोध है।

Live demo में passkeys आज़माएं.

Passkeys आज़माएं

फ़िशिंग एक ऐसा हमला है जिसमें पीड़ित को एक नकली साइट पर क्रेडेंशियल प्रदान करने के लिए धोखा दिया जाता है जो मूल साइट होने की नकल करती है। उदाहरण के लिए, कल्पना करें कि आपको अपने बैंक से एक ईमेल प्राप्त होता है, जिसमें आपको लॉग इन करने के लिए कहा जाता है। आप लिंक पर क्लिक करते हैं, और वेबसाइट वैध लगती है, इसलिए आप अपने क्रेडेंशियल दर्ज करते हैं और हमलावर उनका उपयोग मूल साइट पर लॉग इन करने के लिए कर सकता है। डिजिटल युग में यह एक लगातार बढ़ती समस्या बनती जा रही है और यहाँ तक कि Okta (एक ऑथेंटिकेशन प्रदाता!) या Retool जैसी प्रमुख कंपनियाँ भी स्पीयर-फ़िशिंग हमलों (फ़िशिंग का एक विशेष रूप जहाँ लक्षित पीड़ितों को बहुत व्यक्तिगत फ़िशिंग चालों से फंसाया जाता है) का शिकार हुई हैं, जो मजबूत सुरक्षा उपायों की आवश्यकता पर जोर देती हैं।

इसके विपरीत, यदि आप पासकी का उपयोग करते हैं, और साइट नकली है, तो आपका ऑथेंटिकेशन विफल हो जाएगा। ऐसा इसलिए है क्योंकि पासकी Relying Party ID के माध्यम से उन डोमेन से बंधी होती हैं जिनके लिए उन्हें बनाया गया था।

यह तंत्र WebAuthn में बेक किया गया है, जो पासवर्डलेस ऑथेंटिकेशन के लिए पासकी-आधारित वेब मानक है। WebAuthn दो मुख्य समारोहों पर बनाया गया है: पंजीकरण और ऑथेंटिकेशन समारोह।

पंजीकरण (साइन-अप) समारोह के दौरान वेब या नेटिव ऐप के माध्यम से एक ऑनलाइन सेवा (Relying Party) के लिए एक नई पासकी बनाई जाती है। इस प्रक्रिया में, वह डोमेन (Relying Party ID) जिसके लिए पासकी बनाई जाती है, पासकी में सेव हो जाता है।

यह ऑथेंटिकेशन (लॉगिन) समारोह को यह जांचने की अनुमति देता है कि क्या ऑनलाइन सेवा (Relying Party), जिससे वेब या नेटिव ऐप संबंधित है, पासकी में सेव की गई Relying Party ID से मेल खाती है।

निम्नलिखित में, हम विस्तार से देखेंगे कि यह डोमेन मिलान प्रक्रिया कैसे काम करती है और विशेष रूप से, नेटिव ऐप्स कैसे सुरक्षित हैं।

Relying Party ID अनिवार्य रूप से पासकी के भीतर सेव किया गया एक डोमेन है, जो यह सुनिश्चित करता है कि पासकी तभी काम करती है जब वर्तमान ब्राउज़र URL (उपयोगकर्ता का ऑरिजिन जो स्वचालित रूप से प्रत्येक अनुरोध पर भेजा जाता है) इससे मेल खाता है (नीचे नेटिव ऐप दृष्टिकोण देखें)। यह WebAuthn विनिर्देश का एक महत्वपूर्ण घटक है, जिसके बारे में आप यहाँ अधिक जान सकते हैं। Relying Party ID रूट डोमेन (उदा. corbado.com) या सबडोमेन (auth.corbado.com) हो सकता है। यदि यह पब्लिक सफिक्स लिस्ट में है तो आप रूट डोमेन को Relying Party ID के रूप में सेव नहीं कर सकते (पब्लिक सफिक्स डिटेक्शन के लिए सूची और लाइब्रेरी यहाँ खोजें)। किसी ऑनलाइन सेवा के लिए Relying Party ID बदलने से मौजूदा पासकी टूट जाएंगी (अपवाद: नई Relying Party ID पुरानी Relying Party ID का एक सबडोमेन है, या संबंधित डोमेन में पासकी के पुन: उपयोग की अनुमति देने के लिए .well-known/webauthn के माध्यम से Related Origin Requests कॉन्फ़िगर किए गए हैं)।

Passkeys चीटशीट. passkey कार्यक्रमों के लिए व्यावहारिक मार्गदर्शन, रोलआउट पैटर्न और KPIs।

Cheat sheet पाएं

ऑथेंटिकेशन प्रक्रिया के दौरान, Relying Party ID को ब्राउज़र URL (उपयोगकर्ता का ऑरिजिन) के विरुद्ध जांचा जाता है ताकि यह सुनिश्चित हो सके कि वे मेल खाते हैं। इस अर्थ में मिलान का अर्थ है कि या तो:

• ब्राउज़र URL (उपयोगकर्ताओं का ऑरिजिन) Relying Party ID से पूरी तरह मेल खाता है या
• ब्राउज़र URL (उपयोगकर्ता का ऑरिजिन) एक सबडोमेन है जो Relying Party ID से मेल खाता है और पैरेंट डोमेन पंजीकृत करने योग्य है (उदा. com या Public Suffix List पर कोई भी डोमेन काम नहीं करता है)

यहाँ एक विस्तृत रूपरेखा दी गई है कि किस originalHost (दूसरा कॉलम) को अपने पैरेंट डोमेन तक पहुँचने की अनुमति है:

निम्नलिखित में, आप पार्स किए गए PublicKeyCredentialCreationOptions देखते हैं:

{
    "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 क्लोन विकसित करता है जो एक नकली वेबसाइट है जो आपकी ओर से लॉग इन करने के लिए आपके PayPal क्रेडेंशियल चुराने का प्रयास करती है और हमलावरों के खाते में पैसे भेजती है। यह नकली PayPal वेबसाइट डोमेन 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:<SHA256_fingerprint> के रूप में स्वरूपित किया जाता है। iOS पर, WebAuthn ऑरिजिन RP वेब-ऑरिजिन (उदा., https://paypal.com) है। दोनों मामलों में, आपके नेटिव ऐप और सर्वर के बीच विश्वास को संबंधित एसोसिएशन फ़ाइल (नीचे देखें) के माध्यम से सत्यापित किया जाता है। नेटिव ऐप्स के लिए ऑरिजिन सत्यापन कैसे काम करता है, इस बारे में विस्तृत जानकारी के लिए, नेटिव ऐप्स के लिए WebAuthn ऑरिजिन सत्यापन पर हमारी समर्पित मार्गदर्शिका देखें।

Updates और support के लिए हमारी Passkeys Community से जुड़ें.

जुड़ें

किसी नेटिव ऐप में पासकी लागू करने के लिए, कोई डेवलपर उन्हें WebView के माध्यम से या मूल रूप से जोड़ने के बीच निर्णय ले सकता है। आइए निम्नलिखित में दोनों दृष्टिकोणों के लाभों और नुकसानों की जांच करें।

पासकी को इंटीग्रेट करने के लिए WebView* का उपयोग करने का अर्थ है ऑथेंटिकेशन प्रक्रिया को संभालने के लिए नेटिव ऐप के भीतर एक वेब ब्राउज़र एम्बेड करना। यह दृष्टिकोण अनिवार्य रूप से ऐप के अंदर एक वेब पेज प्रदर्शित करता है, जिससे नेटिव प्लेटफ़ॉर्म के लिए उन्हें फिर से लिखे बिना वेब-आधारित ऑथेंटिकेशन फ़्लो का पुन: उपयोग करना आसान हो जाता है। हालाँकि, कुछ कमियाँ हैं। WebView सभी पासकी सुविधाओं का समर्थन नहीं कर सकता है, और यदि सुरक्षित रूप से लागू नहीं किया जाता है तो "मैन-इन-द-मिडल" हमलों का संभावित जोखिम है। इसके अतिरिक्त, उपयोगकर्ता अनुभव नेटिव इंटीग्रेशन के जितना सहज नहीं हो सकता है, और विभिन्न उपकरणों और OS संस्करणों में सुसंगत व्यवहार बनाए रखने में चुनौतियां हो सकती हैं।

*कई प्रकार के WebView हैं: iOS पर (WKWebView, SFSafariViewController या SFAuthenticationSession / ASWebAuthenticationSession OAuth/OpenID Connect आधारित ऑथेंटिकेशन फ़्लो के लिए) और Android (WebView, CCT-Chrome Custom Tabs)। विवरण के लिए यह ब्लॉग पोस्ट देखें। यदि आप नेटिव इंटीग्रेशन नहीं चाहते हैं तो हम पासकी के संदर्भ में SFSafariViewController/ ASWebAuthenticationSession और Chrome Custom Tabs का उपयोग करने की सलाह देते हैं।

देखें कि वास्तव में कितने लोग passkeys इस्तेमाल करते हैं.

Adoption data देखें

नेटिव इंटीग्रेशन में प्लेटफ़ॉर्म-विशिष्ट API और लाइब्रेरी का उपयोग करके पासकी कार्यक्षमता को सीधे iOS या Android ऐप में बनाना शामिल है। यह विधि अधिक सहज उपयोगकर्ता अनुभव प्रदान करती है, क्योंकि नेटिव ऐप और WebView के बीच संक्रमण की कोई आवश्यकता नहीं है। यह बेहतर प्रदर्शन और अधिक सुसंगत लुक और फील की भी अनुमति देता है। सुरक्षा के दृष्टिकोण से, नेटिव इंटीग्रेशन कुछ प्रकार के हमलों के खिलाफ बेहतर सुरक्षा प्रदान कर सकता है, खासकर जब प्लेटफ़ॉर्म-विशिष्ट सुरक्षा सुविधाओं के साथ संयुक्त हो। हालाँकि, कार्यान्वयन प्रयास अधिक हो सकता है, क्योंकि डेवलपर्स को प्रत्येक प्लेटफ़ॉर्म (Android और iOS) के लिए अलग-अलग कोड लिखने और बनाए रखने की आवश्यकता होती है। इसके अतिरिक्त, नवीनतम पासकी / WebAuthn विनिर्देशों के साथ अपडेट रहने के लिए अधिक लगातार ऐप अपडेट की आवश्यकता हो सकती है।

निम्नलिखित में, हम नेटिव पासकी इंटीग्रेशन पर ध्यान केंद्रित करते हैं।

देखें कि वास्तव में कितने लोग passkeys इस्तेमाल करते हैं.

Adoption data देखें

वेब ऐप्स की तुलना में नेटिव ऐप्स (उदा. iOS या Android ऐप्स) एक चुनौती पेश करते हैं। वेब ऐप्स के विपरीत, Relying Party ID से मिलान करने के लिए कोई ब्राउज़र URL नहीं है। फिर भी, समान स्तर की सुरक्षा सुनिश्चित करने के लिए, डोमेन को एसोसिएशन फ़ाइलों के माध्यम से नेटिव ऐप्स से जोड़ा जाता है, ताकि डोमेन और नेटिव ऐप के बीच विश्वास स्थापित हो सके।

यह विशेष रूप से महत्वपूर्ण है यदि कोई पासकी किसी वेब ऐप पर बनाई गई थी और उसे नेटिव ऐप पर उसी Relying Party ID के लिए उपयोग किया जाना चाहिए (और इसके विपरीत)।

iOS apple-app-site-association फ़ाइल का उपयोग करता है। इस फ़ाइल में विभिन्न एंटाइटेलमेंट होते हैं, लेकिन WebAuthn और पासकी के लिए, webcredentials एंटाइटेलमेंट महत्वपूर्ण है।

{
    "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://<Relying Party ID>/.well-known/apple-app-site-association) के अंतर्गत सेव किया जाना चाहिए।

एक लाइव उदाहरण यहाँ देखें।

Android assetlinks.json फ़ाइल का उपयोग करता है, जिसमें अपने iOS समकक्ष की तरह, WebAuthn और पासकी के लिए विशेष कॉन्फ़िगरेशन की आवश्यकता होती है।

[
    {
        "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 के लिए।

एक लाइव उदाहरण यहाँ देखें।

Android ऐप्स के काम करने के लिए, assetlinks.json फ़ाइल को Relying Party IDs /.well-known निर्देशिका https://<Relying Party ID>/.well- known/assetlinks.json के अंतर्गत सेव किया जाना चाहिए - इसलिए काफी हद तक iOS की तरह)।

एक नेटिव Android / iOS ऐप और एक वेब ऐप के बीच पासकी साझा करने वाले एक नमूना कार्यान्वयन को देखने के लिए इस ब्लॉग पोस्ट को देखें।

Passkeys Debugger में passkey flows के साथ experiment करें.

मुफ्त में आज़माएं

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 ऐप के भीतर एक पासकी बनाई जा सकती है।

Igor Gjorgjioski

Head of Digital Channels & Platform Enablement, VicRoads

We hit 80% mobile passkey activation across 5M+ users without replacing our IDP.

See how VicRoads scaled passkeys to 5M+ users — alongside their existing IDP.

Read the case study

Android ऐप और वेब ऐप के बीच विश्वास स्थापित करने की प्रक्रिया इस प्रकार है:

1. Android ऐप डेवलपर को उन डोमेन की सूची निर्दिष्ट करनी होगी जिन्हें वह Android ऐप के साथ जोड़ना चाहता है। ये डोमेन assetlinks.json फ़ाइल में नेमस्पेस web के साथ लक्ष्य के रूप में सेव किए जाते हैं। यह घोषित करने के लिए कि Android ऐप्स और वेब ऐप्स क्रेडेंशियल साझा करते हैं, delegate_permission/common.get_login_creds निर्दिष्ट किया जाना चाहिए। विवरण यहाँ खोजें।

2. यदि Android ऐप के अंदर एक पासकी बनाई जाती है, तो Android ऐप मान्य करता है कि क्या Relying Party ID assetlinks.json की जांच करके Android ऐप से जुड़ा है:

• क्या https://<Relying Party ID>./well-known/assetlinks.json पर इस Relying Party ID के लिए कोई assetlinks.json फ़ाइल है
• क्या Android ऐप को लक्ष्य के रूप में सही ढंग से परिभाषित किया गया है।

3. यदि, और केवल यदि, दोनों प्रश्नों का उत्तर हाँ में दिया जा सकता है, तो Android ऐप के भीतर एक पासकी बनाई जा सकती है।

नीचे दिया गया आरेख इन विश्वास स्थापना प्रक्रियाओं की कंधे से कंधा मिलाकर तुलना करता है।

Latest news के लिए हमारे Passkeys Substack को subscribe करें.

Subscribe करें

निम्नलिखित में, हम नेटिव ऐप्स के लिए पासकी ऑथेंटिकेशन को ठीक से सेट करने के लिए आवश्यक विभिन्न सेटिंग्स के लिए एक विस्तृत अवलोकन प्रदान करते हैं।

Flutter के लिए, Android या iOS का संबंधित नियम लागू होता है। केवल Flutter-विशिष्ट सेटिंग एसोसिएशन फ़ाइलों की रजिस्ट्री है, जहाँ आपको जोड़ना चाहिए:

• Android के लिए: AndroidManifest.xml में flutter_deeplinking_enabled
• iOS के लिए: Info.plist में FlutterDeepLinkingEnabled true

जैसा कि हमने खुद अनुभव किया है, Relying Party IDs, (उप-)डोमेन के विभिन्न स्तरों और CNAMEs के साथ काम करना काफी चुनौतीपूर्ण काम हो सकता है, हम चार अलग-अलग उदाहरण प्रस्तुत करते हैं और समझाते हैं कि वे क्यों और कैसे काम करते हैं।

ध्यान दें, कि CNAME टेबल पंक्ति पासकी ऑथेंटिकेशन के लिए आवश्यक नहीं है और यह केवल हमारे शोध का परिणाम है जिसे हम जोड़ना चाहते थे।

इस उदाहरण में, Corbado.com के लिए apple-app-site-association / assetlinks.json फ़ाइल को बिना किसी समस्या के डाउनलोड किया जा सकता है जब नेटिव ऐप इंस्टॉल / अपडेट किया जाता है, क्योंकि फ़ाइल Relying Party ID के समान स्थान पर है।

Relying Party ID के लिए एक पासकी बनाई जा सकती है।

इस उदाहरण में, auth.corbado.com के लिए apple-app-site-association / assetlinks.json फ़ाइल को बिना किसी समस्या के डाउनलोड किया जा सकता है जब नेटिव ऐप इंस्टॉल / अपडेट किया जाता है, क्योंकि फ़ाइल Relying Party ID के रूप में स्थान पर है, क्योंकि CNAME Relying Party ID से संग्रहीत स्थान पर इंगित करता है।

Relying Party ID के लिए एक पासकी बनाई जा सकती है।

इस उदाहरण में, 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 के लिए एक पासकी नहीं बनाई जा सकती है।

इस उदाहरण में, corbado.com के लिए apple-app-site-association फ़ाइल को बिना किसी समस्या के डाउनलोड किया जा सकता है, जब नेटिव ऐप इंस्टॉल / अपडेट किया जाता है, क्योंकि फ़ाइल वह है जहाँ इसकी अपेक्षा की जाती है और webcredentials एंटाइटेलमेंट (*.corbado.com) Relying Party ID (auth.corbado.com) से मेल खाता है। ध्यान दें कि यह उदाहरण Android के लिए काम नहीं करता है, क्योंकि Android (वाइल्डकार्ड) एंटाइटेलमेंट जैसी किसी चीज़ के साथ काम नहीं करता है। सामान्य तौर पर, Relying Party IDs को परिभाषित करने के इस तरीके की अनुशंसा नहीं की जाती है।

Relying Party ID के लिए एक पासकी बनाई जा सकती है।

Updates और support के लिए हमारी Passkeys Community से जुड़ें.

जुड़ें

गलती:

आपने विकास शुरू किया और अपने 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 में न हो।

गलती:

आप एक साथ एक नेटिव और वेब ऐप विकसित कर रहे हैं। चीजों को गति देने के लिए, आप दो अलग-अलग WebAuthn सर्वर (नेटिव और वेब ऐप के लिए अलग-अलग Relying Party IDs के साथ) का उपयोग करते हैं। जैसे ही आपके उपयोगकर्ता पहली पासकी बनाते हैं, संबंधित Relying Party ID पासकी में सेव हो जाती है। उसी पासकी के साथ क्रॉस-डिवाइस / क्रॉस-प्लेटफ़ॉर्म लॉगिन की अनुमति देना, उदा. वेब ऐप में बनाई गई पासकी के साथ और नेटिव ऐप में साइन-इन करने का प्रयास करना, अब संभव नहीं है। दो WebAuthn सर्वर को मर्ज करने से वे पासकी छोड़ दी जाएंगी जो पुराने WebAuthn सर्वर (पुराने Relying Party ID) के साथ पंजीकृत थीं और आपके उपयोगकर्ता इन पासकी के साथ लॉगिन नहीं कर सकते।

समाधान:

यदि आपके पास कई एप्लिकेशन (उदा. एक वेब ऐप और एक नेटिव ऐप) हैं, तो हमेशा केवल एक WebAuthn सर्वर रखें और अपने सभी ऐप्स के लिए केवल एक Relying Party ID परिभाषित करें। इन ऐप्स के बीच लिंकिंग ऊपर बताए गए चरणों के माध्यम से की जा सकती है।

गलती:

आप अपना एप्लिकेशन विकसित करना शुरू करते हैं, एसोसिएशन फ़ाइलों को कॉन्फ़िगर करते हैं और उन्हें अपने सर्वर पर तैनात करते हैं। किसी कारण से, आपको अभी भी त्रुटि संदेश मिल रहे हैं और आपको मूल कारण नहीं मिल रहा है।

समाधान:

त्रुटि संदेश का एक संभावित कारण एक विकृत या अगम्य एसोसिएशन फ़ाइल हो सकता है। सर्वर पर किसी भी एसोसिएशन फ़ाइल को तैनात करने से पहले, हम iOS और Android के लिए प्रदान किए गए टूल के माध्यम से एसोसिएशन फ़ाइल की वैधता और पहुंच (अक्सर ये फ़ाइलें एक मजबूत VPN या फ़ायरवॉल के पीछे हो सकती हैं जो Apple और Google के क्रॉलर के लिए उचित पहुंच को रोकती हैं) की जांच करने की अत्यधिक अनुशंसा करते हैं।

गलती:

आपने अपनी 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 होगा)।

गलती:

आप एक Android ऐप विकसित करना शुरू करते हैं और इसे Android एम्यूलेटर पर परीक्षण करना चाहते हैं। कुछ के लिए, कारण आपको त्रुटि संदेश मिल रहे हैं, भले ही आपने Android एम्यूलेटर को ठीक से सेट किया हो और अन्य ऐप इस पर सुचारू रूप से काम करते प्रतीत होते हों।

समाधान:

पासकी एप्लिकेशन का परीक्षण करते समय Android संस्करण, Play Store समर्थन और API संस्करण एक प्रमुख भूमिका निभाते हैं। इसके अलावा, आपको Google खाते में लॉग इन होना चाहिए। विवरण के लिए कृपया हमारे समस्या निवारण अनुभाग को देखें।

हमारी समग्र सिफ़ारिश यह है कि आप अपने एप्लिकेशन परिदृश्य और आवश्यकताओं के आधार पर अपनी Relying Party ID का सावधानीपूर्वक चुनाव करें। नीचे, हमने सबसे सामान्य उपयोग के मामलों को एकत्र किया है, लेकिन हमारी सामान्य सिफ़ारिश यह है कि आपको अपनी Relying Party ID के रूप में अपना रूट डोमेन चुनने का लक्ष्य रखना चाहिए और इस तरह से अपना ऑथेंटिकेशन कॉन्फ़िगर करना चाहिए। Corbado के साथ, हमने इसे आपके लिए पहले से ही इस तरह से पूर्व-कॉन्फ़िगर कर दिया है (क्योंकि यह सभी तकनीकी सेटअप के लिए सहज पासकी ऑथेंटिकेशन प्रदान करने के हमारे दृष्टिकोण का हिस्सा है। हमारे UI घटक और SDK आपके रूट डोमेन के साथ Relying Party ID के रूप में उपयोग करने के लिए तैयार हैं)।

निम्नलिखित में, हम एक बहुत ही विशिष्ट निर्णय ट्री प्रदान करते हैं जो आपको सही Relying Party ID निर्धारित करने में मदद करेगा और अपने पासकी समाधान के रूप में Corbado का उपयोग करते समय आपको एसोसिएशन फ़ाइलों को कैसे संभालना / होस्ट करना चाहिए।

पहला निर्णय यह है कि क्या आप विकास या उत्पादन परिवेश में हैं। निर्णय का अगला स्तर जो आपको करना है वह आपके एप्लिकेशन परिदृश्य पर आधारित है: क्या आपके पास केवल एक नेटिव ऐप है या एक नेटिव और वेब ऐप है।

विकास परिवेश के लिए, हम मानते हैं कि आप जल्दी से विकास और परीक्षण शुरू करना चाहते हैं। यदि आप लाइव जाना चाहते हैं तो Relying Party ID को बाद में बदला जा सकता है।

• Relying Party ID सेट करें = pro-XXX.frontendapi.cloud.corbado.io (डिफ़ॉल्ट मान)
• Corbado आपके लिए एसोसिएशन फ़ाइल होस्ट करता है
• आपके लिए कोई DNS ToDo नहीं

एक ही समय में वेब ऐप और नेटिव ऐप दोनों का परीक्षण करना आसानी से संभव नहीं है

विकल्प 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) जोड़ें (उदाहरण के तौर पर)

उत्पादन परिवेश में, आपको यह तय करना होगा कि क्या आप Relying Party ID (उदा. auth.acme.com) के रूप में एक सबडोमेन के साथ ठीक हैं या यदि आप Relying Party ID (उदा. acme.com) के रूप में एक रूट डोमेन चाहते हैं।

• Relying Party ID सेट करें = auth.acme.com
• Corbado आपके लिए एसोसिएशन फ़ाइल होस्ट करता है
• auth.acme.com से CNAME सेट करें => pro-XXX.frontendapi.cloud.corbado.io

• Relying Party ID सेट करें = auth.acme.com
• Corbado आपके लिए एसोसिएशन फ़ाइल होस्ट करता है
• auth.acme.com से CNAME सेट करें => pro-XXX.frontendapi.cloud.corbado.io (कुकीज़ के काम करने के लिए भी आवश्यक है यदि आप Corbado के सत्र प्रबंधन का उपयोग करते हैं)

• Relying Party ID सेट करें = acme.com
• एसोसिएशन फ़ाइल को अपने सर्वर पर acme.com/.well-known/<association file> पर स्वयं होस्ट करें
• आपके लिए कोई DNS ToDo नहीं

• Relying Party ID सेट करें = acme.com
• एसोसिएशन फ़ाइल को अपने सर्वर पर acme.com/.well-known/<association file> पर स्वयं होस्ट करें
• यदि आप, Corbado के सत्र प्रबंधन का उपयोग करते हैं, तो आपको कुकीज़ को काम करने के लिए auth.acme.com => pro-XXX.frontendapi.cloud.corbado.io से CNAME सेट करने की आवश्यकता है (यह CNAME पूरी तरह से सत्र प्रबंधन के लिए Relying Party ID के लिए आवश्यक नहीं है)

निम्नलिखित निर्णय ट्री सभी कॉन्फ़िगरेशन पथों को सारांशित करता है।

Relying Party ID WebAuthn और पासकी-आधारित ऑथेंटिकेशन की एक आधारशिला है और मजबूत फ़िशिंग-प्रतिरोध प्रदान करती है। इसे ठीक से कॉन्फ़िगर करना, डोमेन मिलान की जटिलताओं को समझना, और नेटिव ऐप्स के लिए सही परिनियोजन सुनिश्चित करना महत्वपूर्ण है। इस ब्लॉग पोस्ट ने आपको दिखाया कि उन्हें सही तरीके से कैसे सेट किया जाए और विभिन्न गलतियों को कैसे संभाला जाए। एक बार आपका rpID कॉन्फ़िगरेशन ठोस हो जाने पर, वास्तविक अपनाने को गति देने के लिए अपने पासकी निर्माण प्रवाह और पासकी लॉगिन प्रवाह को अनुकूलित करने पर ध्यान केंद्रित करें। नेटिव ऐप के लिए पासकी सेट करने के बारे में अधिक जानकारी के लिए, हम Flutter में पासकी के बारे में पढ़ने की सलाह देते हैं।

यदि आपके कोई और प्रश्न हैं या सहायता की आवश्यकता है, तो बेझिझक संपर्क करें।

Corbado के बारे में

Corbado बड़े पैमाने पर consumer authentication चलाने वाली CIAM टीमों के लिए Passkey Intelligence Platform है। हम आपको वह दिखाते हैं जो IDP logs और सामान्य analytics tools नहीं दिखा सकते: कौन-से devices, OS versions, browsers और credential managers passkeys को support करते हैं, क्यों enrollments login में नहीं बदलते, WebAuthn flow कहाँ fail होता है, और कब कोई OS या browser update चुपचाप login को तोड़ देता है — और यह सब Okta, Auth0, Ping, Cognito या आपके in-house IDP को बदले बिना। दो products: Corbado Observe जोड़ता है passkeys और किसी भी अन्य login method के लिए observability। Corbado Connect देता है analytics के साथ built-in managed passkeys (आपके IDP के साथ-साथ)। VicRoads, Corbado के साथ 5M+ users के लिए passkeys चला रहा है (+80% passkey activation)। Passkey विशेषज्ञ से बात करें →

ऑथेंटिकेटर पासकी में सेव की गई Relying Party ID के विरुद्ध ब्राउज़र के वास्तविक ऑरिजिन की तुलना करता है। यदि कोई हमलावर किसी अलग डोमेन पर एक नकली साइट होस्ट करता है, तो ऑरिजिन बेमेल के कारण ऑथेंटिकेशन स्वचालित रूप से विफल हो जाता है, भले ही जाली चुनौती वैध RP ID का दावा करती हो। इस बाइंडिंग का अर्थ है कि paypal.com पर पंजीकृत पासकी का उपयोग paybal.com जैसे दिखने वाले डोमेन पर नहीं किया जा सकता है।

RP ID को बदलने से सभी मौजूदा पासकी अमान्य हो जाती हैं क्योंकि प्रत्येक क्रेडेंशियल में सेव की गई RP ID अब नए मान से मेल नहीं खाएगी। केवल अपवाद तब होते हैं जब नया RP ID पुराने का सबडोमेन होता है या जब Related Origin Requests .well-known/webauthn के माध्यम से कॉन्फ़िगर किए जाते हैं। इस अपरिवर्तनीय समस्या से बचने के लिए शुरू से ही रूट डोमेन को RP ID के रूप में चुनें।

iOS apple-app-site-association फ़ाइल को सीधे आपके सर्वर से प्राप्त नहीं करता है। यह Apple के CDN का उपयोग करता है, जिसमें नई तैनात या अद्यतन फ़ाइल को कैश करने में 24 घंटे तक का समय लग सकता है। विकास के दौरान, कैशिंग को पूरी तरह से बायपास करने के लिए Relying Party ID में ?mode=developer जोड़ें।

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