WebAuthn इमीडिएट मीडिएशन: एक विस्तृत गाइड

60-page Enterprise Passkey Whitepaper:
Learn how leaders get +80% passkey adoption. Trusted by Rakuten, Klarna & Oracle

Get free Whitepaper

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

एक समाधान आइडेंटिफ़ायर-फ़र्स्ट होना और यूज़र के लिए सबसे अच्छा लॉगिन तरीका निर्धारित करना है। एक और संभावित समाधान एक सिंगल, इंटेलिजेंट "साइन इन" बटन है जो प्रत्येक यूज़र के लिए सबसे सहज फ़्लो को ऑर्केस्ट्रेट करता है। अगर डिवाइस पर पासकी उपलब्ध है तो इसे सीधे पासकी के लिए प्रॉम्प्ट करना चाहिए, या अगर नहीं है तो आसानी से दूसरे तरीकों पर फ़ॉलबैक करना चाहिए।

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

इमीडिएट मीडिएशन को समझने के लिए, पहले दूसरे विकल्पों को जानना मददगार है। WebAuthn में यूज़र मीडिएशन यह है कि ब्राउज़र आपकी वेबसाइट (Relying Party) और यूज़र के ऑथेंटिकेटर (जैसे, Face ID, YubiKey) के बीच इंटरैक्शन को कैसे मैनेज करता है।

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

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

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

Try for Free

यूज़र्स को पासकी पर ट्रांज़िशन में मदद करने के लिए पेश किया गया यह मोड ज़्यादा सूक्ष्म है। mediation: 'conditional' के साथ, WebAuthn रिक्वेस्ट को autocomplete="webauthn" एट्रिब्यूट के साथ एक इनपुट फ़ील्ड (जैसे, यूज़रनेम) से जोड़ा जाता है। जब यूज़र फ़ील्ड पर क्लिक करता है, तो ब्राउज़र का ऑटोफ़िल UI किसी भी उपलब्ध पासकी का सुझाव देता है।

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

mediation: 'immediate' "सिंगल साइन-इन बटन" की समस्या का समाधान है। यह एक वेबसाइट को कोई भी UI दिखाने से पहले पासकी की उपलब्धता की जांच करने का एक विश्वसनीय तरीका प्रदान करता है।

एक मोडल के माध्यम से यूज़र को पासकी से ऑथेंटिकेट करने के लिए बताने के बजाय, immediate मीडिएशन ब्राउज़र से पूछता है: "क्या इस यूज़र के लिए इस डिवाइस पर अभी कोई पासकी आसानी से उपलब्ध है?"

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

Want to try passkeys yourself in a passkeys demo?

Try Passkeys

इस फ़ीचर की शक्ति इसके स्पष्ट, बाइनरी परिणाम में निहित है। navigator.credentials.get() द्वारा लौटाया गया प्रॉमिस या तो सफल होगा या विफल, जिससे डेवलपर को एक स्पष्ट सिग्नल मिलेगा।

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

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

सही मीडिएशन मोड चुनना एक महत्वपूर्ण UX निर्णय है। यह तालिका एक साथ तुलना प्रदान करती है।

यहाँ mediation: 'immediate' को लागू करने के लिए एक व्यावहारिक, चरण-दर-चरण गाइड है।

चूंकि mediation: 'immediate' एक नया फ़ीचर है, इसलिए मजबूत फ़ीचर डिटेक्शन महत्वपूर्ण है।

// Feature detection is essential for progressive enhancement.
let immediateMediationAvailable = false;
 
if (window.PublicKeyCredential && PublicKeyCredential.getClientCapabilities) {
    try {
        const capabilities = await PublicKeyCredential.getClientCapabilities();
        // The 'immediateGet' capability signals browser support.
        immediateMediationAvailable = capabilities.immediateGet === true;
    } catch (e) {
        console.error("Error getting client capabilities:", e);
    }
}

यह कॉल एक यूज़र जेस्चर द्वारा ट्रिगर किया जाना चाहिए, जैसे कि एक बटन क्लिक।

// This function should be the event handler for your primary "Sign In" button.
async function handleSignInClick() {
    if (!immediateMediationAvailable) {
        // Fall back to showing a legacy login form if the feature isn't supported.
        showLegacyLoginForm();
        return;
    }
 
    try {
        // Fetch a fresh, random challenge from your server for each attempt.
        const challenge = await fetchChallengeFromServer();
 
        const publicKeyCredentialRequestOptions = {
            challenge: challenge, // The server-provided challenge as a Uint8Array
            rpId: "example.com",
            // The allowCredentials list MUST be empty for immediate mediation
            // to protect user privacy.
            allowCredentials: [],
        };
 
        const credential = await navigator.credentials.get({
            publicKey: publicKeyCredentialRequestOptions,
            // This is the key that enables the immediate mediation flow.
            mediation: "immediate",
        });
 
        // If the promise resolves, send the credential to your server for verification.
        await verifyCredentialOnServer(credential);
    } catch (error) {
        // The catch block is a critical part of the control flow.
        handleAuthError(error);
    }
}

