नेटिव ऐप पासकीज़: नेटिव बनाम वेबव्यू कार्यान्वयन

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

एक नेटिव कार्यान्वयन को अक्सर एक ऐप के भीतर सबसे अच्छा उपयोगकर्ता अनुभव प्रदान करने वाला माना जाता है। इसकी विशेषता इसके सहज, एकीकृत और सामंजस्यपूर्ण उपयोगकर्ता इंटरैक्शन हैं, जो ऑपरेटिंग सिस्टम के वातावरण के लिए सटीक रूप से तैयार किए गए हैं, चाहे वह iOS हो या Android। 100% नेटिव कार्यान्वयन की आवश्यकता 100% पासवर्ड रहित होना और वास्तव में पासकी-नेटिव होना है। यह दृष्टिकोण आपको नेटिव ऐप और वेब सामग्री (एक वेबव्यू के माध्यम से प्रदर्शित) के बीच संक्रमण के संभावित घर्षण से मुक्त करता है।

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

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

इस लेख के अगले खंड वेबव्यू के माध्यम से कार्यान्वयन पर ध्यान केंद्रित करते हैं। नेटिव पासकी एकीकरण के बारे में अधिक जानने के लिए, कृपया यहाँ देखें।

नेटिव ऐप्स में प्रमाणीकरण की भूलभुलैया से गुजरते हुए, डेवलपर्स और उत्पाद प्रबंधकों को एक महत्वपूर्ण निर्णय का सामना करना पड़ता है: पासकी प्रमाणीकरण को नेटिव रूप से या वेबव्यू के माध्यम से लागू करना। यदि बाद वाले के लिए निर्णय लिया जाता है, तो iOS और Android दोनों प्लेटफ़ॉर्म दो अलग-अलग प्रकार के वेबव्यू प्रदान करते हैं, प्रत्येक अपनी अनूठी विशेषताओं और संभावित उपयोग के मामलों के साथ।

• WKWebView
• SFSafariViewController
• SFAuthenticationSession / ASWebAuthenticationSession (विशेष रूप से OAuth / OpenID Connect-आधारित प्रमाणीकरण प्रवाह के लिए तैयार)

• WebView
• Chrome Custom Tabs (CCT)

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

iOS वेबव्यू या तो WKWebView या SFSafariViewController हैं (यदि OAuth / OIDC के साथ काम कर रहे हैं, तो यह SFAuthenticationSession / ASWebAuthenticationSession है)।

iOS में विभिन्न वेबव्यू व्यवहार का परीक्षण करने के लिए, हम ऐप WebView - WKWebView and UIWebView rendering की अनुशंसा करते हैं।

WKWebView iOS डेवलपर्स के लिए उपलब्ध एक शक्तिशाली और बहुमुखी वेबव्यू विकल्प है। iOS 8 के साथ पेश किया गया, यह डेवलपर्स को एक ऐप के भीतर सीधे वेब सामग्री एम्बेड करने की अनुमति देता है, जो अनुकूलन और कॉन्फ़िगरेशन विकल्पों की एक विस्तृत श्रृंखला प्रदान करता है। WKWebView अपने प्रदर्शन के लिए प्रसिद्ध है, जो Safari के समान वेब रेंडरिंग इंजन का उपयोग करता है, और वेब सामग्री के साथ बातचीत करने, नेविगेशन, उपयोगकर्ता इंटरैक्शन और बहुत कुछ प्रबंधित करने के लिए APIs का एक समृद्ध सेट प्रदान करता है।

