WebAuthn क्लाइंट क्षमताएं

WebAuthn पासकीज़ के पीछे का आधुनिक मानक है। पारंपरिक पासवर्ड पर निर्भर रहने के बजाय, यह पब्लिक-की क्रिप्टोग्राफी का लाभ उठाता है, जिससे यूज़र्स पासकीज़ के साथ प्रमाणित कर सकते हैं, जिसमें बायोमेट्रिक्स (जैसे फिंगरप्रिंट या चेहरे की पहचान) या भौतिक सुरक्षा कुंजियाँ शामिल हो सकती हैं। यह बदलाव न केवल सुरक्षा को बढ़ाता है बल्कि पासवर्ड मैनेजमेंट की आवश्यकता को समाप्त करके यूज़र अनुभव को भी बेहतर बनाता है।

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

इस ब्लॉग पोस्ट में, हम निम्नलिखित सवालों के जवाब देंगे:

1. WebAuthn क्लाइंट क्षमताएं क्या हैं?
2. कौन-सी WebAuthn क्लाइंट क्षमताएं मौजूद हैं?
3. WebAuthn क्लाइंट क्षमताएं पासकी कार्यान्वयन को कैसे बेहतर बनाती हैं?
4. WebAuthn क्लाइंट क्षमताएं डेवलपर्स और प्रोडक्ट मैनेजर्स दोनों के लिए क्यों महत्वपूर्ण हैं?

अंत तक, आप समझ जाएंगे कि ये सुविधाएँ आपको सहज, सुरक्षित प्रमाणीकरण प्रवाह बनाने में कैसे मदद कर सकती हैं जो आधुनिक यूज़र अपेक्षाओं के अनुरूप हों।

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

उदाहरण के लिए, यदि कोई ब्राउज़र यह संकेत देता है कि वह बायोमेट्रिक प्रमाणीकरण (जैसे Touch ID) का समर्थन करता है, तो डेवलपर्स अपने लॉगिन प्रवाह को इस तरह से डिज़ाइन कर सकते हैं कि यूज़र्स को फिंगरप्रिंट से लॉगिन करने का विकल्प मिले। इसके विपरीत, यदि ब्राउज़र कुछ सुविधाओं का समर्थन नहीं करता है, तो डेवलपर्स पासवर्ड या SMS OTP जैसे फ़ॉलबैक विकल्प प्रदान कर सकते हैं।

WebAuthn लेवल 3 मानक कई नई क्लाइंट क्षमताएं पेश करता है जो पासकी कार्यान्वयन को अधिक बहुमुखी और यूज़र-फ्रेंडली बनाती हैं। getClientCapabilities() API कॉल के लिए पहला समर्थन Safari 17.4 में पेश किया गया था।

ब्राउज़र में समर्थन का पता लगाने के लिए, निम्नलिखित स्निपेट उपयोगी हो सकता है:

// Check if PublicKeyCredential is supported in the current browser
if (typeof PublicKeyCredential === "undefined") {
    console.log("PublicKeyCredential is not supported in this browser.");
}
 
// Check if getClientCapabilities method exists on PublicKeyCredential
if (typeof PublicKeyCredential.getClientCapabilities === "function") {
    try {
        let capabilities = await PublicKeyCredential.getClientCapabilities();
        console.log(capabilities);
    } catch (error) {
        console.error("Error getting client capabilities:", error);
    }
} else {
    console.log("getClientCapabilities is not supported in this browser");
}

getClientCapabilities() वेबसाइटों और ऐप्स को क्लाइंट (जैसे, ब्राउज़र या डिवाइस) से यह पता लगाने की अनुमति देता है कि वह कौन-सी WebAuthn सुविधाओं का समर्थन करता है। क्लाइंट की क्षमताओं को समझकर, डेवलपर्स उपलब्ध सुविधाओं, जैसे बायोमेट्रिक प्रमाणीकरण, का लाभ उठाने के लिए प्रमाणीकरण प्रवाह को अनुकूलित कर सकते हैं, और यदि कुछ क्षमताएं अनुपस्थित हैं तो वैकल्पिक तरीके प्रदान कर सकते हैं।

Subscribe to our Passkeys Substack for the latest news.

Subscribe

यहाँ WebAuthn क्लाइंट क्षमताओं पर एक करीब से नज़र डाली गई है और वे पासकी इंटीग्रेशन को कैसे प्रभावित करती हैं:

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

