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

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

Cheat sheet पाएं

WebAuthn पासकीज़ (passkeys) के पीछे का आधुनिक स्टैंडर्ड है। पारंपरिक पासवर्ड्स पर निर्भर रहने के बजाय, यह पब्लिक-की क्रिप्टोग्राफी का उपयोग करता है। इससे यूज़र्स पासकीज़ के ज़रिए ऑथेंटिकेट कर सकते हैं, जिसमें बायोमेट्रिक्स (जैसे फिंगरप्रिंट या फेशियल रिकग्निशन) या फिजिकल सिक्योरिटी कीज़ (security keys) शामिल हो सकते हैं। यह बदलाव न केवल सुरक्षा बढ़ाता है, बल्कि पासवर्ड याद रखने की झंझट को खत्म करके यूज़र अनुभव (UX) को भी बेहतर बनाता है।

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

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

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

इस पोस्ट के अंत तक, आप समझ जाएंगे कि ये फीचर्स आपको आधुनिक यूज़र उम्मीदों के अनुरूप सहज और सुरक्षित ऑथेंटिकेशन फ्लो बनाने में कैसे मदद कर सकते हैं।

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

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

WebAuthn Level 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 फीचर्स को सपोर्ट करता है। क्लाइंट की क्षमताओं को समझकर, डेवलपर्स ऑथेंटिकेशन फ्लो को अनुकूलित कर सकते हैं ताकि उपलब्ध फीचर्स, जैसे biometric authentication का लाभ उठाया जा सके, और कुछ क्षमताएं अनुपस्थित होने पर वैकल्पिक तरीके प्रदान किए जा सकें।

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

Subscribe करें

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

conditionalCreate विशिष्ट शर्तों के आधार पर automatic passkey creation को सक्षम बनाता है। एक एप्लिकेशन इस क्षमता का उपयोग password autofill के दौरान स्वचालित रूप से पासकी बनाने के लिए कर सकता है यदि password manager के पास संबंधित सपोर्ट है। यह फीचर यूज़र्स को पासवर्ड से पासकीज़ में स्वचालित रूप से बदलकर passkey adoption और इसके बाद के उपयोग को बढ़ाने में मदद करता है।

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ऑथेंटिकेटर फिर स्थानीय रूप से सेव की गई पासकी के मेटाडेटा को अपडेट करेगा। बड़ा फायदा यह है कि भविष्य के Conditional UI / passkey autofill रिक्वेस्ट में, Conditional UI सिलेक्शन / ड्रॉपडाउन मेनू अपडेटेड नाम और WebAuthn Display Name दिखाता है।

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

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

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

ऑथेंटिकेटर फिर भविष्य के ऑथेंटिकेशन समारोहों से क्रेडेंशियल ID X वाली पासकी को हटा देगा या छिपा देगा।

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

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

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

Adoption data देखें

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

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

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

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

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

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

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

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