SFSafariViewController एक वेबव्यू है जो डेवलपर्स को अपने ऐप्स के भीतर सीधे Safari की क्षमताओं का लाभ उठाने की अनुमति देता है। यह उपयोगकर्ता की Safari सेटिंग्स, जैसे सहेजे गए पासवर्ड, पासकीज़, कुकीज़, और बहुत कुछ का उपयोग करके एक सहज उपयोगकर्ता अनुभव प्रदान करता है, जो लगातार वेब ब्राउज़िंग सुनिश्चित करता है, क्योंकि यह वास्तव में Safari एप्लिकेशन के रूप में चलता है। SFSafariViewController WKWebView जितना अनुकूलन योग्य नहीं है, लेकिन यह बढ़ी हुई सुरक्षा सुविधाएँ और उपयोग में आसानी प्रदान करता है, जिससे यह ऐप्स के भीतर सीधी वेब सामग्री प्रदर्शित करने के लिए एक पसंदीदा विकल्प बन जाता है।

SFAuthenticationSession और ASWebAuthenticationSession वेबव्यू हैं जो विशेष रूप से OAuth / OpenID Connect-आधारित प्रमाणीकरण प्रवाह के लिए तैयार किए गए हैं। वे उपयोगकर्ता प्रमाणीकरण के लिए एक सुरक्षित और पृथक स्थान प्रदान करते हैं, उपयोगकर्ता क्रेडेंशियल्स की सुरक्षा करते हैं और यह सुनिश्चित करते हैं कि निजी जानकारी अनजाने में ऐप के साथ साझा न हो। ये सत्र Safari के साथ कुकीज़ और वेबसाइट डेटा साझा करते हैं, एक सुसंगत और सहज उपयोगकर्ता अनुभव प्रदान करते हैं, खासकर प्रमाणीकरण प्रक्रियाओं के दौरान।

फायदे:

• समर्पित प्रमाणीकरण: विशेष रूप से OAuth / OpenID Connect-आधारित प्रमाणीकरण प्रवाह के लिए डिज़ाइन किया गया है, जो एक सुव्यवस्थित प्रमाणीकरण प्रक्रिया सुनिश्चित करता है।
• गोपनीयता संरक्षण: ऐप के साथ कुकीज़ या वेबसाइट डेटा साझा न करके उपयोगकर्ता डेटा गोपनीयता सुनिश्चित करता है।
• SSO समर्थन: सिंगल साइन-ऑन का समर्थन करता है, एक सुविधाजनक उपयोगकर्ता अनुभव प्रदान करता है।

नुकसान:

• सीमित उपयोग का मामला: मुख्य रूप से OAuth / OpenID Connect प्रमाणीकरण पर केंद्रित है, जो सभी उपयोग के मामलों के लिए उपयुक्त नहीं हो सकता है।

जब प्राथमिक कार्य उपयोगकर्ता प्रमाणीकरण है, विशेष रूप से SSO को लागू करते समय या OAuth प्रदाताओं के साथ बातचीत करते समय, आपको SFSafariViewController के बजाय SFAuthenticationSession / ASWebAuthenticationSession का उपयोग करना चाहिए।

Android वेबव्यू या तो WebView या Chrome Custom Tabs (CCT) हैं। Android में विभिन्न वेबव्यू व्यवहार का परीक्षण करने के लिए, हम ऐप WebView vs Chrome Custom Tabs की अनुशंसा करते हैं।

Android पर WebView एक व्यापक घटक है जो डेवलपर्स को ऐप्स UI के हिस्से के रूप में वेब सामग्री प्रदर्शित करने की अनुमति देता है। यह बहुमुखी है, जो अनुकूलन विकल्पों की एक विस्तृत श्रृंखला प्रदान करता है और डेवलपर्स को विभिन्न आवश्यकताओं के अनुरूप वेबव्यू को कॉन्फ़िगर करने की सुविधा प्रदान करता है। WebView वेब सामग्री के साथ बातचीत करने, उपयोगकर्ता इंटरैक्शन को प्रबंधित करने और यहां तक कि जावास्क्रिप्ट संवाद, क्लाइंट प्रमाणपत्र और अनुमति अनुरोधों को संभालने के लिए APIs का एक समृद्ध सेट प्रदान करता है।