conditionalCreate के समान, conditionalGet पासकी लॉगिन को स्वचालित रूप से ट्रिगर करता है। यह उन परिदृश्यों में उपयोगी है जहाँ सर्वश्रेष्ठ पासकी UX को सक्षम किया जाना चाहिए, जिससे लॉगिन न केवल पासवर्ड रहित बल्कि यूज़रनेम रहित भी हो जाता है (यूज़र्स बस एक मोडल/ड्रॉपडाउन में चयनित पासकी पर क्लिक करते हैं और प्रमाणित कर सकते हैं)। इस क्षमता का उपयोग करके, डेवलपर्स यह सुनिश्चित कर सकते हैं कि पासकी प्रमाणीकरण केवल तभी होता है जब उपयुक्त हो, जिससे अनावश्यक संकेतों को कम किया जा सके और यूज़र अनुभव को बढ़ाया जा सके।

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

प्लेटफ़ॉर्म ऑथेंटिकेटर, जैसे Windows Hello, Face ID या Touch ID, सीधे डिवाइस में बनाए जाते हैं और यूज़र्स को बायोमेट्रिक्स या अन्य डिवाइस-नेटिव विधि (जैसे पिन पैटर्न) से प्रमाणित करने में सक्षम बनाकर एक तेज़, सहज और अधिक सुरक्षित पासकी अनुभव प्रदान करते हैं।

Become part of our Passkeys Community for updates & support.

Join

userVerifyingPlatformAuthenticator यह सुनिश्चित करता है कि पासकी प्रमाणीकरण में यूज़र वेरिफिकेशन शामिल हो, जैसे कि एक सक्रिय फिंगरप्रिंट स्कैन या चेहरे की पहचान, जो सुरक्षा की एक अतिरिक्त परत प्रदान करता है।

relatedOrigins क्षमता एक ही संगठन के स्वामित्व वाले विभिन्न डोमेन (जैसे amazon.com और amazon.de) पर सहज प्रमाणीकरण की अनुमति देती है। उदाहरण के लिए, यदि कोई कंपनी कई डोमेन का प्रबंधन करती है या उसके अलग-अलग सबडोमेन हैं, तो यूज़र्स एक बार लॉग इन कर सकते हैं और प्रत्येक पर फिर से प्रमाणित किए बिना सभी संपत्तियों तक पहुंच सकते हैं। यह क्षमता यूज़र अनुभव को सुव्यवस्थित करती है, घर्षण को कम करती है, और विशेष रूप से अंतरराष्ट्रीय वातावरण में या बहु-सेवा प्लेटफ़ॉर्म वाले उद्यमों के लिए मूल्यवान है।

signalAllAcceptedCredentials(options) विधि किसी दिए गए यूज़र के लिए WebAuthn क्रेडेंशियल आईडी की पूरी सूची प्रदान करती है। WebAuthn Relying Parties को इस विधि का उपयोग signalUnknownCredential() के बजाय तब करना चाहिए जब यूज़र प्रमाणित हो, क्योंकि इसमें गोपनीयता लीक का कोई जोखिम नहीं होता है। यह विधि यूज़र के पब्लिक की क्रेडेंशियल्स का एक व्यापक अवलोकन प्रदान करती है, जिसमें कोई भी हालिया परिवर्तन शामिल है जो वर्तमान में जुड़े ऑथेंटिकेटर पर अपडेट नहीं किया गया हो सकता है।

आइए एक उदाहरण देखें। एक यूज़र (userId: A) के पास 2 पासकीज़ हैं जिनके क्रेडेंशियल आईडी Base64URL में X और Y के रूप में एन्कोड होते हैं। फिर, यूज़र वेब सेवा (example.com) की खाता सेटिंग्स में पासकी X को हटा देता है (इसलिए पब्लिक की हटा दी जाती है)। अब, निम्नलिखित स्निपेट चलाएँ:

PublicKeyCredential.signalAllAcceptedCredentials({
    rpId: "example.com",
    userId: "A", // WebAuthn User Handle, Base64URL.
    allAcceptedCredentialIds: ["Y"],
});

यदि उपरोक्त कोड के निष्पादन के समय ऑथेंटिकेटर उपलब्ध है, तो ऑथेंटिकेटर भविष्य के प्रमाणीकरण समारोहों से पासकी X को हटा देता है या छिपा देता है। हालाँकि, निष्पादन के समय ऑथेंटिकेटर संलग्न नहीं हो सकता है, इसलिए यह अनुशंसा की जाती है कि Relying Parties को समय-समय पर इस कोड को निष्पादित करना चाहिए, जैसे कि हर साइन-इन पर।

