WebAuthn Conditional UI (पासकी ऑटोफिल) की तकनीकी व्याख्या

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

Cheat sheet पाएं

पासकी (और अंतर्निहित WebAuthn प्रोटोकॉल) को तेज़ी से अपनाए जाने के साथ, प्रमाणीकरण (authentication) कई उपयोगकर्ताओं के लिए अधिक सुरक्षित और उपयोगकर्ता के अनुकूल बन गया है। पासकीज़ की सबसे उत्कृष्ट प्रगतियों में से एक Conditional UI का एकीकरण रहा है, जिसे अक्सर "पासकी ऑटोफिल" या Conditional Mediation कहा जाता है (आगे हम Conditional UI शब्द के साथ ही रहेंगे)।

इसकी हालिया शुरुआत और ब्राउज़रों द्वारा इसे लगातार अपनाए जाने के बावजूद, Conditional UI के लिए तकनीकी दस्तावेज़ीकरण और कार्यान्वयन सलाह में एक ध्यान देने योग्य अंतर है। इस लेख का उद्देश्य यह समझाकर उस अंतर को पाटना है कि Conditional UI क्या है, यह कैसे काम करता है और इसके कार्यान्वयन के दौरान आने वाली सामान्य चुनौतियों से कैसे निपटा जाए।

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

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

Conditional UI की नींव तीन मुख्य स्तंभों पर बनी है:

1. उपयोगकर्ता की गोपनीयता का सम्मान: उपलब्ध क्रेडेंशियल्स के प्रकटीकरण या इन क्रेडेंशियल्स को प्रकट करने के लिए उपयोगकर्ता की सहमति की कमी को रोककर उपयोगकर्ता की गोपनीयता सुनिश्चित करना।
2. कोई पासकी मौजूद न होने पर भी बेहतरीन उपयोगकर्ता अनुभव: रिलाइंग पार्टियों को अवसरवादी तरीके से WebAuthn लागू करने के लिए सशक्त बनाना, यह सुनिश्चित करना कि पासकी उपलब्ध न होने पर भी उपयोगकर्ता अनुभव अच्छा बना रहे।
3. पासवर्ड से पासकी में सुचारू रूप से बदलाव: पासवर्ड-आधारित प्रमाणीकरण के साथ पासकीज़ का संयोजन करके पासवर्डलेस प्रमाणीकरण विधियों की दिशा में बदलाव को सुचारू बनाना, और उपयोगकर्ताओं के परिचित UX प्रतिमानों (paradigms) का लाभ उठाना।

• सुव्यवस्थित प्रमाणीकरण: यह प्रक्रिया अधिक सुव्यवस्थित और कुशल है, जो अक्सर कई प्रमाणीकरण विधियों से जुड़ी जटिलताओं को दूर करती है।
• उपयोगकर्ता त्रुटियों में कमी: केवल प्रासंगिक विकल्प प्रस्तुत करके, उपयोगकर्ताओं द्वारा प्रमाणीकरण प्रक्रिया के दौरान गलतियाँ करने की संभावना कम हो जाती है।
• बढ़ी हुई उपयोगकर्ता संतुष्टि: अनावश्यक कदमों को हटाने का अर्थ है कि उपयोगकर्ता तेज़ी से और आसानी से लॉग इन कर सकते हैं, जिससे उपयोगकर्ता संतुष्टि में सुधार होता है।
• सरल फ़्रंटएंड एकीकरण: Conditional UI की एक असाधारण विशेषता इसके एकीकरण में आसानी है। डेवलपर्स कोड की कुछ पंक्तियों के साथ इसे फ़्रंटएंड में सहजता से शामिल कर सकते हैं (नीचे देखें)।
• पासवर्डलेस और यज़रनेम-रहित लॉगिन: इसके बहुत बड़े लाभों में से एक यह है कि Conditional UI न केवल पासवर्डलेस प्रमाणीकरण को बढ़ावा देता है बल्कि एक यूज़रनेम-रहित या खाता-रहित (accountless) अनुभव भी प्रदान करता है। उपयोगकर्ताओं को साइन-अप से अपना विशिष्ट ईमेल पता या उपयोगकर्ता हैंडल याद रखने के मानसिक भार से बचाया जाता है। इसके बजाय, वे ब्राउज़र के सुझावों पर भरोसा कर सकते हैं, जिसमें ऑटोफिल मेनू में उपयुक्त पासकी के साथ जोड़ा गया ईमेल पता / यूज़र हैंडल शामिल है।
• बूटस्ट्रैपिंग दुविधा का समाधान: पारंपरिक यूज़रनेम-पासवर्ड सिस्टम से पासकीज़ में परिवर्तन कठिन हो सकता है। Conditional UI इस परिवर्तन की चुनौती को हल करता है। यदि किसी डिवाइस में आवश्यक क्रेडेंशियल्स का अभाव है, तो वेबसाइटें संभावित मोडल संवाद त्रुटियों की चिंता किए बिना पारंपरिक पासवर्ड प्रॉम्प्ट के साथ पासकी / WebAuthn कॉल शुरू कर सकती हैं।

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