Chrome Custom Tabs (CCT) आपके ऐप में सीधे वेब सामग्री को एकीकृत करने का एक सहज, सुरक्षित और कुशल तरीका प्रदान करता है। Chrome की क्षमताओं और सुरक्षा सुविधाओं का लाभ उठाकर, CCT एक उपयोगकर्ता अनुभव प्रदान करता है जो सुसंगत और उच्च-प्रदर्शन दोनों है।

CCT Chrome ब्राउज़र का एक घटक है, जिसे Android ढांचे के साथ एकीकृत करने के लिए डिज़ाइन किया गया है, जो ऐप्स को एक हल्के, समर्पित प्रक्रिया में वेब सामग्री खोलने की अनुमति देता है। विशेष रूप से, यह एक पारंपरिक ब्राउज़र की तुलना में तेज़ी से खुलता है और, जब इसकी वार्म-अप कॉल के माध्यम से प्रीलोड किया जाता है, तो संभावित रूप से एक वेबव्यू से बेहतर प्रदर्शन करता है। जबकि यह जावास्क्रिप्ट निष्पादित करता है, यह अपनी प्रक्रिया में काम करता है, ऐप्स को दुर्भावनापूर्ण कोड चलाने से बचाता है। इसके अलावा, CCTs UI एक एक्शन बार प्रदान करता है, जो URL और सुरक्षित पृष्ठों के लिए एक SSL सत्यापन लॉक आइकन प्रदर्शित करता है, जिससे उपयोगकर्ताओं को लोड किए जा रहे पृष्ठ की प्रामाणिकता और सुरक्षा का आश्वासन मिलता है।

सामान्य तौर पर, कोई यह कह सकता है कि iOS WKWebView और Android WebView, साथ ही SFSafariViewController और Chrome Custom Tabs (CCT) समान हैं।

हमारे ग्राहक लगातार हमसे पूछते हैं कि नेटिव ऐप्स में पासकीज़ को कैसे लागू किया जाना चाहिए। मोटे तौर पर उन ग्राहकों को विभिन्न समूहों में विभाजित किया जा सकता है:

समूह A:

वे ग्राहक जो अपने नेटिव ऐप को स्क्रैच से बनाना शुरू करते हैं और सीधे हमारे पासवर्ड रहित प्रमाणीकरण का उपयोग कर सकते हैं (कोई पुराना पासवर्ड मौजूद नहीं है)।

समूह B:

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

1. अपने मौजूदा वेबव्यू प्रमाणीकरण प्रवाह में पासकीज़ जोड़ें (इसी तरह Google और GitHub ने इसे अपने नेटिव ऐप्स में लागू किया है)
2. शीर्ष पर नेटिव कार्यान्वयन के माध्यम से पासकीज़ जोड़ें। यह नेटिव पासकी कार्यान्वयन पुराने वेबव्यू (जैसे सामाजिक लॉगिन और पासवर्ड के लिए) से पहले जांचता है कि क्या उपयोगकर्ता पासकी के साथ लॉगिन कर सकता है (इसी तरह KAYAK ने इसे अपने नेटिव ऐप में लागू किया है)।

अपना समूह निर्धारित करें

अपने उपयोगकर्ताओं को एक नेटिव ऐप में सर्वश्रेष्ठ पासकी कार्यान्वयन प्रदान करने के लिए, आपको यह तय करने की आवश्यकता है कि आप किस समूह से संबंधित हैं, जो आपके वर्तमान तकनीकी सेटअप और आप पासकीज़ को कैसे आगे बढ़ाना चाहते हैं (यह प्रश्न समूह B की कंपनियों के लिए प्रासंगिक है) पर आधारित है।

समूह A के लिए सिफारिश: नेटिव कार्यान्वयन

