पासकी डे 2 की समस्याएं: लॉन्च के बाद 5 जोखिम

1. परिचय: लॉन्च के बाद पासकी जोखिम#

पासकी लागू न करें।

कम से कम हर कीमत पर नहीं और यदि आपके पास इसे ठीक से करने के लिए संसाधन नहीं हैं तो बिलकुल नहीं।

हां, पासकी पिछले एक दशक में कंज्यूमर ऑथेंटिकेशन के साथ होने वाली सबसे अच्छी चीज है। हां, वे फ़िशिंग को खत्म करते हैं। हां, वे UX को व्यापक रूप से सुधार सकते हैं। लेकिन गलत तरीके से लागू की गई पासकी बहुत नुकसान भी पहुंचा सकती है।

WebAuthn सर्वर को लागू करना बहुत जटिल नहीं है। वास्तविक चुनौती इसके आस-पास की हर चीज है। पासकी को बड़े पैमाने पर कुशलता से संचालित करने के लिए आगे की योजना बनाने की आवश्यकता है। आपको सभी "डे 2" समस्याओं के बारे में सोचना होगा - वे ऑपरेशनल वास्तविकताएं जो आपके द्वारा पासकी रोलआउट शुरू करने के बाद ही सामने आती हैं।

यह लेख पांच डे 2 समस्याओं को कवर करता है जो लगातार पासकी प्रोजेक्ट्स को विफल करती हैं। यदि आप उन सभी को हल नहीं कर सकते हैं, तो आप पासकी शिप करने के लिए तैयार नहीं हैं। यदि आप कर सकते हैं, तो आप ऐसा ऑथेंटिकेशन बनाएंगे जो पासवर्ड की पेशकश से कहीं अधिक सुरक्षित और उपयोग करने में आसान होगा।

2. पासकी डे 2 समस्याएं क्या हैं?#

इंजीनियरिंग में, "डे 1" वह समय होता है जब आप निर्माण और शिप करते हैं। "डे 2" वह समय होता है जब आप अपने द्वारा शिप की गई चीज़ों को संचालित करते हैं, बनाए रखते हैं और स्केल करते हैं। पासकी के लिए, डे 1 सीधा हो सकता है:

• अपने एंटरप्राइज़ स्टैक में एक WebAuthn सर्वर को एकीकृत करें
• फ्रंटएंड फ्लो जोड़ें और लॉन्च करें।

अधिकांश टीमें कुछ दिनों या हफ्तों में एक बुनियादी पासकी कार्यान्वयन चला सकती हैं।

डे 2 वह जगह है जहां प्रोजेक्ट्स विफल हो जाते हैं। यह वह क्षण है जब वास्तविक डिवाइस पर वास्तविक किनारे के मामलों (edge cases) वाले वास्तविक यूज़र आपके पासकी सिस्टम के साथ इंटरैक्ट करते हैं। यह तब होता है जब आपको पता चलता है कि आपके मैकबुक पर पूरी तरह से काम करने वाला चमकदार डेमो कॉर्पोरेट प्रॉक्सी के पीछे क्रोम चलाने वाले विंडोज लैपटॉप पर टूट जाता है। यह तब होता है जब आपकी सपोर्ट टीम "मैं अब लॉग इन नहीं कर सकता" टिकटों से भर जाती है।

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

3. समस्या 1: रिकवरी और फॉलबैक को सुरक्षित करना कठिन है#

यदि आप रिकवरी और फॉलबैक को ठीक से डिज़ाइन नहीं करते हैं, तो आप या तो बड़े पैमाने पर यूज़र्स को लॉक आउट कर देते हैं या आप चुपचाप उन्हीं फ़िशिंग-संभावित फ्लो को फिर से पेश कर देते हैं जिन्हें आप समाप्त करना चाहते थे।

3.1 बड़े पैमाने पर अकाउंट लॉकआउट जोखिम#

