WebAuthn Transports: इंटरनल और हाइब्रिड ट्रांसपोर्ट

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

व्हाइटपेपर पाएं

नोट: WebAuthn स्पेसिफिकेशन के अनुसार, खाली ट्रांसपोर्ट अनुक्रम का अर्थ है कि ट्रांसपोर्ट जानकारी उपलब्ध नहीं है या प्राइवेसी के लिए रोक दी गई है। अक्सर ब्राउज़रों द्वारा इसे ऐसे माना जाता है जैसे सभी ट्रांसपोर्ट संभव हो सकते हैं।

विभिन्न प्लेटफ़ॉर्म पर पासकी लागू करते समय, डेवलपर्स को एक महत्वपूर्ण निर्णय का सामना करना पड़ता है:

• इष्टतम क्रॉस-डिवाइस प्रमाणीकरण अनुभव सुनिश्चित करने के लिए आपको WebAuthn ट्रांसपोर्ट, विशेष रूप से इंटरनल और हाइब्रिड ट्रांसपोर्ट को कैसे संभालना चाहिए?

इसका उत्तर WebAuthn ट्रांसपोर्ट को समझने में निहित है - एक तकनीकी विवरण जो यह निर्धारित करता है कि ऑथेंटिकेटर रिलाइंग पार्टीज़ के साथ कैसे संवाद करते हैं। हालांकि ट्रांसपोर्ट सिद्धांत रूप में सीधे लगते हैं, उनका कार्यान्वयन वेब ब्राउज़र, नेटिव iOS और नेटिव Android एप्लिकेशन में काफी भिन्न होता है, विशेष रूप से इंटरनल और हाइब्रिड ट्रांसपोर्ट हैंडलिंग के लिए।

यह लेख परीक्षण करता है कि विभिन्न प्लेटफ़ॉर्म पर WebAuthn ट्रांसपोर्ट कैसे काम करते हैं और इंटरनल और हाइब्रिड ट्रांसपोर्ट को संभालने के लिए दो अलग-अलग दृष्टिकोण प्रस्तुत करता है - जिनमें से प्रत्येक के अपने ट्रेड-ऑफ़ हैं।

इस लेख में शामिल हैं:

1. WebAuthn ट्रांसपोर्ट: वेब, iOS और Android पर इंटरनल, हाइब्रिड और प्लेटफ़ॉर्म ऑथेंटिकेटर
2. दो दृष्टिकोण: स्पेक-कंप्लायंट बनाम अनुकूलित इंटरनल और हाइब्रिड ट्रांसपोर्ट हैंडलिंग
3. क्रॉस-डिवाइस प्रमाणीकरण कार्यान्वयन सर्वोत्तम प्रथाएं और सिफारिशें

WebAuthn ट्रांसपोर्ट ऑथेंटिकेटर और क्लाइंट डिवाइस के बीच संचार विधियों को परिभाषित करते हैं। WebAuthn Level 3 स्पेसिफिकेशन छह ट्रांसपोर्ट प्रकारों को परिभाषित करता है:

usb: उन हार्डवेयर सिक्योरिटी कीज़ द्वारा उपयोग किया जाता है जो USB पोर्ट के माध्यम से जुड़ती हैं, जैसे कि YubiKeys या अन्य FIDO2 सिक्योरिटी टोकन।

nfc: नियर फील्ड कम्युनिकेशन के माध्यम से ऑथेंटिकेटर के साथ संचार को सक्षम करता है, जिससे उपयोगकर्ता अपनी सिक्योरिटी की या NFC-सक्षम डिवाइस को टैप कर सकते हैं।

ble: ब्लूटूथ लो एनर्जी के माध्यम से प्रमाणीकरण की सुविधा देता है, जिससे बाहरी ऑथेंटिकेटर के साथ वायरलेस संचार सक्षम होता है।

smart-card: स्मार्ट कार्ड रीडर के लिए उपयोग किया जाता है, जिससे स्मार्ट कार्ड के माध्यम से प्रमाणीकरण की अनुमति मिलती है।

hybrid: क्रॉस-डिवाइस प्रमाणीकरण को सक्षम करता है, आमतौर पर जहां एक उपयोगकर्ता डिवाइस में प्रमाणीकरण करने के लिए QR कोड को स्कैन करता है - जैसे डेस्कटॉप ब्राउज़र पर प्रमाणीकरण करने के लिए फ़ोन का उपयोग करना, या इसके विपरीत। यह ट्रांसपोर्ट डेस्कटॉप और मोबाइल डिवाइस दोनों पर QR कोड संकेत ट्रिगर कर सकता है, जो संदर्भ के आधार पर हमेशा वांछनीय नहीं हो सकता है। नोट: hybrid को WebAuthn Level 3 में जोड़ा गया था।

internal: ऑथेंटिकेटर डिवाइस के भीतर ही एम्बेडेड होता है - जैसे iPhones पर iCloud Keychain (Face ID या Touch ID के माध्यम से सत्यापित), PCs पर Windows Hello, या Android डिवाइस पर Google Password Manager। ये प्लेटफ़ॉर्म ऑथेंटिकेटर हैं।

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

ट्रांसपोर्ट हैंडलिंग विभिन्न प्लेटफ़ॉर्म पर काफी भिन्न होती है, जिससे डेवलपर्स को अनुकूलता चुनौतियों का सामना करना पड़ता है।

ब्राउज़र ऑथेंटिकेटर से ट्रांसपोर्ट जानकारी प्राप्त करते हैं और प्रमाणीकरण प्रवाह के दौरान इसका सम्मान करते हैं। जब आप Chrome, Safari, या Edge में पासकी बनाते हैं, तो ब्राउज़र का क्रेडेंशियल मैनेजर ट्रांसपोर्ट डेटा प्रदान करता है जो अंतर्निहित ऑथेंटिकेटर के आधार पर भिन्न होता है:

प्लेटफ़ॉर्म ऑथेंटिकेटर: Windows Hello केवल ["internal"] प्रदान करता है, जो इसकी डिवाइस-बाउंड प्रकृति को दर्शाता है। हालांकि, जब Chrome ऑथेंटिकेटर के रूप में Google Password Manager का उपयोग करता है, तो यह ["internal", "hybrid"] प्रदान करता है क्योंकि Google Password Manager Android फ़ोन के माध्यम से क्रॉस-डिवाइस प्रमाणीकरण का समर्थन करता है।

हार्डवेयर सिक्योरिटी कीज़: उनकी वास्तविक क्षमताओं के आधार पर विशिष्ट ट्रांसपोर्ट जैसे ["usb", "nfc"] प्रदान करती हैं।

क्लाउड-सिंक्ड क्रेडेंशियल मैनेजर: Safari में iCloud Keychain और Chrome में Google Password Manager आमतौर पर स्थानीय और क्रॉस-डिवाइस प्रमाणीकरण दोनों प्रवाह का समर्थन करने के लिए ["internal", "hybrid"] प्रदान करते हैं।