allAcceptedCredentialIds में मौजूद नहीं पासकीज़ को हटा दिया जाएगा या छिपा दिया जाएगा, जो संभावित रूप से अपरिवर्तनीय हो सकता है। इसलिए, Relying Parties के लिए यह ध्यान रखना महत्वपूर्ण है कि मान्य WebAuthn क्रेडेंशियल आईडी को कभी भी सूची से न हटाया जाए। यदि कोई मान्य क्रेडेंशियल आईडी गलती से हटा दिया गया था, तो Relying Party को पासकी को "अनहाइड" करने के लिए जितनी जल्दी हो सके इसे दूसरे signalAllAcceptedCredentials(options) कॉल में तुरंत शामिल करना चाहिए। यदि पासकी छिपी नहीं है बल्कि हटा दी गई है, तो चीजों को ठीक करने के लिए बहुत कुछ नहीं है।

Want to experiment with passkey flows? Try our Passkeys Debugger.

Try for Free

signalCurrentUserDetails(options) विधि यूज़र के वर्तमान नाम और WebAuthn डिस्प्ले नाम का संकेत देती है। जब signalCurrentUserDetails(options) को कॉल किया जाता है, तो क्लाइंट इस क्रिया को निष्पादित करने के लिए परिभाषित चरणों के एक सेट का पालन करता है।

आइए एक उदाहरण देखें। WebAuthn यूज़र आईडी A वाला एक यूज़र एक वेबसाइट (example.com) की खाता सेटिंग्स में अपना नाम अपडेट करता है। फिर, Relying Party निम्नलिखित कोड चला सकता है:

PublicKeyCredential.signalCurrentUserDetails({
    rpId: "example.com",
    userId: "A", // user ID, Base64URL.
    name: "New user name",
    displayName: "New display name",
});

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

signalUnknownCredential(options) विधि यह संकेत देती है कि एक WebAuthn क्रेडेंशियल आईडी को WebAuthn Relying Party द्वारा पहचाना नहीं गया है, उदाहरण के लिए, यदि पासकी यूज़र द्वारा हटा दी गई थी। signalAllAcceptedCredentials(options) के विपरीत, इस विधि को स्वीकृत क्रेडेंशियल आईडी की पूरी सूची और WebAuthn यूज़र हैंडल प्रदान करने की आवश्यकता नहीं होती है, जिससे अप्रमाणित कॉल करने वालों को संभावित गोपनीयता लीक को रोका जा सकता है।

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

PublicKeyCredential.signalUnknownCredential({
    rpId: "example.com",
    credentialId: "X", // credential ID the user just tried, Base64URL
});

ऑथेंटिकेटर तब भविष्य के प्रमाणीकरण समारोहों से क्रेडेंशियल आईडी X वाली पासकी को हटा देगा या छिपा देगा।

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

अपनाने की गति संभवतः तेज हो जाएगी जैसे-जैसे लेवल 3 परिपक्व होगा और अधिक ब्राउज़र इन सुविधाओं को शिप करेंगे। यदि आप देखना चाहते हैं कि कितने यूज़र्स अभी getClientCapabilities() का लाभ उठा सकते हैं, तो आप मुफ्त Passkeys Analyzer का उपयोग करके वास्तविक दुनिया के डेटा की जांच कर सकते हैं। ब्राउज़र रिलीज़ नोट्स और संबंधित दस्तावेज़ों पर नज़र रखें ताकि व्यापक संगतता के विकसित होने पर योजना बना सकें।

Are your users passkey-ready?

Test Passkey-Readiness

एक डेवलपर के रूप में, आप खुद से पूछ सकते हैं कि इन नई WebAuthn क्लाइंट क्षमता का पता लगाने का आपके लिए क्या मतलब है और आपको उन्हें अपने ऐप में कैसे उपयोग करना चाहिए। निम्नलिखित में, आप उन्हें उपयोग करने के लिए सिफारिशें पाएंगे।

हालांकि, ध्यान रखें कि अभी तक सभी ब्राउज़र getClientCapabilities() API कॉल का समर्थन नहीं करते हैं (नवंबर 2024 तक)। यहाँ एक पॉलीफ़िल उपलब्ध है, जिसका उपयोग तब तक किया जा सकता है जब तक सभी ब्राउज़र पकड़ में नहीं आ जाते।