उस यूज़र पर विचार करें जो अपने iPhone पर एक पासकी रजिस्टर करता है, फिर उस iPhone को खो देता है। आमतौर पर, इन रिकवरी मामलों का एक बड़ा हिस्सा अब क्रेडेंशियल मैनेजर (ज्यादातर iPhones पर iCloud Keychain) द्वारा संभाला जा रहा है। जब तक यूज़र के पास अपने Apple अकाउंट तक पहुंच है, तब तक उनके पास नए डिवाइस पर लॉग इन करने के लिए सिंक की गई पासकी उपलब्ध है। लेकिन क्या होगा यदि उनके पास अब उस क्लाउड अकाउंट तक पहुंच नहीं है? यहीं पर आपका नियमित रिकवरी पथ काम आता है।

मान लें कि आप मानते हैं कि निजी कुंजी अभी भी उस डिवाइस पर उपलब्ध है जिससे यूज़र लॉग इन करने का प्रयास करता है, इसलिए आप WebAuthn लॉगिन सेरेमनी शुरू करते हैं। इसका परिणाम यह होगा कि OS / ब्राउज़र मॉडल यूज़र से "किसी अन्य डिवाइस पर अपनी पासकी के साथ लॉग इन करें" के लिए कहेगा। मूल रूप से, यूज़र अब अपने अकाउंट से लॉक आउट हो गया है। ऐसा कोई अन्य डिवाइस नहीं है जहां पासकी स्टोर की गई हो। यूज़र बहुत भ्रमित है। इसे हजारों यूज़र्स से गुणा करें और आपके पास एक सपोर्ट संकट है।

आम प्रतिक्रिया फॉलबैक के रूप में ईमेल-आधारित अकाउंट रीसेट को जोड़ना है। लेकिन यह पासकी के उद्देश्य को विफल कर देता है: आपने अभी-अभी एक फ़िशिंग योग्य रिकवरी चैनल फिर से पेश किया है। एक हमलावर जो किसी यूज़र के ईमेल से समझौता कर सकता है, वह अब आपके फ़िशिंग-प्रतिरोधी पासकी कार्यान्वयन को पूरी तरह से बायपास कर सकता है।

3.2 फ़िशिंग को फिर से पेश किए बिना फॉलबैक डिज़ाइन करना#

हमारी राय में, सही दृष्टिकोण लेयर्ड रिकवरी है:

1. प्राथमिक रणनीति के रूप में सिंक की गई पासकी: सुनिश्चित करें कि यूज़र सिंक की गई पासकी (iCloud Keychain, Google Password Manager या किसी थर्ड-पार्टी पासकी प्रदाता के माध्यम से) बनाते हैं ताकि डिवाइस के नुकसान का मतलब क्रेडेंशियल का नुकसान न हो
2. दूसरी लेयर के रूप में क्रॉस-डिवाइस ऑथेंटिकेशन: यूज़र्स को किसी अन्य डिवाइस से ऑथेंटिकेट करने की अनुमति दें जहां QR कोड स्कैन करके कोई अन्य पासकी उपलब्ध हो
3. तीसरी लेयर के रूप में आइडेंटिटी वेरिफिकेशन (IDV): पासवर्ड/OTP पर वापस जाने के बजाय लाइवनेस चेक के साथ ऑटोमेटेड IDV प्रदान करें।
4. चौथी लेयर के रूप में डिजिटल वेरिफ़िएबल क्रेडेंशियल्स: यह अकाउंट रिकवरी का सबसे सुरक्षित, प्राइवेसी-संरक्षित और UX-अनुकूल संस्करण है। यह यूज़र को मानक API (जैसे Digital Credentials API) का उपयोग करके अपनी पहचान सत्यापित करने के लिए अपने डिजिटल वेरिफ़िएबल क्रेडेंशियल्स (जैसे डिजिटल नेशनल ID या mDL) का उपयोग करने की अनुमति देता है। यह तकनीक काफी नई है और अडॉप्शन अधिक नहीं है लेकिन यह आने वाले महीनों और वर्षों में एक प्रमुख भूमिका निभाएगी।