catch ब्लॉक वह जगह है जहाँ सिंगल साइन-इन बटन की "इंटेलिजेंस" को साकार किया जाता है।

// Handling the NotAllowedError is the key to the fallback mechanism.
function handleAuthError(error) {
    // Check the 'name' property of the DOMException.
    if (error.name === "NotAllowedError") {
        // This is the expected signal to show the traditional login form.
        console.log("No local passkey found. Showing legacy login form.");
        showLegacyLoginForm();
    } else {
        // This handles other potential errors, like the user dismissing the prompt.
        console.error("Authentication error:", error);
    }
}

सबसे सहज अनुभव के लिए, आप ब्राउज़र से एक ही रिक्वेस्ट में पासकी और सहेजे गए पासवर्ड दोनों को खोजने के लिए कह सकते हैं, इसके लिए password: true जोड़ें।

// Combining passkeys and passwords for a truly unified sign-in experience.
const credential = await navigator.credentials.get({
    publicKey: publicKeyCredentialRequestOptions,
    password: true, // Ask the browser to include saved passwords.
    mediation: "immediate",
});
 
// The returned 'credential' object will either be a PublicKeyCredential
// or a PasswordCredential. Your server-side logic must handle both.

1. एक साथ WebAuthn रिक्वेस्ट्स: एक पेंडिंग conditional रिक्वेस्ट (जो अक्सर पेज लोड पर शुरू होती है) एक नई immediate रिक्वेस्ट को ब्लॉक कर सकती है। एक नई रिक्वेस्ट शुरू करने से पहले किसी भी पेंडिंग रिक्वेस्ट को रद्द करने के लिए AbortController का उपयोग करने पर विचार करें।
2. allowCredentials पर प्रतिबंध: allowCredentials ऐरे खाली होना चाहिए। क्रेडेंशियल आईडी प्रदान करने से कॉल विफल हो जाएगी। यह एक महत्वपूर्ण प्राइवेसी सुरक्षा उपाय है ताकि साइटें विशिष्ट, ज्ञात यूज़र्स की जांच न कर सकें।
3. यूज़र जेस्चर की आवश्यकता: कॉल को एक यूज़र जेस्चर (जैसे, एक 'क्लिक' इवेंट) से शुरू किया जाना चाहिए। इसे पेज लोड पर प्रोग्रामेटिक रूप से कॉल करने पर ब्राउज़र द्वारा प्राइवेसी सुरक्षा उपाय के रूप में ब्लॉक कर दिया जाएगा।

mediation: 'immediate' को इसके सुरक्षा और गोपनीयता ट्रेड-ऑफ़ की स्पष्ट समझ के साथ डिज़ाइन किया गया था।

मुख्य ट्रेड-ऑफ़ एक "वन-बिट लीक" है। प्रॉमिस के रिज़ॉल्यूशन के समय को मापकर, एक Relying Party एक बिट जानकारी का अनुमान लगा सकता है: क्या प्रॉमिस तुरंत रिजेक्ट हो गया (कोई लोकल क्रेडेंशियल नहीं) या इसमें देरी हुई (एक UI प्रॉम्प्ट दिखाया गया क्योंकि एक लोकल क्रेडेंशियल मिला था)। इस लीक का उद्देश्य एक बेहतर UX को सक्षम करना है।

डिजाइनरों ने दुरुपयोग (जैसे, यूज़र ट्रैकिंग) की क्षमता का अनुमान लगाया और कई अनिवार्य सुरक्षा उपाय बनाए:

1. अनिवार्य यूज़र जेस्चर: API कॉल को एक यूज़र एक्शन जैसे क्लिक द्वारा ट्रिगर किया जाना चाहिए। यह एक साइट को पेज लोड पर चुपचाप खातों की जांच करने से रोकता है और बड़े पैमाने पर फिंगरप्रिंटिंग को अव्यावहारिक बनाता है।
2. प्राइवेट/इनकॉग्निटो मोड में अक्षम: यह फ़ीचर प्राइवेट ब्राउज़िंग मोड में अस्वीकृत है ताकि एक यूज़र की गतिविधि को सामान्य और प्राइवेट सेशन के बीच जोड़ने से रोका जा सके।
3. निषिद्ध allowCredentials लिस्ट: allowCredentials ऐरे खाली होना चाहिए। यह एक साइट को इस फ़ीचर का उपयोग यह जांचने के लिए करने से रोकता है कि क्या कोई विशिष्ट ज्ञात यूज़र विज़िट कर रहा है।
4. केवल फ़र्स्ट-पार्टी कॉन्टेक्स्ट: यह फ़ीचर थर्ड-पार्टी कॉन्टेक्स्ट (जैसे, किसी अन्य ऑरिजिन से एक iframe) में अस्वीकृत है ताकि क्रॉस-साइट ट्रैकिंग को रोका जा सके।