Subscribe करें

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

नीचे, हम एक संपूर्ण Conditional UI प्रवाह के एकल चरणों का चरण-दर-चरण विश्लेषण प्रदान करते हैं:

सामान्य तौर पर, Conditional UI प्रक्रिया प्रवाह को दो चरणों में विभाजित किया जा सकता है। पेज लोड चरण के दौरान, Conditional UI लॉजिक पृष्ठभूमि में काम करता है, जबकि उपयोगकर्ता संचालन चरण में, उपयोगकर्ता को सक्रिय रूप से कुछ करना होता है।

1. Conditional UI उपलब्धता की जाँच: क्लाइंट (ब्राउज़र) यह पता लगाने के लिए isConditionalMediationAvailable() फ़ंक्शन को कॉल करता है कि क्या वर्तमान ब्राउज़र / डिवाइस संयोजन Conditional UI का समर्थन करता है। यदि प्रतिक्रिया सही (true) है तभी प्रक्रिया जारी रहती है, अन्यथा Conditional UI प्रक्रिया निरस्त हो जाती है।
2. Conditional UI एंडपॉइंट को कॉल करें: अगला, क्लाइंट PublicKeyCredentialRequestOptions को पुनः प्राप्त करने के लिए सर्वर के Conditional UI एंडपॉइंट को कॉल करता है।
3. PublicKeyCredentialRequestOptions प्राप्त करें: सर्वर PublicKeyCredentialRequestOptions लौटाता है जिसमें चुनौती (challenge) और अधिक WebAuthn सर्वर विकल्प (जैसे allowCredentials, extensions, userVerification) शामिल हैं।
4. स्थानीय प्रमाणीकरण प्रारंभ करें: प्राप्त PublicKeyCredentialRequestOptions और conditional के रूप में सेट किए गए mediation प्रॉपर्टी के साथ credentials.get() को कॉल करके, डिवाइस पर स्थानीय प्रमाणीकरण की प्रक्रिया शुरू हो जाती है।
5. ऑटोफिल चयन दिखाएं: पासकीज़ के लिए ऑटोफिल मेनू पॉप अप होता है। विशिष्ट स्टाइलिंग ब्राउज़र और डिवाइस पर निर्भर करती है (उदा., कुछ के लिए उपयोगकर्ता को इनपुट फ़ील्ड में कर्सर रखने की आवश्यकता होती है, कुछ पेज लोड होने पर स्वचालित रूप से मेनू प्रदर्शित करते हैं, नीचे देखें)।
6. स्थानीय उपयोगकर्ता प्रमाणीकरण: उपयोगकर्ता ऑटोफिल मेनू से उस पासकी का चयन करता है जिसका वह उपयोग करना चाहता है और अपने डिवाइस के प्रमाणीकरण संवाद (जैसे Face ID, Touch ID, Windows Hello) के माध्यम से प्रमाणित करता है।
7. सर्वर को ऑथेंटिकेटर प्रतिक्रिया भेजें: यदि स्थानीय उपयोगकर्ता प्रमाणीकरण सफल रहा, तो ऑथेंटिकेटर प्रतिक्रिया वापस सर्वर पर भेज दी जाती है।
8. उपयोगकर्ता लॉग इन होता है और रीडायरेक्ट किया जाता है: एक बार सर्वर ऑथेंटिकेटर प्रतिक्रिया प्राप्त कर लेता है, तो यह डेटाबेस में संबंधित उपयोगकर्ता खाते की सार्वजनिक कुंजी के विरुद्ध हस्ताक्षर (signature) को मान्य करता है। यदि सत्यापन सफल होता है, तो उपयोगकर्ता को पहुंच प्रदान की जाती है, लॉग इन किया जाता है और लॉग-इन पेज पर रीडायरेक्ट किया जाता है।