सामान्य तौर पर, आपको यह तय करने की आवश्यकता है कि अकाउंट रिकवरी की कौन सी लेयर लागत / घर्षण के दृष्टिकोण से उचित ठहराई जा सकती है। उदाहरण के लिए, रिटेल / ई-कॉमर्स में, आप केवल पहली दो लेयर्स की पेशकश कर सकते हैं और वित्तीय कारणों से फ़िशिंग जोखिम को स्वीकार कर सकते हैं। अन्य उद्योगों में, जहां सुरक्षा अधिक महत्वपूर्ण है, आप लेयर 3 और 4 पर जाते हैं।

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

3.3 अधिकांश टीमें क्या गलत करती हैं#

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

4. समस्या 2: क्रॉस-डिवाइस और क्रॉस-इकोसिस्टम एज केसेस पासकी फ्लो को तोड़ देते हैं#

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

4.1 इकोसिस्टम विखंडन वास्तविक है#

पासकी इकोसिस्टम तीन प्रमुख प्लेटफॉर्म (Apple, Google और Microsoft), कई ब्राउज़रों (Chrome, Safari, Firefox और Edge), दर्जनों पासकी प्रदाताओं / क्रेडेंशियल प्रबंधकों (जैसे 1Password, Bitwarden, Dashlane और अन्य) और अनगिनत OS/ब्राउज़र/डिवाइस संयोजनों तक फैला हुआ है। प्रत्येक संयोजन थोड़ा अलग व्यवहार कर सकता है, उदा.:

• Apple डिफ़ॉल्ट रूप से iOS, iPadOS और macOS पर iCloud Keychain के माध्यम से पासकी सिंक करता है लेकिन Windows या Android पर नहीं
• Google Android और Chrome पर Google Password Manager के माध्यम से सिंक करता है लेकिन iOS पर अनुभव अलग है (आपको इसे मैन्युअल रूप से सेट अप करना होगा)
• Windows का अपना पासकी व्यवहार है जो अन्य प्लेटफॉर्म से काफी भिन्न है
• पासवर्ड प्रबंधक प्रत्येक पासकी निर्माण और चयन को अलग तरह से संभालते हैं, कभी-कभी प्लेटफॉर्म-नेटिव प्रॉम्प्ट के साथ संघर्ष करते हैं

4.2 क्रॉस-डिवाइस ऑथेंटिकेशन फ्लो#

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

• इसके लिए दोनों डिवाइस पर ब्लूटूथ का सक्षम होना आवश्यक है
• कॉर्पोरेट फायरवॉल और MDM नीतियां हस्तक्षेप कर सकती हैं क्योंकि बैकग्राउंड में एक टनल स्थापित की गई है
• UX ब्राउज़रों के बीच नाटकीय रूप से भिन्न होता है
• यूज़र्स अक्सर यह नहीं समझते कि क्या हो रहा है या वे QR कोड को स्कैन क्यों कर रहे हैं

हमने हजारों डिवाइस संयोजनों में इन एज केसेस को प्रत्यक्ष रूप से देखा है। यदि आप घर में पासकी बना रहे हैं, तो आपको उनमें से प्रत्येक का परीक्षण करने और उन्हें संभालने की आवश्यकता है। यदि आप नहीं कर सकते हैं, तो आपके यूज़र्स ऐसी त्रुटियों का सामना करेंगे जिन्हें आपकी सपोर्ट टीम समझा नहीं सकती है।

4.3 ब्राउज़र और OS विसंगतियां#

यहां तक कि एक ही डिवाइस पर, अलग-अलग ब्राउज़र अलग-अलग व्यवहार करते हैं। macOS पर Chrome macOS पर Safari की तुलना में अलग पासकी मॉडल दिखाता है। Firefox का अपना व्यवहार है। क्लाइंट हिंट और यूज़र एजेंट का पता लगाना सही यूज़र को सही फ्लो प्रदान करने के लिए महत्वपूर्ण हो जाता है लेकिन सभी संयोजनों में उन्हें सही ढंग से पार्स करना एक रखरखाव का बोझ है जो कभी समाप्त नहीं होता है।