यदि आप पूरी तरह से एक नया ऐप (समूह A) बना रहे हैं, तो हम एक नेटिव पासकी कार्यान्वयन के साथ जाने और तुरंत पूरी तरह से पासवर्ड रहित होने की सलाह देते हैं (इसलिए किसी भी प्रकार के वेबव्यू का उपयोग नहीं किया जाता है)। कृपया iOS और Android के लिए नेटिव SDKs और APIs का उपयोग करें (उदाहरण के लिए, पासकीज़ फ़्लटर पैकेज के माध्यम से)। कृपया Relying Party IDs के बारे में यह लेख भी पढ़ें।

समूह B के लिए सिफारिश: पहले वेबव्यू, फिर नेटिव कार्यान्वयन

यदि आप आज किसी भी कारण से नेटिव रूप से पासकीज़ लागू नहीं कर सकते हैं (समूह B), तो आप एक वेबव्यू कार्यान्वयन के साथ शुरू कर सकते हैं और फिर भविष्य में एक नेटिव पासकी कार्यान्वयन में भी जा सकते हैं (यह एसोसिएशन फ़ाइलों के निर्माण के माध्यम से काम करता है, जैसे iOS ऐप्स के लिए apple-app-site-association और Android ऐप्स के लिए assetlinks.json)। वेबव्यू कार्यान्वयन के साथ जाने के कारणों में शामिल हो सकते हैं:

• आप पहले से ही OAuth2-आधारित प्रमाणीकरण प्रदान करते हैं और इसे अपने उपयोगकर्ताओं को प्रदान करना जारी रखना चाहते हैं (OAuth2 नेटिव रूप से काम नहीं करता है, मानक यहाँ देखें)
• आप उसी विंडो / स्क्रीन में पासकी प्रमाणीकरण की पेशकश करना चाहते हैं, जहाँ आप अपने अन्य प्रमाणीकरण तरीकों (जैसे पासवर्ड, सामाजिक लॉगिन, OAuth2) की पेशकश करते हैं

यह वह तरीका है जिससे Google या GitHub ने वर्तमान में अपने नेटिव ऐप्स में पासकी प्रमाणीकरण लागू किया है। पासकी प्रमाणीकरण के लिए वेबव्यू को सही ढंग से स्थापित करने के लिए कृपया नीचे दी गई सिफारिश देखें। हालांकि, हम KAYAK की तरह एक नेटिव पासकी कार्यान्वयन पर विचार करने और सीधे चरण 2 से शुरू करने की सलाह देते हैं।

यदि आप समूह B से संबंधित हैं और नेटिव रूप से पासकीज़ लागू नहीं कर सकते हैं, तो हमारी सिफारिश iOS के लिए SFAuthenticationSession / ASWebAuthenticationSession और Android के लिए Chrome Custom Tabs का उपयोग करने की ओर झुकती है (अन्यथा पासकीज़ वैसे भी काम नहीं करेंगी)।

निम्नलिखित में, हम इस सिफारिश के कारण बताते हैं:

SFAuthenticationSession / ASWebAuthenticationSession Safari के साथ कुकीज़ और वेबसाइट डेटा साझा करते हैं, जो प्रमाणीकरण प्रक्रियाओं के दौरान एक सहज उपयोगकर्ता अनुभव प्रदान करते हैं। यही बात Android पर Chrome Custom Tabs के लिए भी लागू होती है।

उपयोगकर्ताओं को ब्राउज़र में उनके सहेजे गए पासवर्ड, ऑटो-फिल डेटा और अन्य संग्रहीत जानकारी से लाभ होता है, जिससे प्रमाणीकरण प्रक्रिया आसान और तेज़ हो जाती है।

iOS पर SFAuthenticationSession / ASWebAuthenticationSession और Android पर Chrome Custom Tabs उपयोगकर्ता प्रमाणीकरण के लिए एक सुरक्षित और पृथक स्थान प्रदान करते हैं, यह सुनिश्चित करते हुए कि संवेदनशील उपयोगकर्ता क्रेडेंशियल्स सुरक्षित हैं और अनजाने में ऐप या अन्य वेबसाइटों के साथ साझा नहीं किए जाते हैं।