यह जानकारी वेब संदर्भों में मज़बूती से प्रवाहित होती है, हालांकि विशिष्ट ट्रांसपोर्ट इस बात पर निर्भर करते हैं कि ब्राउज़र क्रेडेंशियल स्टोरेज के लिए किस ऑथेंटिकेटर का चयन करता है।

दस्तावेज़ीकरण: W3C WebAuthn स्पेसिफिकेशन

Android का Credential Manager API वेब ब्राउज़र के समान व्यवहार करता है। नेटिव Android ऐप्स में पासकी बनाते समय, Credential Manager वह ट्रांसपोर्ट जानकारी प्रदान करता है जो वेब व्यवहार को दर्शाती है - प्लेटफ़ॉर्म ऑथेंटिकेटर अपनी क्षमताओं की सटीक रिपोर्ट करते हैं, और सिस्टम ट्रांसपोर्ट डेटा को लगातार संभालता है। Android डेवलपर्स विशेष हैंडलिंग के बिना इस जानकारी पर भरोसा कर सकते हैं।

दस्तावेज़ीकरण: Android Credential Manager

iOS अधिक जटिल स्थिति प्रस्तुत करता है। Apple का AuthenticationServices फ्रेमवर्क ऑथेंटिकेटर प्रकार के आधार पर ट्रांसपोर्ट को अलग तरह से संभालता है:

प्लेटफ़ॉर्म ऑथेंटिकेटर (iCloud Keychain, Face ID या Touch ID के माध्यम से सत्यापित): अक्सर पासकी निर्माण के दौरान खाली ट्रांसपोर्ट ऐरे लौटाते हैं। यह इंगित करता है कि ट्रांसपोर्ट जानकारी उपलब्ध नहीं है या प्राइवेसी के लिए रोक दी गई है - WebAuthn स्पेसिफिकेशन के अनुसार, जब ट्रांसपोर्ट जानकारी अज्ञात हो या प्राइवेसी बनाए रखने के लिए यूजर एजेंट खाली अनुक्रम लौटा सकते हैं। रिलाइंग पार्टी को ट्रांसपोर्ट को गारंटी के बजाय संकेत के रूप में मानना चाहिए।

सिक्योरिटी कीज़: अपेक्षित पैटर्न का पालन करते हुए, जब iOS डिवाइस के साथ उपयोग किया जाता है, तो ट्रांसपोर्ट जानकारी (उदा., ["usb"], ["nfc"]) प्रदान करती हैं।

दस्तावेज़ीकरण: Apple AuthenticationServices

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

मुख्य बातें:

प्लेटफ़ॉर्म ऑथेंटिकेटर हावी हैं: अधिकांश पासकीज़ internal ट्रांसपोर्ट का उपयोग करती हैं, जिसे अक्सर क्रॉस-डिवाइस प्रमाणीकरण समर्थन के लिए hybrid के साथ जोड़ा जाता है। यह प्लेटफ़ॉर्म ऑथेंटिकेटर (iCloud Keychain, Google Password Manager) पर उपभोक्ता फ़ोकस को दर्शाता है।

खाली ऐरे आम हैं: iOS नेटिव एप्लिकेशन अक्सर प्लेटफ़ॉर्म ऑथेंटिकेटर के लिए खाली ट्रांसपोर्ट ऐरे लौटाते हैं, जो प्रोडक्शन क्रेडेंशियल के एक महत्वपूर्ण हिस्से का प्रतिनिधित्व करते हैं। जैसा कि धारा 2.2.3 में चर्चा की गई है, ये व्यापक ट्रांसपोर्ट समर्थन के बजाय अनुपलब्ध ट्रांसपोर्ट जानकारी को इंगित करते हैं।

सिक्योरिटी कीज़ दुर्लभ हैं: हार्डवेयर सिक्योरिटी कीज़ (usb, nfc) प्रोडक्शन पासकीज़ के एक छोटे अंश का प्रतिनिधित्व करती हैं, जो उपभोक्ता एप्लिकेशन के बजाय एंटरप्राइज़ या उच्च-सुरक्षा परिदृश्यों में उनके प्राथमिक उपयोग का संकेत देती हैं।

क्रम भिन्नताएं मौजूद हैं: ऐरे में ट्रांसपोर्ट का क्रम (["internal", "hybrid"] बनाम ["hybrid", "internal"]) प्लेटफ़ॉर्म और ऑथेंटिकेटर कार्यान्वयन के आधार पर भिन्न होता है लेकिन इसमें कोई कार्यात्मक अंतर नहीं होता है - दोनों समान ट्रांसपोर्ट विधियों के समर्थन का संकेत देते हैं।

विरासत शब्दावली: cable ट्रांसपोर्ट आइडेंटिफ़ायर कभी-कभी पुराने कार्यान्वयनों में प्रकट होता है और hybrid (caBLE = क्लाउड-असिस्टेड ब्लूटूथ लो एनर्जी, हाइब्रिड ट्रांसपोर्ट का मूल नाम) का पर्याय है।

यह वितरण internal और hybrid ट्रांसपोर्ट को सही ढंग से संभालने के महत्व को पुष्ट करता है, क्योंकि वे वास्तविक दुनिया के पासकी कार्यान्वयन के भारी बहुमत के लिए ज़िम्मेदार हैं।

ट्रांसपोर्ट की उपलब्धता दिखाती है कि ऑथेंटिकेटर क्या रिपोर्ट करते हैं, न कि यह कि परिणामी प्रवाह पूरा होता है या नहीं। Corbado Passkey Benchmark 2026 क्रॉस-डिवाइस प्रमाणीकरण पूर्णता विश्लेषण Q1 2026 hybrid-ट्रांसपोर्ट पूर्णता को समग्र रूप से Windows वेब पर 60–78% और macOS वेब पर 66–86% मापता है, जो सेम-डिवाइस नज़ के लिए 79–98% (Win) / 83–98% (macOS) बनाम आइडेंटिफ़ायर-फ़र्स्ट फ़्लो के लिए 52–67% (Win) / 59–76% (macOS) में विभाजित होता है। hybrid को रूटिंग लॉजिक में सबसे अधिक लागत वाले ट्रांसपोर्ट के रूप में मानें और ऐसे फ़्लो को प्राथमिकता दें जो उपयोगकर्ता को क्रेडेंशियल रखने वाले डिवाइस पर ही रखें।

वही ऑथेंटिकेटर अक्सर प्लेटफ़ॉर्म, संस्करण और कार्यान्वयन संदर्भ के आधार पर विभिन्न ट्रांसपोर्ट पैटर्न की रिपोर्ट करता है। यह भिन्नता सामान्य और अपेक्षित है:

iCloud Keychain तीन पैटर्न प्रदर्शित करता है:

• ["internal", "hybrid"] - सबसे आम, आमतौर पर वेब ब्राउज़र से
• [] (खाली ऐरे) - बहुत आम, iOS नेटिव ऐप्स से
• ["hybrid", "internal"] - कम आम, क्रम भिन्नता
• केवल ["internal"] या ["hybrid"] - दुर्लभ एज केस