5. समस्या 3: नेटिव ऐप्स पासकी जटिलता को बढ़ाते हैं#

वेब ऐप्स के लिए पासकी परीक्षण और QA पहले से ही एक चुनौती है (हम इसे समस्या 5: प्लेटफॉर्म में बदलाव पासकी को चुपचाप तोड़ देते हैं में विस्तार से कवर करते हैं)। लेकिन अगर आपके उत्पाद में नेटिव iOS और Android ऐप्स भी हैं, तो वास्तुकला संबंधी निर्णयों और प्लेटफॉर्म-विशिष्ट व्यवहार के कारण जटिलता बढ़ जाती है जिसका वेब-केवल टीमें कभी सामना नहीं करती हैं।

5.1 नेटिव बनाम WebView निर्णय#

पहला निर्णय यह है कि पासकी को मूल रूप से (नैटिवली) लागू किया जाए या WebView के माध्यम से। प्रत्येक दृष्टिकोण के अपने ट्रेड-ऑफ़ हैं:

अकेले iOS पर, आप WKWebView, SFSafariViewController, SFAuthenticationSession और ASWebAuthenticationSession के बीच चयन कर सकते हैं - प्रत्येक में अलग-अलग पासकी सपोर्ट विशेषताएँ हैं। Android पर, Chrome Custom Tabs मानक WebViews से अलग व्यवहार करते हैं। ये ऐसे निर्णय हैं जो वेब-केवल टीमों को कभी नहीं लेने पड़ते और प्रत्येक विकल्प अपनी खुद की रखरखाव सतह बनाता है।

5.2 नेटिव ऐप्स में प्लेटफॉर्म-विशिष्ट व्यवहार#

वास्तुकला संबंधी निर्णय से परे, iOS और Android OS स्तर पर पासकी को अलग तरह से संभालते हैं:

• iOS पासकी को सिस्टम क्रेडेंशियल मैनेजर में गहराई से एकीकृत करता है, विशिष्ट ऑटोफिल व्यवहारों के साथ जो प्रत्येक iOS संस्करण के साथ बदल सकते हैं
• Android Credential Manager API के माध्यम से पासकी अनुरोधों को रूट करता है, जो एक साथ कई पासकी प्रदाताओं के साथ इंटरैक्ट करता है
• त्रुटि अवस्थाएं, टाइमआउट व्यवहार और यूज़र प्रॉम्प्ट प्लेटफॉर्म के बीच भिन्न होते हैं। वही यूज़र कैंसल वेब पर NotAllowedError के रूप में सामने आता है, लेकिन iOS पर SimpleAuthenticationServices.AuthorizationError और Android के Credential Manager पर User cancelled the operation के रूप में - पूर्ण क्रॉस-प्लेटफॉर्म एरर मैपिंग के लिए प्रोडक्शन में WebAuthn एरर देखें
• जब आपको पासकी रिग्रेशन के लिए तत्काल सुधारों को शिप करने की आवश्यकता होती है, तो ऐप स्टोर रिव्यू साइकल देरी जोड़ते हैं

5.3 तिगुनी QA सतह#

यदि आप एक वेब ऐप और नेटिव ऐप दोनों संचालित करते हैं, तो आप न केवल QA प्रयास को दोगुना कर रहे हैं बल्कि आप इसे तीन गुना कर रहे हैं। वेब, iOS और Android प्रत्येक अलग-अलग पासकी वातावरण के रूप में व्यवहार करते हैं जिन्हें स्वतंत्र एंड-टू-एंड परीक्षण और निगरानी की आवश्यकता होती है। और वेब के विपरीत, जहां आप एक फिक्स को तुरंत तैनात कर सकते हैं, नेटिव ऐप के सुधार ऐप स्टोर रिव्यू साइकल्स द्वारा रोके जाते हैं।