वे Apple और Google के कड़े सुरक्षा प्रोटोकॉल का पालन करते हैं, यह सुनिश्चित करते हुए कि उपयोगकर्ता डेटा सुरक्षित रूप से संभाला जाता है और गोपनीयता बनाए रखी जाती है।

इसके अलावा, यह डिज़ाइन विकल्प Safari और Chrome के चल रहे सुरक्षा अपडेट और संवर्द्धन से लाभान्वित होता है, यह सुनिश्चित करता है कि यह नवीनतम सुरक्षा मानकों और प्रोटोकॉल का पालन करता है।

iOS पर SFAuthenticationSession / ASWebAuthenticationSession और Android पर Chrome Custom Tabs एक सुसंगत और परिचित उपयोगकर्ता इंटरफ़ेस प्रदान करते हैं, क्योंकि उपयोगकर्ता ब्राउज़र के उपयोगकर्ता अनुभव के आदी हैं। इसके अलावा, Safari और Chrome की उपयोगकर्ता सेटिंग्स और प्राथमिकताएँ लागू होती हैं।

यह ऐप सामग्री और वेब सामग्री के बीच एक सहज संक्रमण प्रदान करता है, यह सुनिश्चित करता है कि उपयोगकर्ता इंटरफेस के बीच बदलाव से परेशान न हों।

Chrome Custom Tabs Chrome के प्रदर्शन का लाभ उठाते हैं, एक सहज और उत्तरदायी उपयोगकर्ता अनुभव सुनिश्चित करते हैं, जो उपयोगकर्ता की निराशा या परित्याग को रोकने के लिए प्रमाणीकरण प्रक्रियाओं के दौरान विशेष रूप से महत्वपूर्ण है।

CCT का प्रदर्शन अक्सर Android WebView विकल्पों से बेहतर होता है (iOS पर SFAuthenticationSession / ASWebAuthenticationSession के साथ भी ऐसा ही है), यह सुनिश्चित करता है कि वेब सामग्री और प्रमाणीकरण प्रवाह तेजी से और सुचारू रूप से संभाले जाते हैं।

Chrome Custom Tabs, Android WebView और मानक Chrome ब्राउज़र के बीच प्रदर्शन अंतर को महसूस करने के लिए Google द्वारा यह तुलना भी देखें।

SFAuthenticationSession / ASWebAuthenticationSession विशेष रूप से OAuth / OpenID Connect-आधारित प्रमाणीकरण प्रवाह को संभालने के लिए डिज़ाइन किया गया है, जो इन व्यापक रूप से उपयोग किए जाने वाले प्रमाणीकरण प्रोटोकॉल के लिए एक सुव्यवस्थित और सुरक्षित प्रक्रिया सुनिश्चित करता है। यह WebAuthn / पासकी प्रमाणीकरण के लिए भी अनुशंसित तरीका है।

Android पर, प्रमाणीकरण प्रवाह के लिए कोई समर्पित वर्ग नहीं है, लेकिन Chrome Custom Tabs और Android App Links के साथ समान व्यवहार लागू किया जा सकता है।

इसके अलावा, हम उम्मीद करते हैं कि और अधिक ऐप्स TikTok की तरह पासकीज़ पेश करेंगे, बस उन्हें तब एकत्र करके जब उपयोगकर्ता प्रमाणित हो। यह नेटिव रूप से (TikTok का कार्यान्वयन) या वेबव्यू कार्यान्वयन के माध्यम से किया जा सकता है। एक उपयुक्त दृष्टिकोण नेटिव रूप से कंडीशनल UI को ट्रिगर करना है। यदि यह काम नहीं करता है, तो आप वेबव्यू कार्यान्वयन प्रदर्शित करते हैं।

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