Frontend इंटरव्यू: आप WebAuthn conditional create को सुरक्षित रूप से कैसे रोल आउट करेंगे?

प्रॉम्प्ट और लागू संदर्भ

उत्पाद पहले से ही यूज़रनेम/पासवर्ड लॉगिन और पासकी साइन-इन के लिए conditional get का समर्थन करता है। आप उच्च-विश्वास (high-trust) लॉगिन के बाद WebAuthn Level 3 conditional create का उपयोग करना चाहते हैं, जिससे फ़्लो में बाधा डाले बिना पासकी का सुझाव दिया जा सके। ब्राउज़र क्षमता पहचान, निर्माण गेट्स (creation gates), सर्वर सत्यापन, प्राइवेसी सीमाओं और रोलबैक की व्याख्या करें।

यह वेब प्लेटफ़ॉर्म और प्रमाणीकरण UX पर केंद्रित है। ब्राउज़र API समर्थन का अर्थ यह नहीं है कि डिवाइस में उपयोग करने योग्य प्रमाणीकर्ता (authenticator) है; निर्माण के लिए अभी भी उपयोगकर्ता की सहमति और सर्वर सत्यापन की आवश्यकता होती है।

इंटरव्यूअर क्या मूल्यांकन करता है

• क्या आप conditional create, conditional get और स्पष्ट बटन-आधारित निर्माण के बीच अंतर करते हैं।
• क्या आप क्षमता, नीति, अकाउंट स्थिति और क्रॉस-डिवाइस सिंक्रोनाइज़ेशन को स्पष्ट गेट्स से जोड़ते हैं।
• क्या आप डुप्लिकेट क्रेडेंशियल्स, अकाउंट की गलत बाइंडिंग, क्रेडेंशियल-अस्तित्व के लीक होने और पासवर्ड लॉगिन के बाधित होने को रोकते हैं।
• क्या आप हर जगह एक नया API सक्षम करने के बजाय इस सुविधा को कैनरी (canary) और वापस (withdraw) ले सकते हैं।

एक मजबूत उत्तर conditional create को एक संवर्द्धन (enhancement) के रूप में मानता है: असमर्थित, रद्द या टाइम-आउट प्रयास प्राथमिक फ़्लो को अपरिवर्तित छोड़ देते हैं, जबकि सर्वर अभी भी challenge, origin, RP ID और अकाउंट बाइंडिंग की पुष्टि करता है।

उत्तर देने से पहले स्पष्टीकरण प्रश्न

1. क्या लक्ष्य प्रत्येक साइन-इन उपयोगकर्ता है, या केवल सत्यापित ईमेल, MFA, या हाल ही में उच्च-जोखिम वाले पुन: प्रमाणीकरण वाले उपयोगकर्ता हैं?
2. क्या मल्टी-डिवाइस सिंक्रोनाइज़्ड पासकीज़ की अनुमति है? यह रिकवरी और निरसन (revocation) आवश्यकताओं को बदलता है।
3. क्या पेज पर पहले से ही कोई लंबित credentials.create() अनुरोध हो सकता है? समवर्ती अनुरोध प्रॉम्प्ट्स को अप्रत्याशित बनाते हैं।
4. जब conditional create अनुपलब्ध हो, तो क्या आपको एक स्पष्ट “Create a passkey” बटन दिखाना चाहिए या सुविधा को छिपाना चाहिए?

30-सेकंड का उत्तर ढांचा

“मैं conditional-create क्षमता का पता लगाऊंगा, फिर प्रयास करने से पहले अकाउंट स्थिति, हालिया प्रमाणीकरण शक्ति और सर्वर फ़ीचर फ़्लैग को संयोजित करूंगा। क्लाइंट एक स्पष्ट उपयोगकर्ता-स्वीकृत क्षण पर अधिकतम एक अनुरोध शुरू करता है और AbortController के साथ डुप्लिकेट को रद्द करता है; असमर्थित, रद्द या टाइम-आउट प्रयास मूल फ़्लो पर वापस आ जाते हैं। सर्वर उपयोगकर्ता, origin, RP ID और समाप्ति (expiry) के लिए एक बार उपयोग होने वाले challenge को बाइंड करता है, और सत्यापन के बाद ही क्रेडेंशियल संग्रहीत करता है। कैनरी के दौरान मैं निर्माण सफलता, रद्दीकरण, डुप्लिकेट क्रेडेंशियल्स, पासवर्ड फ़ॉलबैक और रिकवरी टिकटों को ट्रैक करूंगा। कोई घटना होने पर फ़्लैग अक्षम हो जाता है; मौजूदा क्रेडेंशियल्स का अभी भी उपयोग किया जा सकता है या अलग से निरस्त किया जा सकता है।”