Google Password Manager सबसे अधिक भिन्नता दिखाता है:

• ["hybrid", "internal"] - सबसे आम पैटर्न
• ["internal", "hybrid"] - आम वैकल्पिक क्रम
• ["internal", "cable"] - विरासत कार्यान्वयन (cable = हाइब्रिड के लिए पुराना शब्द)
• [] (खाली ऐरे) - कुछ नेटिव संदर्भों से
• सिंगल ट्रांसपोर्ट शायद ही कभी

Windows Hello सबसे सुसंगत है:

• ["internal"] - प्रमुख पैटर्न (डिज़ाइन द्वारा डिवाइस-बाउंड)

पासवर्ड मैनेजर जैसे 1Password, Bitwarden, Dashlane, और LastPass सभी समान भिन्नता पैटर्न दिखाते हैं:

• ["internal", "hybrid"] और ["hybrid", "internal"] दोनों क्रम
• नेटिव ऐप संदर्भों से खाली ऐरे []
• कभी-कभी केवल ["internal"]

Samsung Pass (Android इकोसिस्टम) मुख्य रूप से उपयोग करता है:

• ["hybrid", "internal"] और ["internal", "hybrid"] - दोनों क्रम आम हैं

प्लेटफ़ॉर्म अंतर: वही ऑथेंटिकेटर वेब बनाम नेटिव, iOS बनाम Android, या Windows बनाम macOS पर अलग तरह से व्यवहार करता है।

संस्करण विकास: समय के साथ ट्रांसपोर्ट रिपोर्टिंग विकसित हुई है। पुराने संस्करण hybrid के बजाय cable का उपयोग कर सकते हैं, या विभिन्न संयोजनों की रिपोर्ट कर सकते हैं।

कार्यान्वयन विकल्प: कुछ ऑथेंटिकेटर पहले internal को प्राथमिकता देते हैं, अन्य hybrid को। क्रम का कोई कार्यात्मक प्रभाव नहीं है लेकिन यह कार्यान्वयन के अनुसार भिन्न होता है।

संदर्भ संवेदनशीलता: नेटिव ऐप्स, विशेष रूप से iOS पर, अक्सर खाली ऐरे प्राप्त करते हैं, यहां तक कि उन ऑथेंटिकेटरों से भी जो वेब संदर्भों में पूर्ण ट्रांसपोर्ट रिपोर्ट करते हैं।

मुख्य बात: यह न मानें कि दिए गए ऑथेंटिकेटर के लिए ट्रांसपोर्ट ऐरे सुसंगत होंगे। सटीक ऐरे मिलान के बजाय विशिष्ट ट्रांसपोर्ट की उपस्थिति पर ध्यान केंद्रित करते हुए, सभी विविधताओं को इनायत से संभालने के लिए अपना कार्यान्वयन डिज़ाइन करें।

डेवलपर्स को एक विकल्प का सामना करना पड़ता है: विनिर्देश का कड़ाई से पालन करें, या उपयोगकर्ता अनुभव के लिए इंटरनल और हाइब्रिड ट्रांसपोर्ट को अनुकूलित करें। प्रत्येक दृष्टिकोण के अपने गुण और दोष हैं।

यह दृष्टिकोण WebAuthn स्पेसिफिकेशन के साथ संरेखित है: ट्रांसपोर्ट का उपयोग ठीक वैसे ही करें जैसे वे क्रेडेंशियल पंजीकरण के दौरान ऑथेंटिकेटर द्वारा प्रदान किए गए हैं, और प्रमाणीकरण के दौरान उन्हें अपरिवर्तित वापस भेजें।

कार्यान्वयन: जब कोई पासकी बनाई जाती है, तो ऑथेंटिकेटर प्रतिक्रिया से transports ऐरे को सुरक्षित रखें। प्रमाणीकरण के दौरान, allowCredentials सूची में इन सटीक ट्रांसपोर्ट को शामिल करें:

{
    "allowCredentials": [
        {
            "id": "credential-id-base64",
            "type": "public-key",
            "transports": ["internal", "hybrid"]
        }
    ]
}

लाभ:

• विशिष्टता अनुपालन: WebAuthn मानकों का सटीक रूप से पालन करता है, भविष्य के प्लेटफ़ॉर्म अपडेट के साथ अनुकूलता सुनिश्चित करता है
• सिक्योरिटी की विश्वसनीयता: हार्डवेयर सिक्योरिटी कीज़ (YubiKeys, आदि) के लिए पूरी तरह से काम करता है जो हमेशा सटीक ट्रांसपोर्ट जानकारी प्रदान करती हैं
• अमान्य विकल्पों को रोकता है: ऐसे प्रमाणीकरण तरीके पेश करने से बचता है जो वास्तव में समर्थित नहीं हैं - उदाहरण के लिए, Windows Hello क्रेडेंशियल के लिए QR कोड ट्रिगर नहीं करेगा

हानि:

• iOS का खाली ऐरे व्यवहार: iOS पर प्लेटफ़ॉर्म ऑथेंटिकेटर खाली ट्रांसपोर्ट लौटाते हैं, जो अनुपलब्ध ट्रांसपोर्ट जानकारी को इंगित करता है - यह निर्धारित करते समय कि कौन से प्रमाणीकरण विकल्प दिखाने हैं, प्लेटफ़ॉर्म इसकी अलग तरह से व्याख्या कर सकते हैं
• अवांछित विकल्प दिखा सकता है: उपभोक्ता एप्लिकेशन में सिक्योरिटी की विकल्प (USB, NFC) पेश कर सकता है जहां उनकी अपेक्षा नहीं की जाती है
• असंगत उपयोगकर्ता अनुभव: विभिन्न प्लेटफ़ॉर्म एक ही खाते के लिए विभिन्न प्रमाणीकरण विकल्प प्रदान करते हैं

इसके लिए सर्वश्रेष्ठ: मानकों के अनुपालन को प्राथमिकता देने वाले एप्लिकेशन, विविध ऑथेंटिकेटर प्रकारों के साथ एंटरप्राइज़ वातावरण।

यह दृष्टिकोण विशिष्ट अनुकूलन लक्ष्यों के आधार पर इंटरनल और हाइब्रिड ट्रांसपोर्ट को चुनिंदा रूप से संशोधित करके उपयोगकर्ता अनुभव को प्राथमिकता देता है। एक ब्लैंकेट नियम के बजाय, इन सामान्य अनुकूलन परिदृश्यों पर विचार करें:

समस्या: iOS प्लेटफ़ॉर्म ऑथेंटिकेटर खाली ट्रांसपोर्ट ऐरे लौटाते हैं। जब इसे खाली छोड़ दिया जाता है या बैकएंड द्वारा भरा जाता है, तो उपयोगकर्ताओं को प्लेटफ़ॉर्म विकल्पों के साथ सिक्योरिटी की संकेत (USB, NFC) दिखाई दे सकते हैं, जिससे उपभोक्ता एप्लिकेशन में भ्रम पैदा होता है।