6. समस्या 4: अडॉप्शन एक प्रोडक्ट समस्या है, टेक समस्या नहीं#

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

6.1 कम अडॉप्शन आपके प्रोजेक्ट को क्यों मारता है#

हमने पासकी कार्यान्वयन विफल क्यों होते हैं, इस पर अपने लेख में इसे बड़े पैमाने पर कवर किया है: यदि यूज़र्स पासकी पर स्विच नहीं करते हैं, तो प्रोजेक्ट पहले ही विफल हो चुका है। पासवर्ड हावी रहते हैं, SMS OTP लागत अधिक रहती है, फ़िशिंग जोखिम बने रहते हैं और आपके संगठन को महत्वपूर्ण इंजीनियरिंग निवेश पर कोई रिटर्न नहीं मिलता है।

पासकी अडॉप्शन के लिए बिज़नेस केस मजबूत है लेकिन केवल तभी जब अडॉप्शन वास्तव में होता है। हमने ऐसे उद्यमों को बेहतरीन तकनीकी कार्यान्वयन के साथ पासकी लॉन्च करते देखा है जिन्होंने 5% से कम अडॉप्शन हासिल किया क्योंकि किसी ने भी रोलआउट और अडॉप्शन रणनीति के बारे में नहीं सोचा।

6.2 अडॉप्शन के लिए विचारशील प्रोडक्ट कार्य की आवश्यकता होती है#

पासकी अडॉप्शन को बढ़ावा देना एक प्रोडक्ट चुनौती है जिसके लिए निम्नलिखित की आवश्यकता होती है:

• प्रोग्रेसिव एनरोलमेंट: यूज़र्स को सही समय पर पासकी बनाने के लिए प्रेरित करना (उदा. सफल लॉगिन के बाद, अकाउंट सिक्योरिटी रिव्यू के दौरान)
• स्पष्ट यूज़र कम्युनिकेशन: यह समझाना कि पासकी क्या हैं और वे बेहतर क्यों हैं, ऐसी भाषा में जिसे गैर-तकनीकी यूज़र्स समझते हों
• डिवाइस-अवेयर प्रॉम्प्टिंग: केवल तभी पासकी निर्माण की पेशकश करना जब यूज़र का डिवाइस वास्तव में इसका अच्छी तरह से समर्थन करता हो, असमर्थित कॉन्फ़िगरेशन पर निराशाजनक अनुभवों से बचना
• माप का बुनियादी ढांचा: अड़चनों को पहचानने और ठीक करने के लिए पासकी निर्माण दर, लॉगिन सफलता दर, फॉलबैक दर और परित्याग दर को ट्रैक करना

6.3 "अच्छा" अडॉप्शन कैसा दिखता है#

बड़े पैमाने पर पासकी डिप्लॉयमेंट के हमारे अनुभव के आधार पर, यहां बताया गया है कि एंटरप्राइज़ को क्या लक्ष्य रखना चाहिए:

यदि आपके अडॉप्शन के आंकड़े तीन महीनों के बाद "कमज़ोर" कॉलम की तरह दिखते हैं, तो प्रोजेक्ट संकट में है। इसे मापने के लिए एनालिटिक्स के बिना, आपको पता भी नहीं चलेगा।

7. समस्या 5: प्लेटफॉर्म में बदलाव पासकी को चुपचाप तोड़ देते हैं#

OS और ब्राउज़र अपडेट प्रॉम्प्ट, ऑटोफ़िल व्यवहार और फॉलबैक फ़्लो को बदल देते हैं। यदि आपके पास चल रही निगरानी नहीं है, तो आपको बिना किसी चेतावनी के रिग्रेशन और सपोर्ट टिकट मिलेंगे।

हमने हाल ही में प्रोडक्शन में होने वाली WebAuthn एरर का एक व्यापक अवलोकन प्रकाशित किया है।