पेज लोड / प्रमाणीकरण प्रवाह की शुरुआत में क्लाइंट की समर्थित सुविधाओं का पता लगाने के लिए अपने कोड में जल्दी getClientCapabilities() का उपयोग करें। यह आपको अनुभव को गतिशील रूप से अनुकूलित करने की अनुमति देगा, और डिवाइस / ब्राउज़र पर काम करने वाली पासकी सुविधाएँ प्रदान करेगा, जैसे कि समर्थित होने पर प्लेटफ़ॉर्म प्रमाणीकरण के लिए जोर देना या यदि नहीं तो वैकल्पिक तरीके (जैसे, SMS OTPs या हार्डवेयर सुरक्षा कुंजियाँ) प्रदान करना।

यदि आप वर्तमान में पासवर्ड का उपयोग करने वाली वेबसाइट / ऐप में पासकीज़ जोड़ते हैं, तो conditionalCreate सुविधा आपके पासकी एडॉप्शन के लिए एक वास्तविक बूस्टर हो सकती है। पृष्ठभूमि में, एक उपयुक्त क्रेडेंशियल मैनेजर (अक्टूबर 2024 तक केवल Apple Passwords) के साथ पासवर्ड ऑटोफिल के दौरान, एक पासकी स्वचालित रूप से उत्पन्न होती है और भविष्य के ऑटोफिल में इसे प्राथमिकता दी जाएगी।

न केवल एक उच्च पासकी एडॉप्शन हो, बल्कि एक उच्च पासकी लॉगिन उपयोग भी हो, यह जांचने का प्रयास करें कि क्या डिवाइस / ब्राउज़र conditionalGet की जांच करके कंडीशनल UI / पासकी ऑटोफिल का उपयोग कर सकता है। इस तरह आप यूज़र्स को बनाई गई पासकी का उपयोग लॉगिन के लिए करने के लिए प्रेरित करेंगे, क्योंकि यह ऑपरेटिंग सिस्टम / ब्राउज़र द्वारा सक्रिय रूप से सुझाया जाता है और पासवर्ड को ऑटोफिल करने की तुलना में और भी कम प्रयास की आवश्यकता होती है।

क्रॉस-डिवाइस प्रमाणीकरण (QR कोड और ब्लूटूथ के माध्यम से) को सक्षम करने के लिए hybridTransport का उपयोग करें, जिससे यूज़र्स अपने स्मार्टफ़ोन से सहजता से लॉग इन कर सकें, भले ही वे आपकी सेवा को डेस्कटॉप पर एक्सेस कर रहे हों।

WebAuthn क्लाइंट क्षमताएं वर्तमान में मौजूद पासकी अंतरालों को दूर करने में एक महत्वपूर्ण कदम का प्रतिनिधित्व करती हैं। इस ब्लॉग पोस्ट में, हमने WebAuthn क्लाइंट क्षमताओं के बारे में प्रमुख सवालों को संबोधित किया:

1. WebAuthn क्लाइंट क्षमताएं क्या हैं? हमने बताया कि कैसे ये सुविधाएँ ब्राउज़रों और प्लेटफ़ॉर्म को विशिष्ट कार्यात्मकताओं के लिए अपने समर्थन का संकेत देने की अनुमति देती हैं, जिससे डेवलपर्स को प्रमाणीकरण प्रवाह पर अधिक नियंत्रण मिलता है।
2. कौन-सी WebAuthn क्लाइंट क्षमताएं मौजूद हैं? हमने लेवल 3 मानक में पेश की गई नई क्षमताओं का एक अवलोकन प्रदान किया, जिसमें getClientCapabilities, conditionalCreate, hybridTransport, और बहुत कुछ शामिल हैं।
3. WebAuthn क्लाइंट क्षमताएं पासकी कार्यान्वयन को कैसे बेहतर बनाती हैं? हमने चर्चा की कि कैसे ये क्षमताएं एकीकरण को सुव्यवस्थित करती हैं, क्रॉस-डिवाइस उपयोग को बढ़ाती हैं, और सुरक्षा में सुधार करती हैं।
4. WebAuthn क्लाइंट क्षमताएं डेवलपर्स के लिए क्यों महत्वपूर्ण हैं? ये सुविधाएँ सहज, सुरक्षित प्रमाणीकरण अनुभव बनाने में मदद करती हैं जो आधुनिक यूज़र अपेक्षाओं के अनुरूप हैं, जिससे कार्यान्वयन आसान और अधिक प्रभावी हो जाता है।

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