इस प्रक्रिया प्रवाह का पालन करके, Conditional UI एक निर्बाध और उपयोगकर्ता के अनुकूल प्रमाणीकरण अनुभव प्रदान करता है।

Conditional UI को काम करने के लिए, कुछ सामान्य पहलुओं पर विचार करने की आवश्यकता है:

• क्रेडेंशियल विनिर्देश: Conditional UI विशेष रूप से केवल रेज़िडेंट कीज़ / डिस्कवरेबल क्रेडेंशियल्स के साथ काम करने के लिए डिज़ाइन किया गया है। इसके पीछे कारण यह है कि ऑथेंटिकेटर नॉन-रेज़िडेंट कीज़ / नॉन-डिस्कवरेबल क्रेडेंशियल्स के लिए उपयोगकर्ता-विशिष्ट डेटा (जैसे, नाम, डिस्प्ले नाम) संग्रहीत नहीं करते हैं। परिणामस्वरूप, पासकी ऑटोफिल के लिए बाद वाले का उपयोग करना संभव नहीं है।
• क्रेडेंशियल फ़िल्टरिंग: allowCredentials सुविधा समर्थित रहती है, जो उन वेबसाइटों को सुविधा प्रदान करती है जो उपयोगकर्ता की पहचान से पहले से अवगत हैं (उदाहरण के लिए, यदि प्रारंभिक mediation कॉल में कोई यूज़रनेम भेजा गया था क्योंकि यह ब्राउज़र के LocalStorage में संग्रहीत किया जा सकता है) ताकि ऑटोफिल के दौरान उपयोगकर्ताओं को दिखाए गए क्रेडेंशियल्स की सूची को परिष्कृत किया जा सके।

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

जुड़ें

क्लाइंट-साइड पर Conditional UI को कार्यशील करने के लिए, निम्नलिखित आवश्यकताओं को पूरा किया जाना चाहिए:

• संगत ब्राउज़र: सुनिश्चित करें कि उपयोगकर्ता एक आधुनिक ब्राउज़र का उपयोग करता है जो Conditional UI का समर्थन करता है (नवीनतम ब्राउज़र कवरेज के लिए यहाँ देखें)।
• सक्षम JavaScript: Conditional UI संचालन को सुविधाजनक बनाने के लिए JavaScript सक्षम होना चाहिए।
• Conditional UI की उपलब्धता का परीक्षण करें: रिलाइंग पार्टी (सर्वर-साइड) को यह निश्चितता होनी चाहिए कि क्लाइंट-साइड पर Conditional UI उपलब्ध है, जब उसे WebAuthn mediation कॉल प्राप्त होता है ताकि उन परिदृश्यों में किसी भी उपयोगकर्ता-दृश्य त्रुटियों को ट्रिगर करने से बचा जा सके जहां Conditional UI समर्थित नहीं है। इसे संबोधित करने के लिए, Conditional UI की तकनीकी उपलब्धता की जांच करने के लिए isConditionalMediationAvailable() विधि का उपयोग करने की अनुशंसा की जाती है (अधिक जानकारी के लिए नीचे देखें)।
• HTML इनपुट फ़ील्ड आवश्यक: Conditional UI को काम करने के लिए, आपके वेब पेज में एक HTML इनपुट फ़ील्ड होना चाहिए। यदि आपके पास यह नहीं है, तो आपको नियमित पासकी / WebAuthn लॉगिन प्रक्रिया के लिए समर्थन प्रदान करना होगा जो किसी बटन क्लिक जैसे उपयोगकर्ता इंटरैक्शन के साथ ट्रिगर होता है।
• टाइमआउट प्रोटोकॉल निकालें: इस सेटअप में टाइमआउट मापदंडों (उदा., उपयोगकर्ता ऑटोफिल मेनू में पासकी तय करने में बहुत लंबा समय ले रहा है) की उपेक्षा की जानी चाहिए।