7.1 प्लेटफॉर्म में बदलाव से पासकी विशिष्ट रूप से क्यों प्रभावित होती हैं#

पासवर्ड (जो केवल स्ट्रिंग्स हैं जिन्हें आपका सर्वर मान्य करता है) के विपरीत, पासकी ऑपरेटिंग सिस्टम, ब्राउज़र और क्रेडेंशियल मैनेजर के साथ गहरे एकीकरण पर निर्भर करती हैं। जब Apple एक नया iOS संस्करण भेजता है, तो पासकी निर्माण प्रॉम्प्ट अलग दिख सकते हैं। जब Chrome अपने ऑटोफ़िल लॉजिक को अपडेट करता है, तो आपका लॉगिन फ़्लो टूट सकता है। जब कोई पासवर्ड मैनेजर नया संस्करण जारी करता है, तो यह पासकी अनुरोधों को ऐसे तरीकों से रोकना शुरू कर सकता है जिनका आपने अनुमान नहीं लगाया था।

एक हालिया उदाहरण iOS 26.2 बग है जहां isUserVerifyingPlatformAuthenticatorAvailable() सभी गैर-सफारी ब्राउज़रों (Chrome, Edge, Firefox) पर false लौटाता है, जिसके लिए एक वर्कअराउंड के रूप में getClientCapabilities() का उपयोग करते हुए प्लेटफॉर्म-अवेयर डिटेक्शन लॉजिक की आवश्यकता होती है।

7.2 निगरानी वैकल्पिक नहीं है#

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

• रियल-टाइम ऑथेंटिकेशन एनालिटिक्स: OS, ब्राउज़र और पासकी प्रदाता संयोजन द्वारा सफलता और विफलता दरों को ट्रैक करें
• वर्ज़न-अवेयर निगरानी: पता लगाएं कि कब कोई नया OS या ब्राउज़र संस्करण एरर या फॉलबैक में वृद्धि का कारण बनता है। अपेक्षित एरर (NotAllowedError के रूप में सामने आने वाले यूज़र एबॉर्ट्स) और अनपेक्षित एरर (समवर्ती बग से AbortError स्पाइक्स या Android अपडेट के बाद नए Credential Manager पासकी एरर) के बीच अंतर करें
• अलर्टिंग: अपने यूज़र्स द्वारा सपोर्ट टिकट दर्ज करना शुरू करने से पहले सूचित हो जाएं
• रैपिड रिस्पॉन्स क्षमता: प्रभावित डिवाइस संयोजनों के लिए त्वरित रूप से फिक्स पुश करने या पासकी को अक्षम करने की क्षमता

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

7.3 चल रही रखरखाव लागत#

पासकी कार्यान्वयन की सही लागत प्रारंभिक निर्माण नहीं है। यह चल रहा रखरखाव है:

• iOS, Android, Windows, macOS और सभी प्रमुख ब्राउज़रों में प्लेटफॉर्म परिवर्तनों की निगरानी
• रिग्रेशन के लिए प्रत्येक अपडेट का परीक्षण
• जब ब्राउज़र API बदलते हैं तो आपके फ्रंटएंड SDK को अपडेट करना
• पासकी प्रदाताओं के बढ़ते इकोसिस्टम के साथ अनुकूलता बनाए रखना
• आपकी सपोर्ट टीम में बदलावों का दस्तावेजीकरण और संचार करना

8. आपको पासकी कब (नहीं) शिप करनी चाहिए#

इन डे 2 समस्याओं को देखते हुए, यहां एक ईमानदार मूल्यांकन है कि आपको कब पासकी शिप करनी चाहिए और कब नहीं।

8.1 पासकी शिप न करें यदि#