समाधान: iOS प्लेटफ़ॉर्म ऑथेंटिकेटरों के लिए स्पष्ट रूप से ट्रांसपोर्ट को ["hybrid", "internal"] पर सेट करें। यह सुनिश्चित करता है कि केवल प्लेटफ़ॉर्म प्रमाणीकरण और क्रॉस-डिवाइस फ़्लो की पेशकश की जाती है, और सिक्योरिटी की विकल्प छिप जाते हैं।

// When persisting iOS platform authenticator credentials
if (platform === "iOS" && authenticatorAttachment === "platform") {
    transports = ["hybrid", "internal"];
}

परिणाम: iOS-निर्मित पासकी के लिए बिना सिक्योरिटी की संकेतों के साफ़ प्रमाणीकरण UI।

समस्या: मोबाइल डिवाइस पर प्रमाणीकरण करते समय, क्रॉस-डिवाइस प्रमाणीकरण के लिए QR कोड दिखाना ख़राब UX बनाता है - उपयोगकर्ता पहले से ही एक मोबाइल डिवाइस पर हैं जहां उनके पासकी उपलब्ध हैं।

समाधान: जब उपयोगकर्ता मोबाइल डिवाइस से प्रमाणीकरण कर रहा हो, तो hybrid ट्रांसपोर्ट को हटा दें, और केवल ["internal"] छोड़ दें।

// When building allowCredentials for authentication
const transports = isMobileDevice
    ? credentials.transports.filter((t) => t !== "hybrid")
    : credentials.transports;

परिणाम: मोबाइल उपयोगकर्ताओं को बिना अनावश्यक QR कोड संकेतों के केवल प्रत्यक्ष प्रमाणीकरण विकल्प दिखाई देते हैं।

⚠️ सावधानी: ट्रांसपोर्ट हेरफेर हमेशा प्लेटफ़ॉर्म पर सुसंगत परिणाम नहीं देता है। व्यापक परीक्षण से पता चलता है कि ब्राउज़र और OS संयोजन ट्रांसपोर्ट को अलग तरह से संभालते हैं:

• कुछ प्लेटफ़ॉर्म QR कोड दिखाते हैं, तब भी जब hybrid को ट्रांसपोर्ट से बाहर रखा गया हो
• अन्य QR कोड छिपा देते हैं, तब भी जब hybrid शामिल हो
• Windows, macOS, और iOS पर Chrome, Edge, Safari, और Firefox के बीच व्यवहार काफी भिन्न होता है

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

ये अनुकूलन संकेत हैं: WebAuthn ट्रांसपोर्ट हेरफेर से परे प्रमाणीकरण UX को अनुकूलित करने के लिए अन्य तंत्र प्रदान करता है - जैसे कि hints।

ट्रांसपोर्ट व्यवहार अप्रत्याशित है: hybrid ट्रांसपोर्ट के माध्यम से क्रॉस-डिवाइस प्रमाणीकरण (CDA) ब्राउज़र और OS संयोजनों में असंगत व्यवहार प्रदर्शित करता है। वास्तविक दुनिया का परीक्षण प्रदर्शित करता है कि ट्रांसपोर्ट मान विशिष्ट UI व्यवहार की गारंटी नहीं देते हैं - प्लेटफ़ॉर्म ट्रांसपोर्ट की व्याख्या करते हैं और उन्हें अलग तरह से संभालते हैं, जिससे अप्रत्याशित परिणाम सामने आते हैं।

प्लेटफ़ॉर्म-विशिष्ट जटिलता: ट्रांसपोर्ट को स्पष्ट रूप से नियंत्रित करते समय, आपको प्लेटफ़ॉर्म अंतरों को ध्यान में रखना होगा:

• iOS: प्लेटफ़ॉर्म ऑथेंटिकेटरों के लिए खाली ऐरे भेजता है; भरने की आवश्यकता है
• Windows Hello: केवल ["internal"] ही रहना चाहिए; hybrid जोड़ने से अवांछित QR कोड ट्रिगर होते हैं
• वेब और Android: आम तौर पर सटीक ट्रांसपोर्ट जानकारी प्रदान करते हैं
• CDA भिन्नताएं: ट्रांसपोर्ट ऐरे में hybrid उपस्थिति की परवाह किए बिना QR कोड संकेत दिखाई दे सकते हैं या गायब हो सकते हैं

एंड-टू-एंड समझ आवश्यक है: ट्रांसपोर्ट को स्पष्ट रूप से नियंत्रित करने का अर्थ है संपूर्ण प्रवाह की ज़िम्मेदारी लेना। आपको यह समझना चाहिए कि प्रत्येक ट्रांसपोर्ट संयोजन आपके सभी लक्षित प्लेटफ़ॉर्म पर कैसे व्यवहार करता है और पूरी तरह से परीक्षण करना चाहिए। ट्रांसपोर्ट हेरफेर प्रमाणीकरण डेडएंड बना सकता है जहाँ उपयोगकर्ताओं के लिए कोई वैध प्रमाणीकरण पथ मौजूद नहीं है।

लाभ:

• अनुरूप UX: उपयोगकर्ताओं को विशिष्ट संदर्भों में कौन से प्रमाणीकरण विकल्प दिखाई देते हैं, इस पर नियंत्रण रखें
• iOS के खाली ऐरे की समस्या को हल करता है: उन ट्रांसपोर्ट को स्पष्ट रूप से परिभाषित करता है जहाँ iOS कोई ट्रांसपोर्ट प्रदान नहीं करता है
• संदर्भ-जागरूक अनुकूलन: डिवाइस प्रकार के आधार पर प्रमाणीकरण UI को अनुकूलित करें

हानि:

• अप्रत्याशित व्यवहार: ट्रांसपोर्ट हेरफेर सुसंगत UI व्यवहार की गारंटी नहीं देता है - व्यापक परीक्षण से पता चलता है कि प्लेटफ़ॉर्म ट्रांसपोर्ट की अलग तरह से व्याख्या करते हैं, कभी-कभी ट्रांसपोर्ट मानों की परवाह किए बिना विकल्प दिखाते या छिपाते हैं
• प्रमाणीकरण डेडएंड का जोखिम: अत्यधिक प्रतिबंधात्मक ट्रांसपोर्ट फ़िल्टरिंग उपयोगकर्ताओं को पूरी तरह से प्रमाणित करने से रोक सकती है, विशेष रूप से क्रॉस-डिवाइस परिदृश्यों में
• विनिर्देश से विचलित होता है: स्पेक सिफारिशों से दूर हो जाता है, जिससे भविष्य के प्लेटफ़ॉर्म परिवर्तनों के साथ समस्याएं पैदा होने की संभावना है
• रखरखाव का बोझ: प्लेटफ़ॉर्म के विकसित होने के साथ चल रहे प्लेटफ़ॉर्म-विशिष्ट लॉजिक और अपडेट की आवश्यकता होती है
• जटिलता: iOS के खाली ऐरे, Windows Hello बाधाओं और अन्य प्लेटफ़ॉर्म विचित्रताओं को मैन्युअल रूप से संभालना होगा
• परीक्षण ओवरहेड: प्रत्येक अनुकूलन नियम के लिए सभी प्लेटफ़ॉर्म संयोजनों में सत्यापन की आवश्यकता होती है