Conditional UI को काम करने के लिए, सर्वर-साइड पर कुछ आवश्यकताओं को भी पूरा किया जाना चाहिए:

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

2022 के अंत में Conditional UI के आधिकारिक रोलआउट और पहले के बीटा संस्करणों के बाद से, हम इसके साथ बड़े पैमाने पर परीक्षण और काम कर रहे हैं। निम्नलिखित में, हम आपके साथ व्यावहारिक सुझाव साझा करना चाहते हैं जो Conditional UI के कार्यान्वयन के दौरान मदद करते हैं।

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

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

Conditional UI विधि के लिए एक पूर्ण, न्यूनतम कोड उदाहरण इस तरह दिखाई देगा:

<!DOCTYPE html>
<html lang="en">
    <head>
        <meta charset="UTF-8" />
        <meta name="viewport" content="width=device-width, initial-scale=1.0" />
        <title>Conditional UI</title>
    </head>
    <body>
        <input type="text" id="username" autocomplete="username webauthn" />
 
        <script>
            async function passkeyLogin() {
                try {
                    // retrieve the request options (incl. the challenge) from the WebAuthn server
                    let options = await WebAuthnClient.getPublicKeyRequestOptions();
 
                    const credential = await navigator.credentials.get({
                        publicKey: options.publicKeyCredentialRequestOptions,
                        mediation: "conditional",
                    });
 
                    const userData = await WebAuthnClient.sendSignedChallenge(credential);
                    window.location.href = "/logged-in";
                } catch (error) {
                    console.log(error);
                }
            }
 
            passkeyLogin();
        </script>
    </body>
</html>

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

// source: https://developer.mozilla.org/en-US/docs/Web/API/PublicKeyCredential/isConditionalMediationAvailable#examples
 
// Availability of `window.PublicKeyCredential` means WebAuthn is usable.
if (window.PublicKeyCredential && PublicKeyCredential.isConditionalMediationAvailable) {
    // Check if conditional mediation is available.
    const isCMA = await PublicKeyCredential.isConditionalMediationAvailable();
    if (isCMA) {
        // Call WebAuthn authentication start endpoint
 
        let options = await WebAuthnClient.getPublicKeyRequestOptions();
 
        const credential = await navigator.credentials.get({
            publicKey: options.publicKeyCredentialRequestOptions,
            mediation: "conditional",
        });
        /*
        ...
        */
    }
}

इनपुट फ़ील्ड को एक webauthn HTML ऑटोफिल टोकन प्राप्त होना चाहिए। यह क्लाइंट को चल रहे अनुरोध में पासकीज़ को पॉप्युलेट करने का संकेत देता है। पासकीज़ के अलावा, अन्य ऑटोफिल मान भी दिखाए जा सकते हैं। इन ऑटोफिल टोकन को अन्य मौजूदा टोकन के साथ जोड़ा जा सकता है, उदा.:

• autocomplete="username webauthn": पासकीज़ प्रदर्शित करने के अलावा, यह यूज़रनेम ऑटोफिल का भी सुझाव देता है।
• autocomplete="current-password webauthn": पासकीज़ प्रदर्शित करने के अलावा, यह आगे पासवर्ड ऑटोफिल के लिए संकेत देता है।

<label for="name">Username:</label>
<input type="text" name="name" autocomplete="username webauthn" />
<label for="password">Password:</label>
<input type="password" name="password" autocomplete="current-password webauthn" />

अधिक जानकारी के लिए, हम इस ब्लॉग पोस्ट को पढ़ने की अनुशंसा करते हैं जो पासकीज़ और पासवर्ड के लिए ऑटोफिल / ऑटोकम्प्लीट टोकन पर अधिक विवरण प्रदान करता है।