• आपके पास एक स्पष्ट फॉलबैक और रिकवरी रणनीति नहीं है
• आपने उन डिवाइस संयोजनों का परीक्षण नहीं किया है जिनका उपयोग आपके यूज़र्स वास्तव में करते हैं
• आपके पास नेटिव ऐप्स हैं लेकिन चल रहे प्लेटफॉर्म-विशिष्ट QA के लिए कोई योजना नहीं है
• आपके पास अडॉप्शन मापने के लिए एनालिटिक्स इंफ्रास्ट्रक्चर नहीं है
• आप चल रहे रखरखाव के लिए इंजीनियरिंग संसाधनों को प्रतिबद्ध नहीं कर सकते हैं
• आप उचित योजना के बिना पूरी तरह से अनुपालन चेकबॉक्स के लिए पासकी लागू कर रहे हैं

उचित योजना के बिना विनियामक कारणों से ऑल-इन जाना लागत को महत्वपूर्ण रूप से बढ़ा सकता है। एक खराब तरीके से लागू किया गया पासकी सिस्टम बिना पासकी सिस्टम के होने से भी बदतर है: यह यूज़र के भरोसे को कम करता है, सपोर्ट ओवरहेड उत्पन्न करता है और आंतरिक हितधारकों को प्रोजेक्ट को खत्म करने का कारण देता है।

8.2 पासकी शिप करें यदि#

• आपने ऊपर वर्णित सभी पांच डे 2 समस्याओं के लिए योजना बनाई है
• आपके पास चल रहे रोलआउट का समर्थन करने के लिए उत्पाद, इंजीनियरिंग, सुरक्षा और एनालिटिक्स क्षमताएं हैं
• आपने निरंतर रखरखाव के लिए बजट बनाया है, न कि केवल प्रारंभिक निर्माण के लिए
• आपके पास स्पष्ट अडॉप्शन लक्ष्यों के साथ एक चरणबद्ध रोलआउट रणनीति है
• आप Corbado जैसे पार्टनर के साथ काम कर रहे हैं जो आपके लिए ऑपरेशनल जटिलता को संभालता है

8.3 निर्माण बनाम खरीदें निर्णय#

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

9. Corbado पासकी डे 2 की समस्याओं को कैसे हल करता है#

Corbado विशेष रूप से इसलिए मौजूद है क्योंकि डे 2 की समस्याएं कठिन हैं। हमारा प्लेटफॉर्म ऑपरेशनल जटिलता को संभालता है ताकि आपको इसे स्वयं बनाने और बनाए रखने की आवश्यकता न हो।

9.1 रिकवरी और फॉलबैक#

Corbado अनुकूली सुरक्षा स्तरों के साथ आउट-ऑफ़-द-बॉक्स रिकवरी फ़्लो प्रदान करता है। सिंक की गई पासकी रणनीतियों से लेकर क्रॉस-डिवाइस ऑथेंटिकेशन से लेकर ऑटोमेटेड आइडेंटिटी वेरिफिकेशन तक। रिकवरी लॉजिक इन-बिल्ट है और इसे लगातार अपडेट किया जाता है।

9.2 क्रॉस-डिवाइस कम्पैटिबिलिटी#

हमारे फ्रंटएंड SDK को हज़ारों OS, ब्राउज़र और पासकी प्रदाता संयोजनों में पूर्व-परीक्षण किया गया है। डिवाइस डिटेक्शन, कंडीशनल UI हैंडलिंग और फॉलबैक रूटिंग स्वचालित रूप से होती है। जब कोई नया ब्राउज़र संस्करण कुछ तोड़ता है, तो आपके यूज़र्स के ध्यान देने से पहले ही हम इसे अपने SDK में ठीक कर देते हैं।

9.3 नेटिव ऐप सपोर्ट#

Corbado SDK के साथ नेटिव और WebView पासकी कार्यान्वयन दोनों का समर्थन करता है जो प्लेटफॉर्म के अंतर को अलग करते हैं। आप अपने ऐप के UX पर ध्यान केंद्रित करते हैं जबकि हम iOS और Android पर पासकी प्लंबिंग को संभालते हैं।

9.4 अडॉप्शन एनालिटिक्स#

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

9.5 प्लेटफॉर्म चेंज मॉनिटरिंग#