चरण-दर-चरण विस्तृत उत्तर

1. दो सशर्त अंतःक्रियाओं (conditional interactions) को अलग करें

Conditional get उपयोगकर्ता को खाता दर्ज करते समय मौजूदा पासकी चुनने की अनुमति देता है; conditional create फ़ॉर्म संदर्भ में एक नया क्रेडेंशियल पंजीकृत करने का सुझाव देता है। दोनों ब्राउज़र और प्रमाणीकर्ता क्षमता पर निर्भर करते हैं, इसलिए केवल PublicKeyCredential ऑब्जेक्ट की जाँच करना अपर्याप्त है।

क्षमता पहचान यह तय करती है कि प्रयास करना है या नहीं, यह नहीं कि अधिकृत करना है या नहीं। सर्वर को अभी भी पंजीकरण को वर्तमान में प्रमाणित उपयोगकर्ता से बाइंड करना चाहिए और निर्माण स्रोत और नीति संस्करण को रिकॉर्ड करना चाहिए।

2. निर्माण गेट्स (creation gates) परिभाषित करें

इन सभी की आवश्यकता रखें: ब्राउज़र conditional-create क्षमता की रिपोर्ट करता है; उपयोगकर्ता ने हाल ही में पर्याप्त प्रमाणीकरण पूरा किया है; अकाउंट रिकवरी, मर्ज या उच्च-जोखिम वाले परिवर्तन में नहीं है; और एक सर्वर फ़्लैग टेनेंट और ट्रैफ़िक स्लाइस को सक्षम करता है। एक नए डिवाइस पर, लाभ समझाएं और पेज लोड पर बनाने के बजाय उपयोगकर्ता को जारी रखने दें।

3. डुप्लिकेट और रेस कंडीशंस को रोकें

प्रति पेज सत्र में एक निर्माण अनुरोध की अनुमति दें। दूसरा शुरू करने से पहले पिछले अनुरोध को रद्द करें और घटक के अनमाउंट होने पर इसे रद्द करें। एक सर्वर challenge एकल-उपयोग होता है, क्रेडेंशियल IDs में एक यूनीक कंस्ट्रेंट होता है, और डुप्लिकेट सबमिशन दूसरी पंक्ति बनाने के बजाय एक इडेम्पोटेंट परिणाम लौटाते हैं।

capability -> policy gate -> one challenge -> user consent
      |            |               |
   fallback   feature flag     server verify -> persist

4. पंजीकरण को पूरी तरह से मान्य करें

सर्वर challenge, origin, RP ID, हस्ताक्षर, user handle, अटेस्टेशन नीति और क्रेडेंशियल ID की पुष्टि करता है। क्लाइंट-साइड "created" परिणाम पर कभी भरोसा न करें। यदि डिवाइस अटेस्टेशन की आवश्यकता नहीं है, तो एक सरल अटेस्टेशन नीति चुनें और गोपनीयता तथा जोखिम के बीच के समझौते को बताएं।

5. सिंक्रोनाइज़ेशन और रिकवरी को संभालें

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

6. उपयोगी टेलीमेट्री के साथ कैनरी रोलआउट

ब्राउज़र, प्लेटफ़ॉर्म, टेनेंट और जोखिम स्तर के आधार पर सक्षम करें। क्षमता पहचान, प्रॉम्प्ट प्रदर्शन, सहमति, सत्यापन विफलताएं, रद्दीकरण/टाइमआउट, डुप्लिकेट क्रेडेंशियल्स, पासवर्ड फ़ॉलबैक और सहायता टिकट रिकॉर्ड करें। “असमर्थित” को “उपयोगकर्ता द्वारा अस्वीकृत” से अलग करें; अन्यथा आप यह नहीं बता सकते कि कॉपी में सुधार करना है या सुविधा को अक्षम करना है।

7. खातों को तोड़े बिना रोलबैक करें

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

उच्च गुणवत्ता वाला नमूना उत्तर