PublicKeyCredentialRequestOptions ऑब्जेक्ट प्राप्त करने के बाद उपलब्ध पासकीज़ को पुनः प्राप्त करने के लिए, navigator.credentials.get() फ़ंक्शन को कॉल किया जाना चाहिए (जो पासकी और पासवर्ड दोनों के लिए कार्य करता है)। क्लाइंट पर Conditional UI को सक्रिय करने के लिए PublicKeyCredentialRequestOptions ऑब्जेक्ट में mediation पैरामीटर को conditional पर सेट किया जाना चाहिए। उन मामलों के लिए जहां आप इसके बजाय एक मोडल पासकी प्रॉम्प्ट चाहते हैं, तत्काल मध्यस्थता (immediate mediation) देखें।

const credential = await navigator.credentials.get({
    publicKey: options.publicKeyCredentialRequestOptions,
    mediation: "conditional",
});

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

यहाँ ज़ोर देने वाला एक महत्वपूर्ण बिंदु यह है कि चल रहे Conditional UI अनुरोध को रोकने की संभावित आवश्यकता है। मोडल अनुभवों के विपरीत, ऑटोफिल ड्रॉपडाउन में रद्दीकरण (cancellation) बटन का अभाव होता है। WebAuthn के डिज़ाइन के अनुसार, किसी भी दिए गए क्षण में केवल एक सक्रिय क्रेडेंशियल अनुरोध प्रगति पर होना चाहिए। WebAuthn मानक WebAuthn प्रक्रिया को रद्द करने के लिए AbortController का उपयोग करने का सुझाव देता है, जो नियमित और Conditional UI दोनों लॉगिन प्रक्रियाओं पर लागू होता है (विवरण के लिए यहाँ देखें)।

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

जैसे ही कोई उपयोगकर्ता पेज पर आता है, Conditional UI लॉगिन प्रक्रिया सक्रिय हो जाती है। प्रारंभिक कार्य विश्व स्तर पर स्कोप्ड AbortController ऑब्जेक्ट बनाना होना चाहिए। यह आपके क्लाइंट के लिए ऑटोफिल अनुरोध को समाप्त करने के लिए एक संकेत के रूप में कार्य करेगा, विशेष रूप से तब जब उपयोगकर्ता नियमित पासकी लॉगिन प्रक्रिया करने का निर्णय लेता है। आश्वस्त करें कि AbortController को अन्य फ़ंक्शंस द्वारा लागू किया जा सकता है और यदि Conditional UI प्रक्रिया को फिर से शुरू करना है तो इसे रीसेट किया जा सकता है। navigator.credentials.get() कॉल के भीतर सिग्नल प्रॉपर्टी को नियोजित करें, अपने AbortController सिग्नल को इसके मान के रूप में शामिल करें। यह पासकी / WebAuthn फ़ंक्शन को संकेत देता है कि यदि सिग्नल निरस्त हो जाता है तो अनुरोध को रोक दिया जाना चाहिए। हर बार जब आप Conditional UI ट्रिगर करते हैं तो एक नया AbortController सेट करना याद रखें। पहले से निरस्त AbortController का उपयोग करने से पासकी / WebAuthn फ़ंक्शन तुरंत रद्द हो जाएगा। शेष चरण नियमित पासकी लॉगिन प्रक्रिया के साथ संरेखित होते हैं। निम्नलिखित में, आप उल्लिखित चरणों का एक कोड उदाहरण देखते हैं:

<!DOCTYPE html>
<html lang="en">
    <head>
        <meta charset="UTF-8" />
        <meta name="viewport" content="width=device-width, initial-scale=1.0" />
        <title>Conditional UI</title>
    </head>
    <body>
        <input type="text" id="username" autocomplete="username webauthn" />
 
        <script>
            async function passkeyLogin() {
                try {
                    // retrieve the request options (incl. the challenge) from the WebAuthn server
                    let options = await WebAuthnClient.getPublicKeyRequestOptions();
 
                    const credential = await navigator.credentials.get({
                        publicKey: options.publicKeyCredentialRequestOptions,
                        mediation: "conditional",
                    });
 
                    const userData = await WebAuthnClient.sendSignedChallenge(credential);
                    window.location.href = "/logged-in";
                } catch (error) {
                    console.log(error);
                }
            }
 
            passkeyLogin();
        </script>
    </body>