Corbado लगातार OS और ब्राउज़र में बदलावों की निगरानी करता है जो पासकी को प्रभावित करते हैं। हमारे SDK को प्रोएक्टिव रूप से अपडेट किया जाता है। आपका पासकी डिप्लॉयमेंट तब भी स्थिर रहता है जब इसके नीचे का प्लेटफॉर्म परिदृश्य बदलता है।

10. निष्कर्ष#

पासकी ऑथेंटिकेशन का स्वर्ण मानक हैं। इस पर कोई सवाल नहीं है। लेकिन "पासकी सपोर्टेड" से "बड़े पैमाने पर मज़बूती से काम कर रही पासकी" तक का रास्ता डे 2 की समस्याओं से पक्का है जिसे अधिकांश टीमें कम आंकती हैं।

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

मेरी ईमानदार सिफारिश: यदि आपके पास पासकी को ठीक से करने के लिए जानकारी और संसाधन नहीं हैं, तो उन्हें शिप न करें। या तो क्षमता (उत्पाद, इंजीनियरिंग, सुरक्षा और एनालिटिक्स) में निवेश करें या ऐसे पार्टनर के साथ काम करें जिसने इन समस्याओं को पहले ही हल कर लिया है। सबसे बुरा परिणाम एक आधा-पका पासकी डिप्लॉयमेंट है जिसे वापस ले लिया जाता है क्योंकि किसी ने डे 2 के लिए योजना नहीं बनाई थी।

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 विशेषज्ञ से बात करें →

अक्सर पूछे जाने वाले प्रश्न#

लॉन्च के बाद पासकी प्रोजेक्ट्स को विफल करने वाली 5 डे 2 समस्याएं क्या हैं?#

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

मैं Windows पर उन एंटरप्राइज़ यूज़र्स के लिए क्रॉस-डिवाइस पासकी ऑथेंटिकेशन को कैसे संभाल सकता हूं जिन्होंने iPhone पर रजिस्टर किया है?#

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

लॉन्च के बाद मुझे किन पासकी अडॉप्शन मेट्रिक्स को लक्षित और ट्रैक करना चाहिए?#

मजबूत अडॉप्शन का अर्थ है योग्य यूज़र्स के 60% से ऊपर पासकी निर्माण दर और सभी लॉगिन के 40% से ऊपर पासकी लॉगिन दर। तीन महीनों के बाद 10% निर्माण और 5% से कम लॉगिन दरें एक विफल रोलआउट का संकेत देती हैं। इसे मापने के लिए समर्पित बुनियादी ढांचे की आवश्यकता होती है जो निर्माण दरों, लॉगिन सफलता दरों, फॉलबैक दरों और डिवाइस और OS संयोजन द्वारा तोड़े गए परित्याग को ट्रैक करता है।

क्या मुझे अपने मोबाइल ऐप में मूल रूप से (नैटिवली) पासकी बनानी चाहिए या WebView का उपयोग करना चाहिए?#

नेटिव कार्यान्वयन सर्वश्रेष्ठ-इन-क्लास UX प्रदान करता है लेकिन इसके लिए प्लेटफॉर्म-विशिष्ट API हैंडलिंग और स्वतंत्र QA पाइपलाइनों के साथ अलग iOS और Android कोडबेस की आवश्यकता होती है। WebView दृष्टिकोण वेब लॉजिक साझा करते हैं लेकिन WebView प्रकार के आधार पर पासकी सपोर्ट विसंगतियां पेश करते हैं। अकेले iOS पर, WKWebView, SFSafariViewController और ASWebAuthenticationSession के बीच चयन प्रत्येक में अलग-अलग पासकी सपोर्ट विशेषताएं हैं जिनका मूल्यांकन वास्तुकला के लिए प्रतिबद्ध होने से पहले किया जाना चाहिए।

पासकी अकाउंट रिकवरी जितना दिखता है उससे कहीं अधिक कठिन क्यों है और सही दृष्टिकोण क्या है?#

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