इसके लिए सर्वश्रेष्ठ: विशिष्ट UX आवश्यकताओं वाले उपभोक्ता एप्लिकेशन, प्लेटफ़ॉर्म-विशिष्ट लॉजिक को बनाए रखने के लिए संसाधनों वाली टीमें, कड़े स्पेक अनुपालन के बजाय सुव्यवस्थित प्रमाणीकरण फ़्लो को प्राथमिकता देने वाले परिदृश्य।

WebAuthn ट्रांसपोर्ट हैंडलिंग अलगाव में मौजूद नहीं है - यह आपकी समग्र पासकी कार्यान्वयन रणनीति का एक हिस्सा है। प्रोडक्शन डिप्लॉयमेंट में दो सामान्य दृष्टिकोण उभरते हैं, जिनमें से प्रत्येक का इंटरनल और हाइब्रिड ट्रांसपोर्ट के उपयोग के लिए अलग-अलग निहितार्थ हैं।

यह दृष्टिकोण लचीलेपन और मानकों के अनुपालन को प्राथमिकता देता है, जिससे उपयोगकर्ताओं को किसी भी संगत ऑथेंटिकेटर के साथ प्रमाणित करने की अनुमति मिलती है।

कार्यान्वयन विशेषताएं:

• प्रमाणीकरण UI: मौजूदा लॉगिन विकल्पों (उपयोगकर्ता नाम/पासवर्ड) के साथ-साथ पासकी बटन दिखाई देता है
• allowCredentials: खाली ऐरे [] पर सेट किया गया है, जो किसी भी क्रेडेंशियल से मेल खाने की अनुमति देता है
• ऑथेंटिकेटर प्रकार: सिक्योरिटी कीज़, क्रॉस-डिवाइस प्रमाणीकरण (QR कोड), प्लेटफ़ॉर्म ऑथेंटिकेटर सभी समर्थित हैं
• नेटिव ऐप आवश्यकताएं: सिक्योरिटी कीज़ सहित सभी प्रमाणीकरण विधियों का समर्थन करना चाहिए
• preferImmediatelyAvailableCredentials: इसका उपयोग नहीं किया जा सकता है, क्योंकि यह परिभाषा के अनुसार सिक्योरिटी कीज़ और QR कोड लॉगिन को बाहर करता है
• ट्रांसपोर्ट हैंडलिंग: सिक्योरिटी की ट्रांसपोर्ट (usb, nfc, ble) सहित सभी ट्रांसपोर्ट प्रकारों को समायोजित करना चाहिए

ट्रांसपोर्ट निहितार्थ:

खाली allowCredentials के साथ, प्रमाणीकरण के दौरान ट्रांसपोर्ट कम महत्वपूर्ण हो जाते हैं - प्लेटफ़ॉर्म सभी उपलब्ध विकल्प दिखाता है। हालाँकि, इसका मतलब है कि उपयोगकर्ताओं को एक साथ सिक्योरिटी की संकेत, QR कोड और प्लेटफ़ॉर्म विकल्प दिखाई दे सकते हैं, जो उपभोक्ता एप्लिकेशन में निर्णय पक्षाघात पैदा कर सकता है।

इसके लिए सर्वश्रेष्ठ: एंटरप्राइज़ वातावरण, सिक्योरिटी की समर्थन की आवश्यकता वाले विविध उपयोगकर्ता आधार वाले एप्लिकेशन, अधिकतम प्रमाणीकरण लचीलेपन को प्राथमिकता देने वाले परिदृश्य।

यह दृष्टिकोण प्लेटफ़ॉर्म ऑथेंटिकेटरों तक पासकी निर्माण को सीमित करके और आइडेंटिफ़ायर-फ़र्स्ट फ़्लो का उपयोग करके उपभोक्ता UX के लिए अनुकूलित करता है।

कार्यान्वयन विशेषताएं:

• पासकी निर्माण: उपयोगकर्ता द्वारा आरंभ किए गए नज़ (लॉगिन के बाद संकेत, स्वचालित निर्माण प्रवाह) तुरंत उपलब्ध ऑथेंटिकेटरों पर ध्यान केंद्रित करने के लिए authenticatorAttachment: "platform" का उपयोग करते हैं
• सिक्योरिटी की समर्थन: authenticatorAttachment प्रतिबंध के बिना वेब खाता सेटिंग्स के माध्यम से उपलब्ध है, जिससे पावर उपयोगकर्ताओं को सिक्योरिटी कीज़ सहित किसी भी ऑथेंटिकेटर का चयन करने की अनुमति मिलती है
• प्रमाणीकरण प्रवाह: आइडेंटिफ़ायर-फ़र्स्ट - उपयोगकर्ता प्रमाणीकरण से पहले ईमेल/उपयोगकर्ता नाम दर्ज करते हैं
• allowCredentials: पहचानकर्ता ज्ञात होने के बाद उपयोगकर्ता के विशिष्ट क्रेडेंशियल्स से पॉप्युलेट किया जाता है (खाली नहीं)
• ऑथेंटिकेटर प्रकार: प्लेटफ़ॉर्म ऑथेंटिकेटर और क्रॉस-डिवाइस प्रमाणीकरण को प्राथमिकता दी जाती है; सिक्योरिटी कीज़ समर्थित हैं लेकिन प्राथमिक फ़्लो में उन्हें बढ़ावा नहीं दिया जाता है
• नेटिव ऐप अनुकूलन: सिक्योरिटी कीज़ या QR कोड के संकेतों के बिना साइलेंट, त्वरित प्रमाणीकरण के लिए preferImmediatelyAvailableCredentials का उपयोग करता है
• क्रॉस-डिवाइस प्रमाणीकरण: वेब पर उपलब्ध; preferImmediatelyAvailableCredentials का उपयोग करते समय नेटिव ऐप्स में जानबूझकर बाहर रखा गया है (उपयोगकर्ता आमतौर पर उस डिवाइस पर प्रमाणित करते हैं जहां उनके पासकी मौजूद हैं)
• ट्रांसपोर्ट हैंडलिंग: internal और hybrid ट्रांसपोर्ट पर प्राथमिक फ़ोकस

ट्रांसपोर्ट निहितार्थ:

चूंकि allowCredentials में विशिष्ट क्रेडेंशियल अपने ट्रांसपोर्ट के साथ होते हैं, इसलिए प्रमाणीकरण अनुभवों को अनुकूलित करने के लिए ट्रांसपोर्ट हैंडलिंग महत्वपूर्ण हो जाती है।

