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

Passkeys for Super Funds and Financial Institutions
Join our Webinar on 7th November to learn how Super Funds and Financial Institutions can implement passkeys

Join now

प्लेटफॉर्म ट्रांसपोर्ट हैंडलिंग: त्वरित संदर्भ#

प्लेटफॉर्म	प्लेटफॉर्म ऑथेंटिकेटर्स	सिक्योरिटी कीज़
वेब ब्राउज़र	Windows Hello: `["internal"]` Google Password Manager: `["internal", "hybrid"]` iCloud Keychain: `["internal", "hybrid"]`	`["usb", "nfc"]`
Android नेटिव	`["internal", "hybrid"]`	`["usb", "nfc"]`
iOS नेटिव	⚠️ खाली `[]` (iCloud Keychain)	`["usb", "nfc"]`

ध्यान दें: WebAuthn स्पेसिफिकेशन के अनुसार, खाली ट्रांसपोर्ट का मतलब है कि सभी ट्रांसपोर्ट समर्थित हैं।

1. परिचय: क्रॉस-डिवाइस ऑथेंटिकेशन के लिए WebAuthn ट्रांसपोर्ट्स#

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

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

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

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

2. WebAuthn ट्रांसपोर्ट्स को समझना: इंटरनल, हाइब्रिड, और प्लेटफॉर्म ऑथेंटिकेटर्स#

2.1 WebAuthn ट्रांसपोर्ट प्रकार: इंटरनल, हाइब्रिड, USB, NFC, BLE, और स्मार्ट-कार्ड#

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

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

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

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

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

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

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

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

2.2 प्लेटफॉर्म-विशिष्ट व्यवहार#

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

2.2.1 वेब ब्राउज़र#

ब्राउज़र ऑथेंटिकेटर्स से ट्रांसपोर्ट जानकारी प्राप्त करते हैं और ऑथेंटिकेशन प्रवाह के दौरान इसका सम्मान करते हैं। जब आप 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 स्पेसिफिकेशन

2.2.2 Android नेटिव एप्लिकेशन#

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

डॉक्यूमेंटेशन: Android क्रेडेंशियल मैनेजर

2.2.3 iOS नेटिव एप्लिकेशन#

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

प्लेटफॉर्म ऑथेंटिकेटर्स (iCloud Keychain, Face ID या Touch ID के माध्यम से सत्यापित): अक्सर पासकी बनाने के दौरान खाली ट्रांसपोर्ट एरे लौटाते हैं। इसका मतलब यह नहीं है कि पासकी में ट्रांसपोर्ट क्षमताओं की कमी है—इसका सीधा सा मतलब है कि iOS उन्हें स्पष्ट रूप से रिपोर्ट नहीं करता है। WebAuthn मानक के अनुसार, ट्रांसपोर्ट को छोड़ देने का मतलब है कि कोई भी ट्रांसपोर्ट स्वीकार्य है, इसलिए हाइब्रिड ऑथेंटिकेशन फिर भी काम करेगा।

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

डॉक्यूमेंटेशन: Apple AuthenticationServices

3. WebAuthn ट्रांसपोर्ट हैंडलिंग के दो दृष्टिकोण#

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

3.1 स्पेक-कंप्लायंट दृष्टिकोण: इंटरनल और हाइब्रिड ट्रांसपोर्ट पर भरोसा करना#

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

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

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

फायदे:

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

नुकसान:

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

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

3.2 ट्रांसपोर्ट ऑप्टिमाइज़ेशन दृष्टिकोण: क्रॉस-डिवाइस ऑथ के लिए इंटरनल और हाइब्रिड को नियंत्रित करना#

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

3.2.1 यूज़ केस 1: iOS कीज़ से सिक्योरिटी की विकल्प हटाएँ#

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

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

// iOS प्लेटफॉर्म ऑथेंटिकेटर क्रेडेंशियल को बनाए रखते समय
if (platform === "iOS" && authenticatorAttachment === "platform") {
    transports = ["hybrid", "internal"];
}

परिणाम: iOS द्वारा बनाई गई पासकी के लिए सिक्योरिटी की प्रॉम्प्ट के बिना स्वच्छ ऑथेंटिकेशन UI।

3.2.2 यूज़ केस 2: मोबाइल डिवाइस पर QR कोड रोकें#

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

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