ये उपाय सुनिश्चित करते हैं कि WebAuthn की मुख्य सुरक्षा गारंटी अछूती रहें। ऑथेंटिकेशन सेरेमनी स्वयं अपरिवर्तित रहती है और फ़िशिंग-प्रतिरोधी बनी रहती है।

mediation: 'immediate' WebAuthn लेवल 3 स्पेसिफिकेशन का एक उन्नत फ़ीचर है, और इसका रोलआउट जारी है। 2025 के मध्य तक, एक प्रोग्रेसिव एन्हान्समेंट रणनीति आवश्यक है।

जबकि mediation: 'immediate' एक स्मार्टर लॉगिन बटन के लिए एक बेहतरीन, लो-लेवल टूल प्रदान करता है, इसे एक व्यापक "पासकी इंटेलिजेंस" समाधान, जैसे कि Corbado द्वारा पेश किए गए समाधान से अलग करना महत्वपूर्ण है। दोनों का उद्देश्य पासकी पैराडॉक्स को हल करना और अपनाने को बढ़ाना है, लेकिन वे इसे अलग-अलग तरीकों से करते हैं।

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

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

यह डेटा-संचालित दृष्टिकोण mediation: 'immediate' के लिए ब्राउज़र सपोर्ट से स्वतंत्र है, जिसका अर्थ है कि यह आपके सभी यूज़र्स के लिए अभी एक अधिक इंटेलिजेंट लॉगिन फ़्लो प्रदान कर सकता है।

दोनों दुनियाओं का सर्वश्रेष्ठ

अंततः, ये दोनों दृष्टिकोण परस्पर अनन्य नहीं हैं; वे एक दूसरे के पूरक हैं। आदर्श समाधान उन्हें जोड़ता है:

1. अपनी लॉगिन प्रक्रिया के मस्तिष्क के रूप में एक पासकी इंटेलिजेंस सर्विस का उपयोग करें।
2. सर्विस तब mediation: 'immediate' का उपयोग समर्थित ब्राउज़रों पर अपने संकेतों में से एक के रूप में एक त्वरित, प्रारंभिक जांच करने के लिए कर सकती है।
3. परिणाम के आधार पर—या फ़ीचर के लिए सपोर्ट की कमी के आधार पर—इंटेलिजेंस सर्विस तब अपने समृद्ध, ऐतिहासिक डेटा का उपयोग सही फ़ॉलबैक को ऑर्केस्ट्रेट करने के लिए कर सकती है, चाहे वह पासवर्ड फ़ील्ड दिखाना हो या जस्ट-इन-टाइम पासकी बनाने का प्रॉम्प्ट देना हो।

mediation: 'immediate' की नेटिव गति को पासकी इंटेलिजेंस बैकएंड की गहरी जानकारी के साथ जोड़कर, आप सबसे सहज, अनुकूली और प्रभावी लॉगिन अनुभव प्रदान कर सकते हैं, जो हर यूज़र को धीरे-धीरे पासवर्ड रहित भविष्य की ओर मार्गदर्शन करता है।

इमीडिएट मीडिएशन लॉगिन अनुभव के लिए एक शानदार अपग्रेड है। यह पासकी पर ट्रांज़िशन के दौरान यूज़र्स के लिए रुकावट और भ्रम के सामान्य बिंदुओं को खत्म करने के लिए आवश्यक इंटेलिजेंस प्रदान करता है।

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

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

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

इन उन्नत ऑथेंटिकेशन फ़्लो को लागू करना जटिल हो सकता है। Corbado का एंटरप्राइज़ पासकी प्लेटफ़ॉर्म इस जटिलता को दूर करता है। हमारा इंफ़्रास्ट्रक्चर इष्टतम फ़्लो ऑर्केस्ट्रेशन को संभालता है—जिसमें कंडीशनल और immediate मीडिएशन शामिल है—जिससे आपकी टीम आत्मविश्वास के साथ एक अत्याधुनिक, घर्षण रहित ऑथेंटिकेशन अनुभव तैनात कर सकती है।