सिक्योरिटी की की वास्तविकता: बड़े पैमाने पर उपभोक्ता परिनियोजन में सिक्योरिटी कीज़ पासकी उपयोग के एक बहुत छोटे हिस्से का प्रतिनिधित्व करती हैं - मुख्य रूप से पावर उपयोगकर्ता या विशिष्ट सुरक्षा आवश्यकताओं वाले उपयोगकर्ता। उपभोक्ता-अनुरूप दृष्टिकोण प्राथमिक फ़्लो को उनके इर्द-गिर्द अनुकूलित किए बिना सिक्योरिटी कीज़ का समर्थन करके इस वास्तविकता को स्वीकार करता है।

द्वि-स्तरीय निर्माण रणनीति: कार्यान्वयन दोहरे निर्माण पथों के माध्यम से अनुकूलित उपभोक्ता UX के साथ सिक्योरिटी की संगतता को संतुलित कर सकते हैं:

• उपयोगकर्ता नज़ और संकेत: लॉगिन के बाद संकेत और स्वचालित निर्माण प्रवाह authenticatorAttachment: "platform" का उपयोग करते हैं, जो उपयोगकर्ताओं को उच्च सफलता दर के साथ तुरंत उपलब्ध पासकी की ओर ले जाते हैं
• वेब खाता सेटिंग्स: authenticatorAttachment के बिना निर्माण की पेशकश करता है, जिससे पावर उपयोगकर्ताओं को सिक्योरिटी कीज़, थर्ड-पार्टी पासवर्ड मैनेजर या कोई भी उपलब्ध ऑथेंटिकेटर चुनने की अनुमति मिलती है

यह पैटर्न प्रमुख कार्यान्वयनों में दिखाई देता है: सिक्योरिटी कीज़ सेटिंग्स के माध्यम से समर्थित और कार्यात्मक होती हैं, लेकिन उपयोगकर्ता-सामना करने वाले नज़ प्रमुख उपयोग के मामले के लिए अनुकूलित होते हैं - प्लेटफ़ॉर्म ऑथेंटिकेटर जो त्वरित, साइलेंट प्रमाणीकरण प्रदान करते हैं।

इसके लिए सर्वश्रेष्ठ: उपभोक्ता एप्लिकेशन, नेटिव मोबाइल ऐप्स, ऑथेंटिकेटर लचीलेपन पर सुव्यवस्थित UX को प्राथमिकता देने वाले परिदृश्य, ऐसे प्लेटफ़ॉर्म जहाँ आइडेंटिफ़ायर-फ़र्स्ट फ़्लो पहले से मौजूद हैं।

उन प्लेटफ़ॉर्म के लिए जो पहले से ही खाते के अस्तित्व को लीक करते हैं या आइडेंटिफ़ायर-फ़र्स्ट फ़्लो (लॉगिन विकल्प देखने से पहले उपयोगकर्ता ईमेल दर्ज करता है) का उपयोग करते हैं, उपभोक्ता-अनुरूप दृष्टिकोण स्वाभाविक रूप से संरेखित होता है। एक बार जब उपयोगकर्ता ने अपना पहचानकर्ता प्रदान कर दिया:

1. बैकएंड मौजूदा पासकीज़ के लिए क्वेरी करता है
2. विशिष्ट क्रेडेंशियल्स और उनके ट्रांसपोर्ट के साथ allowCredentials लौटाता है
3. प्लेटफ़ॉर्म ट्रांसपोर्ट के आधार पर प्रमाणीकरण UI को अनुकूलित कर सकता है
4. कोई अतिरिक्त खाता प्रगणन जोखिम नहीं (पहचानकर्ता पहले ही प्रदान किया गया)

इन परिदृश्यों में, ट्रांसपोर्ट सुरक्षा चिंता के बजाय अनुकूलन टूल बन सकता है। आप डिवाइस संदर्भ (मोबाइल बनाम डेस्कटॉप) और क्रेडेंशियल क्षमताओं के आधार पर प्रमाणीकरण विकल्पों को अनुकूलित कर सकते हैं।

सिफारिश: उन प्लेटफ़ॉर्म के लिए जो पहले से ही आइडेंटिफ़ायर-फ़र्स्ट फ़्लो का उपयोग करते हैं या जहाँ खाता प्रगणन कोई चिंता का विषय नहीं है, स्पष्ट ट्रांसपोर्ट हैंडलिंग के साथ उपभोक्ता-अनुरूप दृष्टिकोण बेहतर UX प्रदान करता है, विशेष रूप से नेटिव मोबाइल एप्लिकेशन में जहाँ preferImmediatelyAvailableCredentials सहज बायोमेट्रिक प्रमाणीकरण सक्षम करता है।

आप इंटरनल और हाइब्रिड ट्रांसपोर्ट को संभालने के लिए कोई भी दृष्टिकोण चुनें, समस्याओं को कम करने के लिए इन प्रथाओं का पालन करें:

पंजीकरण के दौरान ट्रांसपोर्ट को सुरक्षित रखें: हमेशा क्रेडेंशियल ID और सार्वजनिक कुंजी के साथ ऑथेंटिकेटर प्रतिक्रिया से transports ऐरे को स्टोर करें। प्रमाणीकरण प्रवाह के लिए यह डेटा आवश्यक है।

खाली ऐरे को ग्रेसफुली संभालें: iOS प्लेटफ़ॉर्म ऑथेंटिकेटरों से खाली ट्रांसपोर्ट ऐरे प्राप्त करते समय:

• स्पेक-कंप्लायंट: खाली छोड़ दें या ट्रांसपोर्ट प्रॉपर्टी को हटा दें - यह इंगित करता है कि ट्रांसपोर्ट जानकारी अनुपलब्ध है; प्लेटफ़ॉर्म उपलब्ध विकल्प निर्धारित करेंगे
• अनुकूलन दृष्टिकोण: यह नियंत्रित करने के लिए ["internal", "hybrid"] से भरें कि कौन से प्रमाणीकरण विकल्प दिखाए जाएं

वेब बनाम नेटिव ट्रांसपोर्ट रणनीतियां: संदर्भ के आधार पर ट्रांसपोर्ट हैंडलिंग को अलग करें:

• वेब प्रमाणीकरण: सभी ट्रांसपोर्ट को शामिल करें, जिससे USB/NFC के माध्यम से सिक्योरिटी कीज़ सहित व्यापक ऑथेंटिकेटर समर्थन की अनुमति मिलती है
• नेटिव ऐप प्रमाणीकरण: साइलेंट प्रमाणीकरण के लिए preferImmediatelyAvailableCredentials का उपयोग करें; ट्रांसपोर्ट वैसे ही भेजे गए जैसे स्टोर किए गए थे
• सेटिंग्स/प्रबंधन पृष्ठ: पावर उपयोगकर्ताओं के लिए सभी ऑथेंटिकेटर प्रकारों का समर्थन करें