// ऑथेंटिकेशन के लिए allowCredentials बनाते समय
const transports = isMobileDevice
    ? credentials.transports.filter((t) => t !== "hybrid")
    : credentials.transports;

परिणाम: मोबाइल यूज़र्स को अनावश्यक QR कोड प्रॉम्प्ट के बिना केवल सीधे ऑथेंटिकेशन विकल्प दिखाई देते हैं।

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

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

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

3.2.3 महत्वपूर्ण विचार#

ये ऑप्टिमाइज़ेशन के संकेत हैं: WebAuthn ट्रांसपोर्ट हेरफेर से परे ऑथेंटिकेशन UX को ऑप्टिमाइज़ करने के लिए अन्य तंत्र प्रदान करता है—जैसे कि संकेत।

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

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

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

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

फायदे:

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

नुकसान:

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

किसके लिए सबसे अच्छा है: विशिष्ट UX आवश्यकताओं वाले उपभोक्ता एप्लिकेशन, प्लेटफॉर्म-विशिष्ट तर्क को बनाए रखने के लिए संसाधनों वाली टीमें, सख्त स्पेक अनुपालन पर सुव्यवस्थित ऑथेंटिकेशन प्रवाह को प्राथमिकता देने वाले परिदृश्य।

3.3 WebAuthn ट्रांसपोर्ट रणनीति: प्लेटफॉर्म ऑथेंटिकेटर्स और क्रॉस-डिवाइस ऑथेंटिकेशन#

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

3.3.1 रणनीति 1: अधिकतम मानक अनुरूपता और यूज़र की स्वतंत्रता#

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

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

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

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

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

किसके लिए सबसे अच्छा है: एंटरप्राइज़ वातावरण, सिक्योरिटी की समर्थन की आवश्यकता वाले विविध यूज़र आधार वाले एप्लिकेशन, अधिकतम ऑथेंटिकेशन लचीलेपन को प्राथमिकता देने वाले परिदृश्य।

3.3.2 रणनीति 2: उपभोक्ता-अनुरूप प्लेटफॉर्म ऑथेंटिकेटर्स#

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

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

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

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

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

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

3.3.3 तुलना मैट्रिक्स#

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

3.3.4 आइडेंटिफायर-फर्स्ट प्रवाह और अकाउंट एन्यूमरेशन#

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

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

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

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

4. WebAuthn ट्रांसपोर्ट कार्यान्वयन के सर्वोत्तम अभ्यास#

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

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

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

स्पेक-कंप्लायंट: ट्रांसपोर्ट प्रॉपर्टी को खाली छोड़ दें या हटा दें—इसका मतलब है कि "कोई भी ट्रांसपोर्ट" स्वीकार्य है
ऑप्टिमाइज़ेशन दृष्टिकोण: दिखाए जाने वाले ऑथेंटिकेशन विकल्पों को नियंत्रित करने के लिए ["internal", "hybrid"] से भरें

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

रजिस्ट्रेशन: वेब, iOS नेटिव, Android नेटिव
ऑथेंटिकेशन: वेब, iOS नेटिव, Android नेटिव
सत्यापित करें कि QR कोड अपेक्षित होने पर दिखाई देते हैं और अनुचित होने पर छिपे होते हैं

खाली एरे बनाम गुम प्रॉपर्टी को समझें: एक खाली ट्रांसपोर्ट एरे [] और एक गुम ट्रांसपोर्ट प्रॉपर्टी दोनों को आमतौर पर स्पेसिफिकेशन के अनुसार "कोई भी ट्रांसपोर्ट स्वीकार्य है" माना जाता है। हालांकि, कार्यान्वयन विवरण प्लेटफॉर्मों में भिन्न होते हैं।

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

5. निष्कर्ष: अपनी WebAuthn ट्रांसपोर्ट रणनीति चुनना#

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

5.1 मुख्य बातें#

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

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

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

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

5.2 अपनी रणनीति चुनना#

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

सभी ऑथेंटिकेटर प्रकारों का समर्थन करने के लिए खाली allowCredentials का उपयोग करें
ऑथेंटिकेटर-प्रदत्त ट्रांसपोर्ट पर भरोसा करें
स्वीकार करें कि यूज़र्स को अधिक ऑथेंटिकेशन विकल्प दिखाई देंगे
सरल कार्यान्वयन, व्यापक संगतता

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

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

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

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

5.3 कार्यान्वयन सिफारिश#

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

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

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