मैं conditional create को एक प्रतिवर्ती संवर्द्धन (reversible enhancement) के रूप में शिप करूंगा। क्लाइंट क्षमता का पता लगाता है, फिर अकाउंट स्थिति, हालिया प्रमाणीकरण शक्ति और एक फ़ीचर फ़्लैग की जांच करता है; प्रति पेज एक अनुरोध लागू किया जाता है और AbortController डुप्लिकेट को रद्द करता है। सर्वर एक एकल-उपयोग challenge बनाता है और स्थायित्व से पहले challenge, origin, RP ID, हस्ताक्षर और क्रेडेंशियल ID की पुष्टि करता है। असमर्थित, रद्द या टाइम-आउट प्रयास पासवर्ड लॉगिन पर वापस आ जाते हैं और कभी भी लॉगिन विफलता नहीं बनते हैं। मैं क्षमता, सहमति, सत्यापन त्रुटियों, डुप्लिकेट क्रेडेंशियल्स, फ़ॉलबैक और रिकवरी टिकटों को ट्रैक करते हुए प्लेटफ़ॉर्म और जोखिम के आधार पर कैनरी करूंगा। फ़्लैग को अक्षम करने से नया निर्माण बंद हो जाता है लेकिन मौजूदा पासकी और निरसन उपलब्ध रहते हैं।

सामान्य गलतियाँ

• गलती → केवल यह जाँचना कि क्या PublicKeyCredential मौजूद है → ऑब्जेक्ट यह साबित नहीं करता है कि conditional create या कोई प्रमाणीकर्ता उपलब्ध है; समाधान: क्षमता पहचान का उपयोग करें और फ़ॉलबैक रखें।
• गलती → पेज लोड पर चुपचाप create को कॉल करना → उपयोगकर्ता ने सहमति नहीं दी और डुप्लिकेट प्रॉम्प्ट्स की संभावना बढ़ जाती है; समाधान: एक स्पष्ट उच्च-विश्वास क्षण पर ट्रिगर करें और उपयोगकर्ता को जारी रखने दें।
• गलती → क्लाइंट-साइड सफलता परिणाम पर भरोसा करना → challenge, origin, या अकाउंट बाइंडिंग असत्यापित हो सकते हैं; समाधान: सर्वर पर पंजीकरण सत्यापन पूरा करें।
• गलती → रोलबैक के दौरान नए क्रेडेंशियल्स को हटाना → एक रिलीज़ रोलबैक अकाउंट विनाश बन जाता है; समाधान: नए निर्माण को अक्षम करें और निरसन को अलग से प्रबंधित करें।

फॉलो-अप प्रश्न और प्रतिक्रियाएं

क्या उपयोगकर्ता द्वारा अस्वीकार किए जाने के बाद हर दिन प्रॉम्प्ट करना चाहिए?

नहीं। एक स्थानीय कूलडाउन और नीति संस्करण रिकॉर्ड करें। केवल तभी दोबारा पूछें जब अकाउंट जोखिम, डिवाइस या उत्पाद की स्थिति में भौतिक रूप से बदलाव हो; अस्वीकार करने से पासवर्ड लॉगिन प्रभावित नहीं होना चाहिए।

क्या होगा यदि एक ही खाते में समान क्रेडेंशियल ID वाली दो पंक्तियाँ हों?

क्रेडेंशियल ID को यूनीक बनाएं, पंजीकरण को इडेम्पोटेंट बनाएं और स्रोत रिकॉर्ड करें। यदि डुप्लिकेट पहले से मौजूद हैं, तो नए राइट्स (writes) को फ्रीज करें और उपयोगकर्ता तथा क्रेडेंशियल ID द्वारा मर्ज या समीक्षा करें; कभी भी चुपचाप किसी को ओवरराइट न करें।

क्षमता समर्थित है लेकिन सफलता अचानक गिर जाती है। आप सबसे पहले क्या निरीक्षण करेंगे?

रद्दीकरण, टाइमआउट, नीति अस्वीकृति और सर्वर सत्यापन विफलता को अलग करने के लिए ब्राउज़र संस्करण, प्लेटफ़ॉर्म, प्रमाणीकर्ता और त्रुटि कोड द्वारा स्लाइस करें। प्रभावित फ़्लैग कोहोर्ट को रोकें, पासवर्ड और मौजूदा पासकी लॉगिन रखें, कारण ठीक करें और एक छोटे कोहोर्ट के साथ पुन: मान्य करें।