</html>

Conditional UI समर्थन के अभाव में, उपयोगकर्ताओं को नियमित पासकी लॉगिन प्रक्रिया की ओर निर्देशित करें। यह मार्ग हार्डवेयर सुरक्षा कुंजियों (जैसे YubiKeys) पर निर्भर उपयोगकर्ताओं या ऑथेंटिकेटर की बाधाओं के कारण नॉन-रेज़िडेंट कीज़ / नॉन-डिस्कवरेबल क्रेडेंशियल्स का उपयोग करने के लिए मजबूर लोगों के लिए महत्वपूर्ण है।

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

Adoption data देखें

जब आप एक नेटिव ऐप विकसित करते हैं, उदाहरण के लिए iOS या Android के लिए, तो Conditional UI भी काम करता है। इससे कोई फर्क नहीं पड़ता कि आप इसे मूल रूप से Flutter, Kotlin या Swift में लागू करते हैं, या यदि आप Chrome Custom Tabs CCT या SFSafariViewController या SFAuthenticationSession / ASWebAuthenticationSession के साथ जाने का निर्णय लेते हैं। दोनों दृष्टिकोण Conditional UI का समर्थन करते हैं।

सामान्य तौर पर, हमें iOS ऐप्स के लिए Conditional UI समर्थन को कैसे लागू किया जाए, इस पर लगभग कोई दस्तावेज़ नहीं मिला। हमारे शोध के दौरान, हालांकि, हमने एक iOS ऐप में Conditional UI समर्थन जोड़ने के दो तरीके खोजे, क्योंकि उपयोगकर्ता का अनुभव भी अलग होगा।

प्रकार A: लगभग पूरी स्क्रीन पर ओवरले / पॉपअप

पहला प्रकार A एक ओवरले / पॉपअप दिखाता है जो लगभग पूरी स्क्रीन तक फैला होता है। यहां, आपको इस रिलाइंग पार्टी के लिए सभी उपलब्ध पासकीज़ दिखाई देंगी। एक प्रमुख उदाहरण जो इस तरह से Conditional UI को लागू करता है, वह है KAYAK। उपयोगकर्ता द्वारा सही स्क्रीन खोलने पर ओवरले / पॉपअप स्वचालित रूप से उभर आता है।

प्रकार B: कीबोर्ड ऑटोफिल

दूसरा प्रकार B कीबोर्ड के ऑटोफिल अनुभाग (जहां ऑटोफिल के लिए पासवर्ड भी सुझाए गए हैं) में एक उपयुक्त पासकी प्रदर्शित करता है। सुझाये गए मान पर क्लिक करने से Face ID प्रमाणीकरण होगा और आप लॉग इन कर सकेंगे। Corbado डेवलपर पैनल के वर्तमान iOS ऐप संस्करण में, हमने इसे इस तरह से लागू किया है (<relying party ID> संदेश के लिए WebAuthn यूज़रनेम के साथ पासकी के साथ साइन इन करें देखें)। इसे प्रदर्शित होने के लिए, उपयोगकर्ता को इनपुट फ़ील्ड में टैप करना होगा:

कीबोर्ड अनुभाग में इस पासकी ऑटोफिल सुविधा में कुछ समस्याएँ हो सकती हैं जब iOS ताज़ा स्थापित (freshly installed) होता है क्योंकि स्पष्ट रूप से पृष्ठभूमि में किसी प्रकार की कैशिंग होती है जो इस रिलाइंग पार्टी के लिए सभी उपलब्ध पासकीज़ को देखती है।

सुझाई गई पासकी के दाईं ओर कुंजी आइकन पर क्लिक करने से iOS में पासवर्ड / पासकीज़ चुनने के लिए ज्ञात साइट खुलती है:

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

