प्रॉम्प्ट और दायरा
आपके पास एक वेबसाइट है जिसमें पहले से ही पासवर्ड लॉगिन मौजूद है और आप Passkeys जोड़ना चाहते हैं। समर्थित ब्राउज़रों पर, यूज़र्स को एक स्पष्ट फ़ॉलबैक और रिकवरी पाथ को बनाए रखते हुए प्लेटफ़ॉर्म अनलॉक या सिक्योरिटी की के साथ प्रमाणित (authenticate) करना चाहिए। navigator.credentials.create(), navigator.credentials.get(), चैलेंजेस, RP IDs, ओरिजिन चेक्स और क्रेडेंशियल लाइफ़साइकल सीमाओं सहित फ़्रंटएंड और सर्वर के सहयोग को डिज़ाइन करें।
WebAuthn ब्राउज़र और ऑथेंटिकेटर के बीच एक पब्लिक-की ऑथेंटिकेशन API है। प्राइवेट की ऑथेंटिकेटर में रहती है और वेबसाइट पब्लिक की को स्टोर करती है। फ़्रंटएंड सर्वर ऑप्शन्स प्राप्त करता है, ब्राउज़र API को कॉल करता है, परिणाम को सीरियलाइज़ करता है और स्थिति को रेंडर करता है; सर्वर को सिग्नेचर सत्यापित करने, चैलेंजेस का उपयोग (consume) करने और क्रेडेंशियल्स को अकाउंट्स से बाइंड करने की आवश्यकता होती है।
इंटरव्यूअर क्या टेस्ट कर रहा है
एक मजबूत उत्तर रजिस्ट्रेशन और साइन-इन को दो छोटे स्टेटफ़ुल फ़्लो में अलग करता है: सर्वर एक बार इस्तेमाल होने वाला अप्रत्याशित (unpredictable) चैलेंज बनाता है, फ़्रंटएंड ऑथेंटिकेटर को कॉल करता है, और सर्वर सेशन बनाने से पहले लौटाए गए चैलेंज, ओरिजिन, RP ID, सिग्नेचर और काउंटर को सत्यापित करता है। यह "Face ID दिखाई दिया" को प्रोटोकॉल की सफलता मानने के बजाय HTTPS सिक्योर कॉन्टेक्स्ट्स, यूज़र कैंसिलेशन, टाइमआउट्स, डिवाइस माइग्रेशन, मल्टीपल क्रेडेंशियल्स और रिकवरी को भी कवर करता है।
इंटरव्यूअर इस बात पर ध्यान देगा कि क्या आप समझते हैं कि कंडीशनल ऑटोफ़िल एक UX कैपेबिलिटी है, सर्वर वेरिफिकेशन का विकल्प नहीं। वे यह भी पूछ सकते हैं कि सर्वर क्रेडेंशियल को हटाने के बाद WebAuthn सिग्नल APIs को क्यों कॉल किया जाना चाहिए ताकि ऑथेंटिकेटर अपनी स्थिति को अपडेट कर सके।
पहले स्पष्ट करने योग्य प्रश्न
समर्थित क्लाइंट्स और अकाउंट पॉलिसी
टारगेट ब्राउज़र, मोबाइल और डेस्कटॉप प्लेटफ़ॉर्म, क्या सिंक किए गए डिस्कवरेबल क्रेडेंशियल्स की अनुमति है, और क्या पासवर्ड या सिक्योरिटी की उपलब्ध रहेंगी, इसकी पुष्टि करें। ये विकल्प residentKey, userVerification, क्रेडेंशियल चयन और हेल्प टेक्स्ट को प्रभावित करते हैं।
डोमेन और डिप्लॉयमेंट टोपोलॉजी
प्रोडक्शन और लॉगिन सबडोमेन, iframes, रिवर्स प्रॉक्सी और टेनेंट-विशिष्ट डोमेन की पुष्टि करें। RP ID वर्तमान ओरिजिन के लिए एक मान्य संबंधित डोमेन होना चाहिए। प्रोडक्शन में जाने वाला एक प्रीव्यू डोमेन केवल धारणा के आधार पर कॉन्फ़िगरेशन का सुरक्षित रूप से पुन: उपयोग नहीं कर सकता है।
रिकवरी और उच्च जोखिम वाले कार्य
पूछें कि जब सभी ऑथेंटिकेटर खो जाते हैं तो यूज़र नियंत्रण कैसे साबित करता है, और क्या रीसेट सेशन को रद्द करता है, यूज़र को सूचित करता है, या उच्च जोखिम वाले कार्यों में देरी करता है। रिकवरी आइडेंटिटी लाइफ़साइकल का हिस्सा है; इसे केवल फ़्रंटएंड के "use password" लिंक तक सीमित नहीं किया जा सकता है।
30-सेकंड उत्तर फ़्रेमवर्क
"रजिस्ट्रेशन और साइन-इन दोनों सर्वर से एक बार इस्तेमाल होने वाले अप्रत्याशित चैलेंज के साथ शुरू होते हैं। फ़्रंटएंड WebAuthn को ऑप्शन्स पास करता है। रजिस्ट्रेशन के दौरान, सर्वर क्रेडेंशियल ID को अकाउंट से बाइंड करने से पहले चैलेंज, ओरिजिन, RP ID, अटेस्टेशन पॉलिसी और पब्लिक की को सत्यापित करता है। साइन-इन के दौरान, यह सेशन बनाने से पहले असर्शन सिग्नेचर, चैलेंज, RP ID, ओरिजिन और सिग्नेचर काउंटर को सत्यापित करता है। फ़्रंटएंड असमर्थित, कैंसिल्ड, टाइम-आउट और रिजेक्टेड स्थितियों के बीच अंतर करता है। कंडीशनल मीडिएशन ऑटोफ़िल प्रदान कर सकता है लेकिन सटीकता के लिए यह अनिवार्य नहीं है। डिवाइस खो जाने पर जोखिम-नियंत्रित रिकवरी की जाती है, पुराने सेशन्स को रद्द किया जाता है और एक नया क्रेडेंशियल रजिस्टर करने की अनुमति दी जाती है।"
चरण-दर-चरण समाधान
चरण 1: सर्वर को चैलेंज बनाने दें
रजिस्ट्रेशन या साइन-इन पेज पहले सर्वर से एक फ़्लो बनाने के लिए कहता है। सर्वर कम से कम 16 बाइट्स का रैंडम चैलेंज डेटा जनरेट करता है और इसके हैश, अकाउंट, उद्देश्य, समाप्ति (expiry) और उपयोग की स्थिति को स्टोर करता है। फ़्रंटएंड को इसे जनरेट या पुन: उपयोग नहीं करना चाहिए: अन्यथा एक पुराने असर्शन को दूसरे फ़्लो में ले जाया जा सकता है। सर्वर वर्तमान RP के लिए publicKey ऑप्शन्स लौटाता है, और फ़्रंटएंड सुरक्षा-संवेदनशील फ़ील्ड्स को दोबारा नहीं लिखता है।
चरण 2: रजिस्ट्रेशन डिज़ाइन करें
एक HTTPS सिक्योर कॉन्टेक्स्ट में, फ़्रंटएंड navigator.credentials.create() को कॉल करता है। ऑप्शन्स में RP, यूज़र ID, डिस्प्ले नाम, स्वीकृत पब्लिक-की एल्गोरिदम, यूज़र-वेरिफिकेशन प्राथमिकता और डिस्कवरेबल-क्रेडेंशियल पॉलिसी शामिल हैं। Promise के रिज़ॉल्व होने के बाद, फ़्रंटएंड क्रेडेंशियल ID, क्लाइंट डेटा, अटेस्टेशन रिस्पॉन्स और आवश्यक एक्सटेंशन को सर्वर पर सीरियलाइज़ करता है। प्राइवेट की कभी भी ऑथेंटिकेटर से बाहर नहीं जाती है।
चरण 3: सर्वर पर रजिस्ट्रेशन सत्यापित करें
सर्वर जांचता है कि चैलेंज फ़्लो से मेल खाता है, ओरिजिन की अनुमति है, RP ID हैश सही है, और सिग्नेचर और पब्लिक-की एल्गोरिदम पॉलिसी को पूरा करते हैं। यह प्राइवेसी और कम्पैटिबिलिटी लक्ष्यों के आधार पर अटेस्टेशन को मान्य करने का निर्णय लेता है। सफलता पर यह केवल पब्लिक की, क्रेडेंशियल ID, अकाउंट, सिग्नेचर काउंटर और आवश्यक डिवाइस लेबल को स्टोर करता है। इसे पूरे रॉ ऑब्जेक्ट या पहचान योग्य डिवाइस डेटा को हमेशा के लिए रिटेन नहीं करना चाहिए।
चरण 4: साइन-इन और कंडीशनल ऑटोफ़िल डिज़ाइन करें
साइन-इन के लिए, सर्वर एक नया चैलेंज बनाता है और फ़्रंटएंड इसके साथ navigator.credentials.get() को कॉल करता है, फिर असर्शन सबमिट करता है। सर्वर क्रेडेंशियल ID से अकाउंट का समाधान करने से पहले चैलेंज, ओरिजिन, RP ID, सिग्नेचर और काउंटर को सत्यापित करता है। कंडीशनल मीडिएशन के साथ, यूज़र द्वारा यूज़रनेम फ़ील्ड के साथ इंटरैक्ट करने के बाद पेज डिस्कवरेबल क्रेडेंशियल्स का अनुरोध कर सकता है, जिससे ब्राउज़र को ऑटोफ़िल में Passkeys दिखाने की अनुमति मिलती है। यह डिस्कवरी UX को बदलता है, वेरिफिकेशन अनुबंध को नहीं।
चरण 5: फ़्रंटएंड स्टेट और विफलताओं को संभालें
कैंसिलेशन, टाइमआउट, असमर्थित ब्राउज़र, ब्लॉक की गई परमिशन पॉलिसी और सर्वर रिजेक्शन अलग-अलग यूज़र-समझने योग्य स्थितियां बननी चाहिए। AbortController यूज़र के पेज छोड़ने या फिर से क्लिक करने पर पेंडिंग कॉल को रद्द कर सकता है, जिससे पुरानी Promise को वर्तमान स्थिति को ओवरराइट करने से रोका जा सकता है। फ़्रंटएंड को सिग्नेचर, क्रेडेंशियल IDs या आंतरिक सर्वर एरर नहीं दिखाने चाहिए, और कभी भी किसी अधूरे रजिस्ट्रेशन को सफल के रूप में चिह्नित नहीं करना चाहिए।
चरण 6: रिकवरी, रिवोकेशन और क्रेडेंशियल प्रबंधन
अकाउंट सेटिंग्स में क्रेडेंशियल लेबल, निर्माण का समय और अंतिम बार उपयोग किए जाने का समय सूचीबद्ध होना चाहिए, और एक क्रेडेंशियल को हटाने की अनुमति होनी चाहिए। सर्वर द्वारा इसे हटाने के बाद, बाद का कोई अज्ञात क्रेडेंशियल ID PublicKeyCredential.signalUnknownCredential() को ट्रिगर कर सकता है; एक सफल साइन-इन सर्वर द्वारा अभी भी स्वीकार की जाने वाली IDs को सिंक्रनाइज़ करने के लिए signalAllAcceptedCredentials() का उपयोग कर सकता है। सभी ऑथेंटिकेटर खो जाने पर जोखिम-नियंत्रित रिकवरी का उपयोग किया जाता है जैसे कि पासवर्ड के साथ जोखिम जांच, एक सत्यापित ईमेल, या सपोर्ट समीक्षा। पुराने सेशन्स को रद्द करें और फिर एक नया Passkey रजिस्ट्रेशन आवश्यक करें।
चरण 7: सत्यापित करें और विकसित करें
विभिन्न ब्राउज़रों, प्लेटफ़ॉर्म ऑथेंटिकेटर्स, सिंक किए गए क्रेडेंशियल्स, सिक्योरिटी कीज़, कैंसिलेशन, टाइमआउट, गलत ओरिजिन, समाप्त और दोहराए गए चैलेंजेस, काउंटर विसंगतियों और रिकवरी के बाद के पुराने क्रेडेंशियल्स का परीक्षण करें। यूज़र-एजेंट स्ट्रिंग्स से अनुमान लगाने के बजाय कैपेबिलिटीज का पता लगाएं और सर्वर से पॉलिसी प्राप्त करें। नए एक्सटेंशन फ़ॉलबैक UI के साथ वैकल्पिक होने चाहिए, और एक अज्ञात एक्सटेंशन को कोर सर्वर वेरिफिकेशन को नहीं बदलना चाहिए।
उच्च गुणवत्ता वाला नमूना उत्तर
मैं Passkey को सर्वर-संचालित पब्लिक-की ऑथेंटिकेशन फ़्लो के रूप में मानूंगा। जब कोई यूज़र रजिस्ट्रेशन शुरू करता है, तो फ़्रंटएंड सर्वर से एक बार इस्तेमाल होने वाले चैलेंज और publicKey ऑप्शन्स का अनुरोध करता है, फिर HTTPS पर WebAuthn को कॉल करता है। केवल सर्वर ही चैलेंज, ओरिजिन, RP ID, सिग्नेचर, एल्गोरिदम और किसी भी आवश्यक अटेस्टेशन को सत्यापित करता है, फिर क्रेडेंशियल ID, पब्लिक की, काउंटर और अकाउंट बाइंडिंग को स्टोर करता है। प्राइवेट की ऑथेंटिकेटर में ही रहती है।
साइन-इन एक अन्य सर्वर चैलेंज के साथ शुरू होता है। फ़्रंटएंड navigator.credentials.get() को कॉल करता है, असर्शन सबमिट करता है, और सर्वर सेशन बनाने से पहले इसके सिग्नेचर, चैलेंज, ओरिजिन, RP ID और काउंटर को सत्यापित करता है। यदि कंडीशनल मीडिएशन समर्थित है, तो मैं यूज़रनेम-फ़ील्ड इंटरैक्शन के बाद Passkey ऑटोफ़िल की पेशकश करता हूं, लेकिन यह उसी सर्वर वेरिफिकेशन का पालन करता है।
फ़्रंटएंड असमर्थित, कैंसिल्ड, टाइम-आउट और रिजेक्टेड स्थितियों के बीच अंतर करता है, और पेज छोड़े जाने पर पेंडिंग कॉल्स को रद्द कर देता है। अकाउंट सेटिंग्स क्रेडेंशियल्स को सूचीबद्ध और हटाती हैं; हटाने के बाद, WebAuthn सिग्नल्स ब्राउज़र को अज्ञात क्रेडेंशियल का सुझाव देने से रोकते हैं। डिवाइस खो जाने पर जोखिम-नियंत्रित रिकवरी की आवश्यकता होती है, पुराने सेशन्स रद्द होते हैं, यूज़र को सूचित किया जाता है, और एक प्रतिस्थापन क्रेडेंशियल रजिस्टर किया जाता है। परीक्षण क्रॉस-प्लेटफ़ॉर्म ऑथेंटिकेटर्स, गलत ओरिजिन, समाप्त या दोहराए गए चैलेंजेस, काउंटर विसंगतियों, ब्राउज़र फ़ॉलबैक और रिकवरी के बाद के पुराने क्रेडेंशियल्स को कवर करते हैं ताकि UX परिवर्तन कभी भी प्रोटोकॉल वेरिफिकेशन को कमजोर न करें।
सामान्य गलतियां
- गलती: फ़्रंटएंड में चैलेंज जनरेट करना या इसे पेज कॉन्सटेंट में रखना। → यह क्यों विफल होता है: एक हमलावर पुराने असर्शन को दोबारा चला (replay) सकता है और सर्वर फ़्लो की ताजगी (freshness) स्थापित नहीं कर सकता है। → सुधार: इसे सर्वर पर जनरेट करें, इसे थोड़े समय के लिए स्टोर करें, इसे एक बार उपयोग करें, और इसे अकाउंट और उद्देश्य से बाइंड करें।
- गलती: Promise रिज़ॉल्व होने पर यूज़र को साइन इन करना। → यह क्यों विफल होता है: ब्राउज़र ऑब्जेक्ट इस बात का प्रमाण नहीं है कि सर्वर ने ओरिजिन, RP ID और सिग्नेचर को सत्यापित किया है। → सुधार: सर्वर पर असर्शन वैलिडेशन पूरा करें और फ़्रंटएंड को संरचित परिणाम रेंडर करने दें।
- गलती: यूज़र-एजेंट स्ट्रिंग्स के साथ सपोर्ट का पता लगाना। → यह क्यों विफल होता है: ब्राउज़र संस्करण, प्लेटफ़ॉर्म ऑथेंटिकेटर्स और परमिशन पॉलिसी भिन्न होती हैं। → सुधार: कैपेबिलिटी APIs और सर्वर पॉलिसी का उपयोग करें, फिर एक स्पष्ट पासवर्ड या सिक्योरिटी-की रूट प्रदान करें।
- गलती: डिवाइस स्थिति को सिंक्रनाइज़ किए बिना डेटाबेस क्रेडेंशियल को हटाना। → यह क्यों विफल होता है: ऑथेंटिकेटर अभी भी मानता है कि क्रेडेंशियल मौजूद है और एक अनुपयोगी विकल्प पेश करता रहता है। → सुधार: उचित रूप से प्रमाणित स्थिति में WebAuthn सिग्नल APIs को कॉल करें और एक पुन: रजिस्ट्रेशन पाथ प्रदान करें।
फॉलो-अप प्रश्न और उत्तर
फॉलो-अप 1: RP ID कोई भी API डोमेन क्यों नहीं हो सकता?
RP ID वर्तमान ओरिजिन के लिए एक संबंधित डोमेन होना चाहिए और इसे ब्राउज़र और सर्वर दोनों द्वारा जांचा जाता है। एक असंबंधित मान निर्माण को विफल बनाता है या ट्रस्ट स्कोप का विस्तार करता है। मल्टी-टेनेंट डोमेन के लिए, प्रत्येक विश्वसनीय डोमेन को स्पष्ट रूप से कॉन्फ़िगर करें; क्लाइंट द्वारा प्रदान की गई किसी भी मनमानी स्ट्रिंग को कभी स्वीकार न करें।
फॉलो-अप 2: यूज़र ने फ़ोन पर रजिस्ट्रेशन किया, लेकिन डेस्कटॉप पर कोई की नहीं है। अब क्या होगा?
यदि सिंक किए गए डिस्कवरेबल क्रेडेंशियल्स की अनुमति है, तो ब्राउज़र और क्रेडेंशियल मैनेजर विभिन्न डिवाइसेस पर एक ही अकाउंट की Passkey प्रदान कर सकते हैं। अन्यथा क्रॉस-डिवाइस QR फ़्लो या सिक्योरिटी की प्रदान करें। फ़्रंटएंड को यह बताना चाहिए कि डिवाइस क्रेडेंशियल का उपयोग नहीं कर सकता है और एक कार्रवाई प्रदान करनी चाहिए; सर्वर अभी भी ओरिजिन सहित समान चैलेंज और असर्शन नियमों को सत्यापित करता है।
फॉलो-अप 3: क्या काउंटर रोलबैक से अकाउंट को तुरंत लॉक कर दिया जाना चाहिए?
पहले सिंक किए गए प्लेटफ़ॉर्म क्रेडेंशियल्स, बैकअप रिस्टोरेशन और वास्तविक क्लोनिंग जोखिम के बीच अंतर करें। बिना संदर्भ के स्थायी रूप से लॉक करने के बजाय, विसंगति को एक जोखिम संकेत के रूप में मानें जिसमें अतिरिक्त सत्यापन की आवश्यकता हो सकती है और यूज़र को सूचित किया जा सकता है। उच्च-मूल्य वाले कार्यों के लिए किसी अन्य रजिस्टर्ड क्रेडेंशियल या सपोर्ट समीक्षा की आवश्यकता हो सकती है, जिसका निर्णय पॉलिसी ट्यूनिंग के लिए रिकॉर्ड किया जाता है।
फॉलो-अप 4: क्या रिकवरी Passkey सुरक्षा को कमजोर करती है?
यह कमजोर करती है यदि रिकवरी केवल संभावित रूप से खतरे में पड़े ईमेल लिंक पर निर्भर करती है। टियर वाले जोखिम चेक्स, सेशन रिवोकेशन, कूलिंग पीरियड, नोटिफिकेशन और उच्च जोखिम वाले कार्यों में देरी का उपयोग करें। रिकवरी के बाद, एक नया क्रेडेंशियल रजिस्टर करें और पुराने को हटा दें। यूज़र्स से यह वादा करने के बजाय कि वे कभी भी एक्सेस नहीं खो सकते, उपलब्धता बनाम अकाउंट-टेकओवर ट्रेड-ऑफ़ को समझाएं।