सिक्योरिटी की प्रमाणीकरण को संभालें: जब उपयोगकर्ताओं के पास सिक्योरिटी कीज़ पंजीकृत हों:

• वेब: संग्रहीत क्रेडेंशियल्स में सिक्योरिटी की ट्रांसपोर्ट का पता लगाएं और सुनिश्चित करें कि प्रमाणीकरण प्रवाह उन्हें समायोजित कर सकते हैं
• नेटिव ऐप्स: फ़ॉलबैक प्रमाणीकरण विधियां प्रदान करने या सिक्योरिटी की प्रमाणीकरण के लिए उपयोगकर्ताओं को वेब पर निर्देशित करने पर विचार करें
• हाइब्रिड दृष्टिकोण: नेटिव ऐप्स प्लेटफ़ॉर्म ऑथेंटिकेटर के लिए अनुकूलन करते हैं जबकि वेब पूर्ण ऑथेंटिकेटर लचीलेपन का समर्थन करता है

सभी लक्षित प्लेटफ़ॉर्म पर परीक्षण करें: सभी संयोजनों को कवर करने वाला एक परीक्षण मैट्रिक्स बनाएं:

• पंजीकरण: वेब, iOS नेटिव, Android नेटिव
• प्रमाणीकरण: वेब, iOS नेटिव, Android नेटिव
• सत्यापित करें कि साइलेंट प्रमाणीकरण preferImmediatelyAvailableCredentials के साथ काम करता है
• पुष्टि करें कि सिक्योरिटी कीज़ authenticatorAttachment के बिना सेटिंग्स फ़्लो में काम करती हैं
• सत्यापित करें कि QR कोड केवल उचित संदर्भों में दिखाई देते हैं

ट्रांसपोर्ट सिमेंटिक्स को समझें: खाली और अनुपलब्ध ट्रांसपोर्ट मानों के बीच अंतर को पहचानें:

• खाली ट्रांसपोर्ट ऐरे []: यह इंगित करता है कि ट्रांसपोर्ट जानकारी अनुपलब्ध है या प्राइवेसी के लिए रोक दी गई है। जब यूजर एजेंट ट्रांसपोर्ट क्षमताओं की रिपोर्ट नहीं कर सकते हैं या नहीं करने का विकल्प चुनते हैं, तो वे खाली अनुक्रम प्रदान कर सकते हैं। यह "सभी ट्रांसपोर्ट समर्थित" के बराबर नहीं है - जहां जानकारी अनुपलब्ध हो वहां इसे संकेत के रूप में मानें।
• अनुपलब्ध ट्रांसपोर्ट प्रॉपर्टी: जब क्रेडेंशियल डिस्क्रिप्टर से ट्रांसपोर्ट को हटा दिया जाता है, तो यूजर एजेंट अन्य कारकों के आधार पर उपलब्ध प्रमाणीकरण विधियां निर्धारित करते हैं। संदर्भ मायने रखता है: पंजीकरण प्रतिक्रियाओं बनाम प्रमाणीकरण अनुरोध विकल्पों में, निहितार्थ भिन्न होते हैं।
• ट्रांसपोर्ट संकेत: विनिर्देश के अनुसार, ट्रांसपोर्ट को क्षमताओं की आधिकारिक गारंटी के रूप में नहीं, बल्कि प्रमाणीकरण UI को अनुकूलित करने में यूजर एजेंटों की सहायता के लिए संकेत के रूप में माना जाना चाहिए।

प्लेटफ़ॉर्म परिवर्तनों की निगरानी करें: WebAuthn कार्यान्वयन विकसित हो रहे हैं। Apple, Google, और Microsoft नियमित रूप से अपने ऑथेंटिकेटर व्यवहार को अपडेट करते हैं। ऐसे परिवर्तनों के बारे में सूचित रहें जो ट्रांसपोर्ट हैंडलिंग को प्रभावित कर सकते हैं।

WebAuthn ट्रांसपोर्ट - विशेष रूप से इंटरनल और हाइब्रिड ट्रांसपोर्ट - तकनीकी विवरण हैं जिनका क्रॉस-डिवाइस प्रमाणीकरण पर महत्वपूर्ण व्यावहारिक प्रभाव पड़ता है। आपकी ट्रांसपोर्ट हैंडलिंग रणनीति आपके व्यापक पासकी कार्यान्वयन दृष्टिकोण और लक्षित प्लेटफ़ॉर्म के साथ संरेखित होनी चाहिए।

ट्रांसपोर्ट निर्णय व्यापक रणनीति के अंतर्गत आते हैं: आप ट्रांसपोर्ट को कैसे संभालते हैं यह इस बात पर निर्भर करता है कि क्या आप अधिकतम लचीलेपन (खाली allowCredentials) या उपभोक्ता UX (विशिष्ट क्रेडेंशियल्स के साथ आइडेंटिफ़ायर-फ़र्स्ट) के लिए निर्माण कर रहे हैं। बाद वाला अनुकूलन के लिए ट्रांसपोर्ट को महत्वपूर्ण बनाता है।

प्लेटफ़ॉर्म अंतरों को संभालने की आवश्यकता है: वेब और Android विश्वसनीय ट्रांसपोर्ट जानकारी प्रदान करते हैं, जबकि iOS प्लेटफ़ॉर्म ऑथेंटिकेटर खाली ऐरे लौटाते हैं। Windows Hello केवल ["internal"] भेजता है। प्रोडक्शन डिप्लॉयमेंट के लिए इन अंतरों को समझना आवश्यक है।

दो मान्य ट्रांसपोर्ट दृष्टिकोण: स्पेक-कंप्लायंट (ऑथेंटिकेटर ट्रांसपोर्ट पर भरोसा करें) एंटरप्राइज़ और अधिकतम लचीलेपन वाले परिदृश्यों के लिए अच्छा काम करता है। स्पष्ट नियंत्रण (ट्रांसपोर्ट को अनुकूलित करें) आइडेंटिफ़ायर-फ़र्स्ट फ़्लो वाले उपभोक्ता एप्लिकेशन और नेटिव मोबाइल ऐप्स के अनुकूल है।

आइडेंटिफ़ायर-फ़र्स्ट ट्रांसपोर्ट ऑप्टिमाइज़ेशन को सक्षम करता है: जब उपयोगकर्ता पहले अपना पहचानकर्ता प्रदान करते हैं, तो ट्रांसपोर्ट हैंडलिंग एक शक्तिशाली UX टूल बन जाता है। आप मोबाइल पर अवांछित QR कोड को रोक सकते हैं, सिक्योरिटी की विकल्पों को छिपा सकते हैं, और अतिरिक्त खाता प्रगणन चिंताओं के बिना प्रमाणीकरण को सुव्यवस्थित कर सकते हैं।

एंटरप्राइज़ / अधिकतम लचीलेपन के लिए:

• सभी ऑथेंटिकेटर प्रकारों का समर्थन करने के लिए खाली allowCredentials का उपयोग करें
• ऑथेंटिकेटर द्वारा प्रदान किए गए ट्रांसपोर्ट पर भरोसा करें
• स्वीकार करें कि उपयोगकर्ताओं को अधिक प्रमाणीकरण विकल्प दिखाई देते हैं
• सरल कार्यान्वयन, व्यापक संगतता

उपभोक्ता एप्लिकेशन / नेटिव ऐप्स के लिए:

• आइडेंटिफ़ायर-फ़र्स्ट प्रमाणीकरण प्रवाह लागू करें
• उपयोगकर्ता नज़ (लॉगिन के बाद, स्वचालित संकेत): उच्च-सफलता वाले तत्काल प्रमाणीकरण के लिए authenticatorAttachment: "platform" का उपयोग करें
• वेब खाता सेटिंग्स: सिक्योरिटी कीज़ की आवश्यकता वाले पावर उपयोगकर्ताओं के लिए authenticatorAttachment के बिना निर्माण की अनुमति दें
• विशिष्ट क्रेडेंशियल्स और अनुकूलित ट्रांसपोर्ट के साथ allowCredentials का उपयोग करें
• नेटिव ऐप्स: साइलेंट प्रमाणीकरण के लिए preferImmediatelyAvailableCredentials सक्षम करें
• iOS के खाली ऐरे को ["hybrid", "internal"] से भरें
• वेब प्रमाणीकरण: सिक्योरिटी कीज़ सहित सभी ट्रांसपोर्ट का समर्थन करें
• जहां उचित हो वहां QR कोड को रोकने के लिए मोबाइल डिवाइस पर hybrid को फ़िल्टर करें
• अनुकूलता बनाए रखते हुए सुव्यवस्थित प्रमाणीकरण विकल्पों के साथ बेहतर UX

पहले से ही आइडेंटिफ़ायर-फ़र्स्ट फ़्लो वाले प्लेटफ़ॉर्म के लिए:

• खाता प्रगणन पहले से ही कोई मुद्दा नहीं है
• उपभोक्ता-अनुरूप दृष्टिकोण स्वाभाविक रूप से मौजूदा UX के साथ संरेखित होता है
• ट्रांसपोर्ट ऑप्टिमाइज़ेशन तत्काल UX लाभ प्रदान करता है
• अधिकांश उपभोक्ता एप्लिकेशन के लिए अनुशंसित दृष्टिकोण

स्पेक-कंप्लायंट से शुरू करें, फिर अपनी रणनीति के आधार पर अनुकूलित करें:

1. पंजीकरण के दौरान प्राप्त होने वाले ट्रांसपोर्ट को ठीक वैसे ही सुरक्षित रखें
2. अपनी समग्र रणनीति तय करें (अधिकतम लचीलापन बनाम उपभोक्ता-अनुरूप)
3. यदि उपभोक्ता-अनुरूप है: आइडेंटिफ़ायर-फ़र्स्ट फ़्लो लागू करें और ट्रांसपोर्ट को अनुकूलित करें
4. अपनी चुनी हुई रणनीति के लिए उचित रूप से iOS के खाली ऐरे को संभालें
5. Web, iOS नेटिव और Android नेटिव प्लेटफ़ॉर्म पर पूरी तरह से परीक्षण करें

WebAuthn परिदृश्य विकसित होता जा रहा है। प्लेटफ़ॉर्म विक्रेता नियमित रूप से अपने कार्यान्वयन को अपडेट करते हैं, और WebAuthn Level 3 जैसे विनिर्देश नई क्षमताएं पेश करते हैं। लचीले सिस्टम का निर्माण जो ट्रांसपोर्ट हैंडलिंग को आपकी व्यापक प्रमाणीकरण रणनीति के साथ संरेखित करता है, यह सुनिश्चित करता है कि आपका पासकी कार्यान्वयन मज़बूत बना रहे और इकोसिस्टम परिपक्व होने पर उत्कृष्ट उपयोगकर्ता अनुभव प्रदान करे।

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 विशेषज्ञ से बात करें →

iOS AuthenticationServices iCloud Keychain जैसे प्लेटफ़ॉर्म ऑथेंटिकेटरों के लिए ट्रांसपोर्ट जानकारी को रोकता है, और WebAuthn स्पेक प्राइवेसी प्रावधानों के अनुसार खाली ऐरे लौटाता है। iOS पर सिक्योरिटी कीज़ ["usb"] या ["nfc"] जैसा ट्रांसपोर्ट डेटा प्रदान करती हैं। रिलाइंग पार्टीज़ को क्षमता की आधिकारिक गारंटी के बजाय सभी ट्रांसपोर्ट को संकेत के रूप में मानना चाहिए।

cable हाइब्रिड का पर्याय विरासत शब्दावली है, जो caBLE (क्लाउड-असिस्टेड ब्लूटूथ लो एनर्जी) के लिए है। दोनों क्रॉस-डिवाइस प्रमाणीकरण का वर्णन करते हैं जैसे कि फ़ोन का उपयोग करके डेस्कटॉप सत्र को प्रमाणित करने के लिए QR कोड को स्कैन करना। hybrid WebAuthn Level 3 में पेश किया गया वर्तमान शब्द है और नए कार्यान्वयनों में इसका उपयोग किया जाना चाहिए।

आइडेंटिफ़ायर-फ़र्स्ट फ़्लो का उपयोग करने वाले उपभोक्ता एप्लिकेशन के लिए, iOS प्लेटफ़ॉर्म ऑथेंटिकेटरों के लिए स्पष्ट रूप से ट्रांसपोर्ट को ["hybrid", "internal"] पर सेट करें, जो पंजीकरण के दौरान खाली ऐरे लौटाते हैं। यह USB और NFC सिक्योरिटी की संकेतों को प्रमाणीकरण UI में प्रदर्शित होने से रोकता है। स्पेक-कंप्लायंट विकल्प यह है कि ऐरे को खाली छोड़ दिया जाए या ट्रांसपोर्ट प्रॉपर्टी को पूरी तरह से हटा दिया जाए।

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

एक खाली allowCredentials ऐरे सिक्योरिटी कीज़ और क्रॉस-डिवाइस प्रमाणीकरण सहित सभी ऑथेंटिकेटर प्रकारों का समर्थन करता है, लेकिन ट्रांसपोर्ट प्रासंगिकता को कम करता है और उपयोगकर्ताओं को एक साथ कई विकल्प प्रस्तुत कर सकता है। इसे विशिष्ट उपयोगकर्ता क्रेडेंशियल के साथ पॉप्युलेट करने से UI को अनुकूलित करने के लिए ट्रांसपोर्ट हैंडलिंग महत्वपूर्ण हो जाती है, जिससे मोबाइल पर QR कोड को फ़िल्टर करने के लिए आइडेंटिफ़ायर-फ़र्स्ट फ़्लो सक्षम हो जाता है और उपभोक्ता संदर्भों में सिक्योरिटी की संकेतों को छिपाया जा सकता है।