Android में, Conditional की कहानी थोड़ी स्पष्ट है, क्योंकि Conditional UI / पासकी ऑटोफिल के लिए केवल एक प्रकार है जो Android Credential Manager API का लाभ उठाता है (दस्तावेज़ यहाँ देखें)। क्योंकि Android प्रदाता भिन्न हो सकते हैं, Credential Manager पासकी त्रुटियों को ब्राउज़र-ओनली WebAuthn विफलता पैटर्न से अलग-अलग मॉनिटर करें।

वह पृष्ठ खोलने पर जहाँ Conditional UI लागू किया गया है, निम्न स्क्रीन दिखाई देती है, जहाँ आपको साइन इन करने के विभिन्न तरीके मिलेंगे:

अधिक सहेजे गए साइन-इन (More saved sign-ins) पर क्लिक करने से साइन-इन के लिए चुनने के लिए अधिक विकल्प मिलते हैं (जिसमें क्रॉस-डिवाइस प्रमाणीकरण और एक अलग पासकी सिंक प्लेटफ़ॉर्म का चयन शामिल है, उदा. Samsung Pass या 1Password):

अंतिम उपयोगकर्ता के लिए Conditional UI कैसा दिखता है, यह बताने के लिए, हमने https://passkeys.eu का उपयोग करके Conditional UI ऑटोफिल मेनू के कई स्क्रीनशॉट जोड़े हैं।

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

Passkeys आज़माएं

आइए वास्तविक जीवन के अनुप्रयोगों में कुछ सामान्य परिदृश्यों पर एक नज़र डालें।

यदि किसी साइट के लिए कोई पासकी सहेजी नहीं गई है, तो ब्राउज़र और OS के आधार पर Conditional UI अलग तरह से व्यवहार करेगा।

macOS पर Chrome पर, इनपुट फ़ील्ड में क्लिक करने से एक खाली ऑटोफिल ड्रॉपडाउन दिखाई देता है:

macOS पर Safari पर, कोई ड्रॉपडाउन नहीं दिखाया जाता है - बस इनपुट फ़ील्ड में एक सूक्ष्म आइकन होता है:

Android या iOS पर, ऑटोफिल इंटरफ़ेस केवल तभी दिखाई देता है जब उपयोगकर्ता फ़ील्ड में टैप करता है और OS को मिलान (matching) वाले क्रेडेंशियल मिलते हैं।

यह परिवर्तनशीलता जानबूझकर है और WebAuthn के गोपनीयता मॉडल का हिस्सा है: वेबसाइटें यह पता नहीं लगा सकती हैं कि उपयोगकर्ता के पास कोई पासकी है या नहीं, जब तक कि उपयोगकर्ता सक्रिय रूप से किसी एक का चयन नहीं करता।

यदि किसी उपयोगकर्ता ने कई पासकी प्रदाता स्थापित किए हैं (उदा. iCloud Keychain, Google Password Manager, 1Password), तो ब्राउज़र या OS आमतौर पर उपयोगकर्ता के प्राथमिक क्रेडेंशियल मैनेजर पर डिफ़ॉल्ट हो जाएगा।

विभिन्न पासकी प्रदाताओं / क्रेडेंशियल मैनेजर्स की सूची के लिए जो पासकीज़ का समर्थन करते हैं, हम निम्नलिखित GitHub लिंक पर एक नज़र डालने की सलाह देते हैं।

Android पर, Credential Manager, Samsung Pass या 1Password जैसे विभिन्न प्रदाताओं को सामने लाता है।

1. यूज़र आइडेंटिफ़ायर इनपुट फ़ील्ड पर क्लिक करने पर, यह मेनू सामने आता है जहाँ उपयोगकर्ता पासकी चुन सकता है।

2. यदि उपयोगकर्ता ने पिछली स्क्रीन में "More passkeys" पर क्लिक किया था, तो अन्य पासकी प्रदाताओं / क्रेडेंशियल मैनेजर्स और पासकीज़ का पूर्व-चयन दिखाई देता है:

3. यदि उपयोगकर्ता ने पिछली स्क्रीन में "More saved sign-ins" पर क्लिक किया था, तो उपलब्ध की एक पूरी सूची आती है जहाँ उपयोगकर्ता एक पासकी चुन सकता है।

iOS पर, कुंजी आइकन विभिन्न स्रोतों से पासकीज़ की पूरी सूची खोलता है।

1. सबसे पहले, iOS 18+ पर, डिफ़ॉल्ट पासकी प्रदाता के साथ नियमित Conditional UI आता है।

2. कीबोर्ड आइकन पर क्लिक करने पर, निम्नलिखित चयन मेनू दिखाई देता है।

3. एक क्रेडेंशियल मैनेजर / पासकी प्रदाता का चयन करने के बाद, उपयोगकर्ता उपयोग की जाने वाली पासकी का चयन कर सकता है।

अपनी Conditional UI / पासकी ऑटोफिल क्षमता के साथ पासकीज़, ऑनलाइन प्रमाणीकरण करने का नया तरीका है। जैसे-जैसे हम एक ऐसे युग में प्रवेश कर रहे हैं जहाँ पासवर्ड की जगह पासकीज़ द्वारा तेज़ी से ली जा रही है, मजबूत और उपयोगकर्ता के अनुकूल संक्रमण तंत्र की आवश्यकता निर्विवाद है। इस लेख ने यह समझने में मदद की है कि Conditional UI को सही ढंग से कैसे लागू किया जाए, जो कि संक्रमण प्रक्रिया में एक बड़ी मदद है, और किन पहलुओं पर विशेष ध्यान देना चाहिए।

Corbado के बारे में

Corbado बड़े पैमाने पर consumer authentication चलाने वाली CIAM टीमों के लिए Authentication 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 विशेषज्ञ से बात करें →

PublicKeyCredential.isConditionalMediationAvailable() को कॉल करें और यदि यह true देता है तभी आगे बढ़ें। यह चेक असमर्थित ब्राउज़र और डिवाइस संयोजनों पर उपयोगकर्ता को दिखाई देने वाली त्रुटियों को रोकता है। navigator.credentials.get() को mediation: "conditional" के साथ कॉल करने से पहले हर पेज लोड पर इस विधि का मूल्यांकन किया जाना चाहिए।

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

प्लेटफ़ॉर्म के अनुसार व्यवहार अलग-अलग होता है। macOS पर Chrome एक खाली ऑटोफिल ड्रॉपडाउन दिखाता है, macOS पर Safari इनपुट फ़ील्ड में केवल एक सूक्ष्म आइकन दिखाता है, और Android या iOS पर ऑटोफिल इंटरफ़ेस केवल तभी दिखाई देता है जब उपयोगकर्ता द्वारा फ़ील्ड पर टैप करने के बाद OS को मिलान वाले क्रेडेंशियल मिलते हैं। यह परिवर्तनशीलता जानबूझकर है और WebAuthn के गोपनीयता मॉडल का हिस्सा है: वेबसाइटें यह पता नहीं लगा सकती हैं कि कोई पासकी मौजूद है या नहीं, जब तक कि उपयोगकर्ता सक्रिय रूप से किसी एक को नहीं चुनता।

एक विश्व स्तर पर स्कोप्ड AbortController बनाएं और इसके सिग्नल को navigator.credentials.get() को पास करें। जब उपयोगकर्ता मोडल लॉगिन प्रवाह शुरू करता है तो कंट्रोलर पर .abort() कॉल करें। जब भी Conditional UI पुनरारंभ होता है, हमेशा एक नया AbortController इंस्टेंट करें, क्योंकि पहले से रद्द किए गए कंट्रोलर का पुन: उपयोग करने से WebAuthn अनुरोध तुरंत रद्द हो जाता है।

Conditional UI नेटिव iOS और Android ऐप्स दोनों में काम करता है। iOS दो प्रकारों का समर्थन करता है: एक फुल-स्क्रीन ओवरले पॉपअप और एक कीबोर्ड ऑटोफिल सुझाव। Android Credential Manager API का उपयोग करता है, जो Samsung Pass या 1Password जैसे कई प्रदाताओं से पासकी दिखा सकता है।