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

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

Get free Whitepaper

ध्यान दें: सिस्टम और एम्बेडेड वेबव्यू को अक्सर मिलाया जाता है, जहां सिस्टम वेबव्यू लॉगिन को संभालता है (स्वचालित क्रेडेंशियल शेयरिंग के साथ), फिर एम्बेडेड वेबव्यू सेटिंग्स में पासकी प्रबंधन को रेंडर करता है।

मुख्य निर्णय कारक:

• OAuth-आधारित लॉगिन? → सिस्टम वेबव्यू (ASWebAuthenticationSession, Chrome Custom Tabs)
• नेटिव शेल में वेब प्रमाणीकरण का पुन: उपयोग करना चाहते हैं? → एम्बेडेड वेबव्यू (WKWebView, WebKit 1.12.1+ के साथ Android वेबव्यू)
• नेटिव-फर्स्ट ऐप बना रहे हैं? → नेटिव कार्यान्वयन (Apple AuthenticationServices, Google Credential Manager)

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

1. नेटिव कार्यान्वयन: प्लेटफ़ॉर्म API (iOS AuthenticationServices, Android Credential Manager) का उपयोग करके सीधे अपने ऐप में पासकी प्रवाह बनाएं। यह सहज बायोमेट्रिक प्रमाणीकरण के साथ सर्वश्रेष्ठ उपयोगकर्ता अनुभव प्रदान करता है, लेकिन इसके लिए मध्यम से उच्च तकनीकी कार्यान्वयन प्रयास की आवश्यकता होती है।

2. सिस्टम वेबव्यू: प्रमाणीकरण को संभालने के लिए प्लेटफ़ॉर्म के ब्राउज़र घटक (iOS ASWebAuthenticationSession / SFSafariViewController, Android Chrome Custom Tabs) का उपयोग करें। यह OAuth-आधारित लॉगिन प्रवाह के लिए उत्कृष्ट है और सिस्टम ब्राउज़र के साथ क्रेडेंशियल साझा करता है।

3. एम्बेडेड वेबव्यू: नेटिव ऐप स्केलेटन के साथ वेब प्रमाणीकरण का पुन: उपयोग करने के लिए अपने ऐप के भीतर एक अनुकूलन योग्य वेब व्यू (iOS WKWebView, Android WebView) एम्बेड करें। यह URL बार के बिना एक नेटिव जैसा स्वरूप प्रदान करता है और वेब व्यू UI पर पूर्ण नियंत्रण देता है। इसके लिए अतिरिक्त सेटअप की आवश्यकता होती है जिसमें अनुमतियाँ और एंटाइटलमेंट (iOS), और पासकी कार्यक्षमता को सक्षम करने के लिए AndroidX WebKit 1.12.1+ (Android) के साथ वेबव्यू कॉन्फ़िगरेशन शामिल है।

सही चुनाव आपके ऐप की प्रमाणीकरण वास्तुकला, क्या आप OAuth प्रदाताओं का उपयोग करते हैं, UI पर आपको कितना नियंत्रण चाहिए, और क्या आप नेटिव-फर्स्ट बना रहे हैं या वेब घटकों का पुन: उपयोग कर रहे हैं, इस पर निर्भर करता है।

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

नेटिव कार्यान्वयन कब चुनें:

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

मुख्य लाभ: preferImmediatelyAvailableCredentials()

नेटिव कार्यान्वयन preferImmediatelyAvailableCredentials() का लाभ उठाकर एक स्वचालित पासकी ओवरले बना सकते हैं जो पासकी उपलब्ध होने पर ऐप शुरू होते ही तुरंत दिखाई देता है। यह उपयोगकर्ता नाम रहित प्रवाह सबसे तेज़ संभव लॉगिन अनुभव प्रदान करता है - उपयोगकर्ता पहले पहचानकर्ता दर्ज किए बिना तुरंत अपनी पासकी देखते हैं। यह क्षमता विशेष रूप से नेटिव कार्यान्वयन के लिए है और वेबव्यू वेरिएंट में उपलब्ध नहीं है।

जबकि वेबव्यू कार्यान्वयन कंडीशनल UI (इनपुट फ़ील्ड में पासकी सुझाव) का उपयोग कर सकते हैं, नेटिव का स्वचालित ओवरले उच्च पासकी उपयोग दरों के साथ बेहतर UX प्रदान करता है क्योंकि प्रमाणीकरण ऐप लॉन्च होते ही तुरंत शुरू हो जाता है।

तकनीकी आवश्यकताओं का अवलोकन:

नेटिव पासकी एकीकरण के लिए आपके ऐप और वेब डोमेन के बीच क्रिप्टोग्राफ़िक विश्वास की आवश्यकता होती है। इसके बिना, OS सभी WebAuthn परिचालनों को अस्वीकार कर देगा। मुख्य आवश्यकताएं:

1. ऐप-डोमेन एसोसिएशन फ़ाइलें /.well-known/ पर होस्ट की गईं
2. आपके वेब डोमेन से मेल खाता सही Relying Party ID
3. प्लेटफ़ॉर्म-विशिष्ट क्षमताएं (अनुभाग 4 में विस्तृत)

प्रमुख लाभ: आपकी वेबसाइट पर बनाई गई पासकी आपके ऐप में और इसके विपरीत सहजता से काम करती हैं।

आईओएस पर नेटिव रूप से पासकी लागू करने में Apple का AuthenticationServices फ्रेमवर्क शामिल है, जो WebAuthn संचालन के लिए एक API प्रदान करता है:

मुख्य घटक:

• ASAuthorizationController: प्रमाणीकरण प्रवाह का प्रबंधन करता है
• ASAuthorizationPlatformPublicKeyCredentialProvider: पासकी अनुरोध बनाता है
• पासकी लॉगिन को संभालने के लिए तीन अलग-अलग UI मोड:
  • टेक्स्टफील्ड लॉगिन: बटन सबमिट पर पासकी लॉगिन शुरू होने के साथ पारंपरिक उपयोगकर्ता नाम फ़ील्ड
  • पासकी मोडल ओवरले: उपलब्ध पासकी को सूचीबद्ध करने वाला OS संवाद
  • कंडीशनल UI: कीबोर्ड के ऊपर क्विकटाइप बार में पासकी सुझाव

विकास युक्तियाँ

• AASA कैशिंग: Apple AASA फ़ाइल को आक्रामक रूप से कैश करता है (24 घंटे तक), जो परीक्षण को निराशाजनक बना सकता है। समाधान: अपने परीक्षण उपकरण पर डेवलपर मोड सक्षम करें और ताज़ा फ़ेच के लिए अपने AASA URL में ?mode=developer जोड़ें।
• प्रदर्शन परीक्षण: सैकड़ों क्रेडेंशियल वाले iCloud खातों के साथ परीक्षण करें ताकि वास्तविक दुनिया की विलंबता का निरीक्षण किया जा सके। सिस्टम ओवरले में कई संग्रहीत पासकी के साथ थोड़ी देरी हो सकती है।

Android का नेटिव पासकी कार्यान्वयन Credential Manager API (या पिछड़े संगतता के लिए पुराने FIDO2 API) का उपयोग करता है:

मुख्य घटक:

• CredentialManager: सभी क्रेडेंशियल संचालन के लिए केंद्रीय API
• CreatePublicKeyCredentialRequest: पासकी पंजीकरण के लिए
• GetCredentialRequest: पासकी प्रमाणीकरण के लिए
• दो प्राथमिक UI मोड:
  • टेक्स्टफील्ड लॉगिन: बटन सबमिट पर पासकी लॉगिन शुरू होने के साथ पारंपरिक उपयोगकर्ता नाम फ़ील्ड
  • पासकी मोडल ओवरले: उपलब्ध पासकी को सूचीबद्ध करने वाला OS संवाद

ध्यान दें: Android में वर्तमान में नेटिव ऐप्स में iOS के कंडीशनल UI कीबोर्ड सुझावों का अभाव है (हालांकि कंडीशनल UI वेब ऐप्स में काम करता है)।

नेटिव रूप से पासकी लागू करने में महत्वपूर्ण चुनौतियाँ और सीखे गए सबक हैं: OS स्तर पर एकीकरण विभिन्न उपकरणों और OS संस्करणों में समस्याएँ पैदा कर सकता है।

1. उदाहरण के लिए, हमारी टीम को Apple की apple-app-site-association फ़ाइल (ऐप/वेब क्रेडेंशियल लिंकिंग के लिए उपयोग की जाने वाली) की आक्रामक कैशिंग और कुछ Android OEM बायोमेट्रिक संकेतों में सूक्ष्म UI अंतर जैसी समस्याओं का सामना करना पड़ा।
2. इसके अलावा, विचार करें कि कुछ एंटरप्राइज़ परिदृश्यों में, प्रबंधित उपकरणों पर नीति द्वारा पासकी सिंकिंग अक्षम हो सकती है। कॉर्पोरेट वातावरण में जहां iCloud Keychain या Google Password Manager सिंक बंद है, पासकी डिवाइस-बाध्य हो जाती हैं और रोम नहीं करेंगी - यह योजना बनाने के लिए एक महत्वपूर्ण परिदृश्य है (उदाहरण के लिए यह सुनिश्चित करना कि उपयोगकर्ता नया फ़ोन प्राप्त करने पर भी लॉगिन कर सकते हैं)।
3. इसके अतिरिक्त, तृतीय-पक्ष क्रेडेंशियल प्रबंधक ऐप्स प्रवाह को प्रभावित कर सकते हैं। उदाहरण के लिए, यदि किसी उपयोगकर्ता के पास 1Password जैसा पासवर्ड मैनेजर एक सक्रिय क्रेडेंशियल प्रदाता के रूप में सेट है, तो यह अक्सर प्लेटफ़ॉर्म के नेटिव क्रेडेंशियल मैनेजर पर प्राथमिकता लेते हुए, पासकी निर्माण और भंडारण को बाधित करेगा।

जबकि आप कच्चे प्लेटफ़ॉर्म API का उपयोग करके पासकी लागू कर सकते हैं, विशेष रूप से निर्मित SDK WebAuthn जटिलता, किनारे के मामलों को संभालकर और अंतर्निहित टेलीमेट्री प्रदान करके विकास को काफी तेज करते हैं। SDK यूनिट परीक्षण के लिए मॉकेबल इंटरफेस भी प्रदान करते हैं (महत्वपूर्ण क्योंकि आप सिमुलेटर में बायोमेट्रिक्स का परीक्षण नहीं कर सकते हैं)।

सिफारिश: नेटिव कार्यान्वयन के लिए, हम कॉर्बाडो SDK (iOS Swift Passkey SDK, Android Kotlin Passkey SDK) का उपयोग करने की सलाह देते हैं, जो उत्पादन परिनियोजन के माध्यम से खोजे गए कई किनारे के मामलों को संभालते हैं, अतिरिक्त टेलीमेट्री और परीक्षण प्रदान करते हैं।

Igor Gjorgjioski

Head of Digital Channels & Platform Enablement, VicRoads

Corbado proved to be a trusted partner. Their hands-on, 24/7 support and on-site assistance enabled a seamless integration into VicRoads' complex systems, offering passkeys to 5 million users.

Passkeys that millions adopt, fast. Start with Corbado's Adoption Platform.

Start Free Trial

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

सिस्टम वेबव्यू कब चुनें:

• आपका ऐप OAuth-आधारित लॉगिन का उपयोग करता है: सिस्टम वेबव्यू OAuth2/OIDC प्रवाह के लिए अनुशंसित दृष्टिकोण है, जो सुरक्षित प्रमाणीकरण प्रदान करता है।
• मौजूदा वेब-आधारित प्रमाणीकरण जिसे आप मोबाइल ऐप्स में पुन: उपयोग करना चाहते हैं
• नेटिव रूप से पुनर्निर्माण किए बिना कई प्रमाणीकरण विधियों (पासवर्ड, सामाजिक लॉगिन, पासकी) का समर्थन करने की आवश्यकता है
• वेब और मोबाइल पर एक एकल प्रमाणीकरण कोडबेस बनाए रखना चाहते हैं

मुख्य लाभ:

• OAuth संगतता: OAuth/OIDC प्रमाणीकरण प्रवाह के लिए विशेष रूप से निर्मित
• सुरक्षा संकेतक: उपयोगकर्ता वास्तविक URL और SSL प्रमाणपत्र देखते हैं, जिससे विश्वास बनता है
• कम कार्यान्वयन प्रयास: न्यूनतम नेटिव कोड की आवश्यकता
• लगातार UX: परिचित ब्राउज़र इंटरफ़ेस जिस पर उपयोगकर्ता पहले से भरोसा करते हैं

प्लेटफ़ॉर्म घटक:

• iOS: ASWebAuthenticationSession (प्रमाणीकरण प्रवाह के लिए अनुशंसित) या SFSafariViewController (सामान्य ब्राउज़िंग)
• Android: Chrome Custom Tabs (CCT)

Google और GitHub जैसी प्रमुख कंपनियों ने मौजूदा वेब प्रमाणीकरण पृष्ठों पर वेबव्यू ओवरले के माध्यम से अपने मोबाइल ऐप्स में पासकी लॉगिन जोड़ने के लिए इस दृष्टिकोण को अपनाया है। यह तब अच्छा काम करता है जब पूरी तरह से नेटिव प्रमाणीकरण पुनर्निर्माण तुरंत संभव नहीं होता है।

iOS प्रमाणीकरण के लिए दो प्राथमिक सिस्टम वेबव्यू घटक प्रदान करता है:

ASWebAuthenticationSession (प्रमाणीकरण के लिए अनुशंसित):

• OAuth/OIDC और सुरक्षित लॉगिन प्रवाह के लिए विशेष रूप से निर्मित
• स्वचालित रूप से उपयोगकर्ता से पूछता है कि ऐप प्रमाणित करना चाहता है
• सफारी के साथ कुकीज़ और क्रेडेंशियल साझा करता है
• iCloud Keychain के माध्यम से पासकी का समर्थन करता है

SFSafariViewController (सामान्य ब्राउज़िंग):

• ऐप के भीतर पूर्ण सफारी अनुभव
• URL बार और सुरक्षा संकेतक दिखाता है
• iOS 11+ पर सफारी कुकीज़ साझा नहीं करता है; जब सफारी सत्र साझा करने की आवश्यकता हो तो ASWebAuthenticationSession का उपयोग करें
• कम अनुकूलन योग्य लेकिन उपयोगकर्ताओं के लिए अधिक भरोसेमंद

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

Chrome Custom Tabs (CCT) आपके ऐप के भीतर एक क्रोम-संचालित प्रमाणीकरण अनुभव प्रदान करते हैं:

मुख्य विशेषताएं:

• क्रोम ब्राउज़र के साथ कुकीज़ और क्रेडेंशियल साझा करता है
• URL और सुरक्षा संकेतक दिखाता है
• टूलबार रंग और ब्रांडिंग को अनुकूलित कर सकते हैं
• तेज़ लोड समय के लिए प्री-वार्मिंग

OAuth एकीकरण: Chrome Custom Tabs iOS ASWebAuthenticationSession के Android समकक्ष हैं, जो संग्रहीत पासकी तक पहुंच बनाए रखते हुए उत्कृष्ट OAuth समर्थन प्रदान करते हैं।

Want to try passkeys yourself in a passkeys demo?

Try Passkeys

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

एम्बेडेड वेबव्यू कब चुनें:

• नेटिव-जैसा अनुभव: आपका ऐप पहले से ही एक अनुकूलित वेब व्यू के भीतर प्रमाणीकरण को एम्बेड करता है ताकि एक नेटिव लुक और फील बनाए रखा जा सके, और आप इस सुसंगत उपयोगकर्ता अनुभव को बनाए रखना चाहते हैं।
• सत्र/कुकी नियंत्रण की आवश्यकता: आपके ऐप को OAuth प्रमाणीकरण पूरा होने के बाद प्रमाणीकरण टोकन और सत्र स्थिति के सीधे हेरफेर की आवश्यकता होती है।
• मौजूदा प्रमाणीकरण प्रवाह जहां सिस्टम वेबव्यू प्रमाणीकरण एक प्रमाणीकरण कोड लौटाता है लेकिन एम्बेडेड संदर्भों में कोई सत्र नहीं है।
• कई एम्बेडेड वेब स्क्रीन पर प्रमाणित स्थिति बनाए रखनी चाहिए।
• केवल प्रथम-पक्ष प्रमाणीकरण: आपका ऐप सीधे प्रमाणीकरण को संभालता है, तृतीय-पक्ष पासकी कार्यान्वयन के लिए यहां देखें।
• रनटाइम सुविधा का पता लगाने के साथ AndroidX WebKit 1.12.1+
• लॉगिन के लिए कंडीशनल UI सीमा को स्वीकार करें (एम्बेडेड वेबव्यू में समर्थित नहीं), प्रबंधन सेटिंग्स के लिए प्रासंगिक नहीं है।

महत्वपूर्ण संदर्भ:

कई ऐप्स एक हाइब्रिड दृष्टिकोण का उपयोग करते हैं: सिस्टम वेबव्यू प्रारंभिक OAuth प्रमाणीकरण को संभालता है (जहां पासकी सहजता से काम करती हैं), फिर सेटिंग्स में पासकी का प्रबंधन करने के लिए पोस्ट-प्रमाणीकरण के लिए एम्बेडेड वेबव्यू पर स्विच करते हैं। चुनौतियां तब उत्पन्न होती हैं जब सीधे एम्बेडेड वेबव्यू के भीतर पासकी का उपयोग करने का प्रयास किया जाता है।

तकनीकी आवश्यकताएं:

एम्बेडेड वेबव्यू को सिस्टम वेबव्यू की तुलना में अतिरिक्त सेटअप की आवश्यकता होती है:

1. iOS: एसोसिएटेड डोमेन एंटाइटलमेंट, AASA फ़ाइल कॉन्फ़िगरेशन
2. Android: AndroidX WebKit 1.12.1+ वेबव्यू WebAuthn कॉन्फ़िगरेशन के साथ (सुविधा का पता लगाना आवश्यक)
3. दोनों: अच्छी तरह से ज्ञात एसोसिएशन फ़ाइलें ठीक से कॉन्फ़िगर की गईं और डिजिटल एसेट लिंक

प्लेटफ़ॉर्म घटक:

• iOS: WKWebView
• Android: android.webkit.WebView

फायदे और नुकसान:

• मध्यम जटिलता: वेबव्यू कॉन्फ़िगरेशन (Android WebKit 1.12.1+) और एंटाइटलमेंट सेटअप (iOS) की आवश्यकता होती है
• कम पासकी अपनाने की दर: उपयोगकर्ताओं को नेटिव की तुलना में अधिक घर्षण का सामना करना पड़ सकता है
• कंडीशनल UI समर्थित नहीं: इनपुट फ़ील्ड में पासकी ऑटोफिल Android एम्बेडेड वेबव्यू में काम नहीं करता है
• सीमित प्लेटफ़ॉर्म समर्थन: कुछ सुविधाएँ लगातार काम नहीं कर सकती हैं (उदाहरण के लिए स्वचालित पासकी निर्माण)

वेबव्यू के माध्यम से पासकी लागू करते समय, सिस्टम वेबव्यू और एम्बेडेड वेबव्यू के बीच के अंतर को समझना महत्वपूर्ण है। ऊपर उल्लिखित तीन दृष्टिकोण (नेटिव कार्यान्वयन, सिस्टम वेबव्यू, और एम्बेडेड वेबव्यू) प्रत्येक अलग-अलग उपयोग मामलों की सेवा करते हैं।

iOS पर, आपके पास इन-ऐप वेब सामग्री प्रदर्शित करने के लिए कई विकल्प हैं:

• WKWebView एक अनुकूलन योग्य वेबव्यू है जो WebKit फ्रेमवर्क का हिस्सा है (iOS 8 में पेश किया गया)। यह आपको वेब सामग्री की उपस्थिति और व्यवहार पर बहुत अधिक नियंत्रण देता है।
• SFSafariViewController Apple द्वारा प्रदान किया गया एक व्यू कंट्रोलर है जो आपके ऐप के भीतर एक हल्के सफारी ब्राउज़र के रूप में कार्य करता है। यह सफारी के इंजन का उपयोग करता है। iOS 11+ पर, इसका एक अलग कुकी स्टोर है और यह सफारी कुकीज़ साझा नहीं करता है। जब सफारी सत्र साझा करने की आवश्यकता हो तो ASWebAuthenticationSession का उपयोग करें।
• SFAuthenticationSession / ASWebAuthenticationSession विशेष वेब प्रमाणीकरण सत्र हैं (iOS 11/12 के बाद से उपलब्ध) जो विशेष रूप से OAuth/OpenID या अन्य सुरक्षित लॉगिन प्रवाह के लिए अभिप्रेत हैं। ये भी सफारी का लाभ उठाते हैं, लेकिन प्रमाणीकरण प्रवाह पर केंद्रित होते हैं और स्वचालित रूप से साझा कुकीज़ और सिंगल साइन-ऑन (SSO) जैसी चीजों को संभालते हैं।

Android पर, मुख्य विकल्प हैं:

• Android WebView मानक वेबव्यू विजेट (android.webkit.WebView) है, जो अनिवार्य रूप से एक मिनी ब्राउज़र है जिसे आपकी गतिविधियों में एम्बेड किया जा सकता है। यह अत्यधिक अनुकूलन योग्य है लेकिन आपके ऐप की प्रक्रिया में चलता है।
• Chrome Custom Tabs (CCT) एक ऐसी सुविधा है जो आपके ऐप संदर्भ में एक क्रोम-संचालित टैब खोलती है। कस्टम टैब आपके ऐप के हिस्से के रूप में दिखाई देते हैं लेकिन क्रोम ब्राउज़र (यदि स्थापित हो) द्वारा संचालित होते हैं, जिसमें प्री-लोडिंग, साझा कुकीज़ और परिचित URL बार जैसी सुविधाएँ होती हैं।

निम्नलिखित अनुभागों में, हम iOS और Android के लिए इन वेबव्यू प्रकारों में थोड़ा और गहराई से उतरेंगे, और चर्चा करेंगे कि पासकी प्रमाणीकरण प्रवाह के लिए कौन सा सबसे उपयुक्त हो सकता है।

Subscribe to our Passkeys Substack for the latest news.

Subscribe

Apple का प्लेटफ़ॉर्म ऊपर सूचीबद्ध तीन वेबव्यू विकल्प प्रदान करता है। आपकी पसंद यह प्रभावित करेगी कि ऐप के अंदर पासकी का कितनी सहजता से उपयोग किया जा सकता है:

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

WKWebView iOS के लिए एक बहुमुखी वेबव्यू घटक है। डेवलपर्स UI और व्यवहार पर उच्च स्तर के नियंत्रण के साथ वेब सामग्री को प्रस्तुत करने के लिए एक WKWebView एम्बेड कर सकते हैं। WKWebView सफारी के समान रेंडरिंग इंजन का उपयोग करता है, इसलिए यह बहुत प्रदर्शनकारी है और आधुनिक वेब सुविधाओं का समर्थन करता है। सिद्धांत रूप में, WKWebView WebAuthn (और इस प्रकार पासकी) को सही ढंग से कॉन्फ़िगर किए जाने पर संभाल सकता है, लेकिन ध्यान दें कि सुरक्षा के लिए कुछ उन्नत ब्राउज़र सुविधाएँ प्रतिबंधित हो सकती हैं। एक बात का ध्यान रखना चाहिए कि WKWebView डिफ़ॉल्ट रूप से मोबाइल सफारी के साथ कुकीज़ या कीचेन डेटा साझा नहीं करता है। उपयोगकर्ताओं को नए सिरे से लॉगिन करना पड़ सकता है क्योंकि उनका वेबव्यू सत्र सफारी के सत्र से अलग है। इसके अलावा, क्योंकि WKWebView सामग्री को ऐप द्वारा पूरी तरह से अनुकूलित किया जा सकता है, उपयोगकर्ता को एड्रेस बार या सफारी UI नहीं दिखता है - जो ब्रांडिंग के लिए बहुत अच्छा है, लेकिन इसका मतलब है कि उपयोगकर्ता के पास पृष्ठ की वैधता को सत्यापित करने के लिए कम संकेत हैं (एंटी-फ़िशिंग के लिए एक चिंता)। कुछ ऐप्स ने स्क्रिप्ट इंजेक्ट करने या सामग्री को बदलने के लिए WKWebView का दुरुपयोग भी किया है (उदाहरण के लिए TikTok को अपने इन-ऐप ब्राउज़र के माध्यम से ट्रैकिंग JS इंजेक्ट करने के लिए नोट किया गया था), इसलिए WKWebView को सुरक्षित, उपयोगकर्ता-भरोसेमंद तरीके से उपयोग करने में सावधानी बरतनी चाहिए।

SFSafariViewController एक इन-ऐप सफारी अनुभव प्रदान करता है। जब आप SFSafariViewController के साथ एक URL खोलते हैं, तो यह लगभग वास्तविक सफारी ब्राउज़र में खोलने जैसा होता है, सिवाय इसके कि उपयोगकर्ता आपके ऐप के UI के भीतर रहता है। पासकी के लिए इसका लाभ महत्वपूर्ण है: क्योंकि यह अनिवार्य रूप से सफारी है, उपयोगकर्ता का iCloud Keychain और सहेजे गए पासकी सुलभ हैं। ध्यान दें कि iOS 11+ पर कुकीज़ साझा नहीं की जाती हैं। इसका मतलब है कि यदि उपयोगकर्ता के पास आपकी साइट के लिए पहले से ही एक पासकी है, तो सफारी इसे ढूंढ सकता है और आसान लॉगिन के लिए कंडीशनल UI ऑटोकंप्लीट भी प्रदर्शित कर सकता है। SFSafariViewController कम अनुकूलन योग्य है (आप इसके टूलबार को ज्यादा नहीं बदल सकते हैं), लेकिन यह स्वचालित रूप से बहुत सारी सुरक्षा और गोपनीयता सुविधाओं को संभालता है। URL बार दिखाया गया है, HTTPS के लिए पैडलॉक आइकन के साथ पूरा, जो उपयोगकर्ताओं को विश्वास दिलाता है कि वे सही डोमेन पर हैं। सामान्य तौर पर, SFSafariViewController को एक कच्चे WKWebView की तुलना में अधिक सुरक्षित माना जाता है और इसे लागू करना सरल है (Apple इसे ड्रॉप-इन के रूप में प्रदान करता है)। मुख्य ट्रेड-ऑफ यह है कि आप लुक और फील पर कुछ नियंत्रण का त्याग करते हैं। एक प्रमाणीकरण प्रवाह के लिए, यह आमतौर पर स्वीकार्य है। यहां प्राथमिकता सुरक्षा और लॉगिन में आसानी है, जिसमें SFSafariViewController सफारी के संदर्भ का उपयोग करके उत्कृष्टता प्राप्त करता है।

SFAuthenticationSession / ASWebAuthenticationSession – ये कक्षाएं (बाद वाला नया स्विफ्ट-अनुकूल नाम है) विशेष रूप से OAuth या OpenID कनेक्ट जैसे लॉगिन प्रवाह के लिए बनाई गई हैं। जब आपको किसी वेब पेज के माध्यम से किसी उपयोगकर्ता को प्रमाणित करने की आवश्यकता होती है (शायद किसी बाहरी IdP के लिए), तो ये सत्र iOS पर अनुशंसित विकल्प हैं। वे SFSafariViewController के समान हैं क्योंकि वे सफारी ब्राउज़र का उपयोग करते हैं और सफारी के साथ कुकीज़/स्टोरेज साझा करते हैं। मुख्य अंतर यह है कि SFAuthenticationSession हमेशा उपयोगकर्ता को संकेत देगा कि ऐप वेबपेज का उपयोग करके प्रमाणित करना चाहता है (उपयोगकर्ता जागरूकता के लिए) और यह उपलब्ध होने पर स्वचालित रूप से उपयोगकर्ता के मौजूदा सफारी सत्र का उपयोग करेगा।

इसका लाभ एक सहज SSO अनुभव है - यदि उपयोगकर्ता पहले से ही सफारी में प्रदाता में लॉग इन है, तो यह सत्र दूसरे लॉगिन से बचने के लिए उस कुकी का उपयोग कर सकता है। पासकी के लिए, यह महत्वपूर्ण है क्योंकि इसका मतलब है कि सफारी/iCloud कीचेन में संग्रहीत कोई भी पासकी क्रेडेंशियल यहां भी उपयोग किया जा सकता है। Apple का आधिकारिक मार्गदर्शन यह है कि लॉगिन प्रवाह जैसा दिखने वाली किसी भी चीज़ के लिए ASWebAuthenticationSession का उपयोग करें। इसके फायदे बढ़ी हुई गोपनीयता (आपका ऐप कभी भी क्रेडेंशियल या कुकीज़ नहीं देखता, सफारी इसे संभालता है) और अंतर्निहित SSO समर्थन हैं। इसका नुकसान यह है कि यह प्रमाणीकरण प्रवाह तक सीमित है (आप इसे अपने ऐप में केवल मनमाना वेब सामग्री प्रस्तुत करने के लिए उपयोग नहीं करेंगे)। सारांश में, यदि आप iOS पर एक वेबव्यू दृष्टिकोण चुनते हैं, तो ASWebAuthenticationSession आमतौर पर पासकी लागू करने के लिए सबसे अच्छा विकल्प है क्योंकि यह सुरक्षित है, सफारी के साथ स्थिति साझा करता है और प्रमाणीकरण के लिए विशेष रूप से बनाया गया है।

Want to find out how many people use passkeys?

View Adoption Data

Android पर, वेबव्यू निर्णय क्लासिक वेबव्यू और क्रोम कस्टम टैब के बीच है:

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

Android वेबव्यू (android.webkit.WebView) एक घटक है जो आपको अपनी गतिविधि लेआउट में वेब पेजों को एम्बेड करने देता है। यह WKWebView के समान है क्योंकि यह आपको पूर्ण नियंत्रण देता है: आप नेविगेशन को रोक सकते हैं, जावास्क्रिप्ट इंजेक्ट कर सकते हैं, UI को अनुकूलित कर सकते हैं, आदि। यह आपके ऐप की प्रक्रिया के भीतर भी चलता है। पासकी के लिए वेबव्यू का उपयोग करने का मतलब है कि आपका ऐप आपका वेब लॉगिन पेज लोड करता है, और वह पेज एक WebAuthn पासकी समारोह शुरू कर सकता है। आधुनिक एंड्रॉइड वेबव्यू WebAuthn का समर्थन करता है (बशर्ते डिवाइस का वेबव्यू कार्यान्वयन एंड्रॉइड सिस्टम वेबव्यू या क्रोम घटक के माध्यम से अद्यतित हो)। एक प्रमुख विचार: डिफ़ॉल्ट रूप से, एक एंड्रॉइड वेबव्यू उपयोगकर्ता के क्रोम ब्राउज़र के साथ कुकीज़ या संग्रहीत क्रेडेंशियल साझा नहीं करता है। इसलिए वेबव्यू में बनाया या उपयोग किया गया कोई भी पासकी क्रोम को ज्ञात नहीं हो सकता है, और इसके विपरीत। यह अलगाव सुरक्षा के लिए अच्छा हो सकता है (आपका ऐप ब्राउज़र कुकीज़ नहीं पढ़ सकता है), लेकिन यह उपयोगकर्ताओं को फिर से लॉग इन करने के लिए मजबूर कर सकता है यदि उन्होंने पहले ही क्रोम में प्रमाणित कर लिया है। एक और मुद्दा विश्वास का है। एक सादा वेबव्यू URL या SSL लॉक आइकन नहीं दिखाता है, इसलिए उपयोगकर्ताओं को आपको फ़िश न करने के लिए आपके ऐप पर पूरी तरह से भरोसा करना होगा। Google ने संभावित फ़िशिंग जोखिमों के कारण Google OAuth साइन-इन के लिए वेबव्यू के उपयोग पर भी प्रतिबंध लगा दिया है। प्रदर्शन-वार, वेबव्यू ठीक हैं, लेकिन वे उपयोगकर्ता के डिफ़ॉल्ट ब्राउज़र का उपयोग करने की तुलना में धीमे या अधिक मेमोरी-गहन हो सकते हैं, खासकर यदि भारी पृष्ठ लोड हो रहे हों।

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

इसका नकारात्मक पक्ष यह है कि इसके लिए उपयोगकर्ता को क्रोम (या एक समर्थित ब्राउज़र) स्थापित और अद्यतित होना आवश्यक है। अधिकांश एंड्रॉइड उपयोगकर्ता करते हैं, लेकिन कुछ क्षेत्रों में कुछ उपकरणों पर, यह एक मुद्दा हो सकता है। कुल मिलाकर, यदि आप एंड्रॉइड पर एक एम्बेडेड वेब दृष्टिकोण के साथ जाते हैं, तो पासकी प्रवाह के लिए क्रोम कस्टम टैब की सिफारिश की जाती है, क्योंकि वे एकीकरण और सुरक्षा का एक अच्छा संतुलन प्रदान करते हैं। वास्तव में, वे कई मायनों में iOS के SFSafariViewController/ASWebAuthSession के अनुरूप हैं - प्रमाणीकरण के लिए डिफ़ॉल्ट ब्राउज़र का लाभ उठाते हैं।

(एक तरफ: Apple का WKWebView बनाम SFSafariViewController और Android का वेबव्यू बनाम CCT में कई समानताएं हैं। सफारी VC और क्रोम टैब दोनों ब्राउज़र स्थिति साझा करते हैं और बेहतर सुरक्षा प्रदान करते हैं, जबकि WKWebView/Android वेबव्यू अधिक नियंत्रण देते हैं लेकिन वेब सामग्री को अलग करते हैं। पासकी के लिए, स्थिति (कुकीज़, क्रेडेंशियल स्टोर) साझा करना आमतौर पर वांछनीय है ताकि पासकी को सहजता से एक्सेस और बनाया जा सके।)

आप जो भी कार्यान्वयन दृष्टिकोण चुनें, पासकी कार्यक्षमता को सक्षम करने के लिए कुछ तकनीकी आवश्यकताओं को पूरा किया जाना चाहिए। यह अनुभाग अच्छी तरह से ज्ञात एसोसिएशन फ़ाइलों, iOS एंटाइटलमेंट, और Android वेबव्यू कॉन्फ़िगरेशन पर व्यापक मार्गदर्शन प्रदान करता है।

प्रबंधित उपकरणों पर ध्यान दें: पासकी व्यवहार प्रबंधित उपकरणों पर काफी बदल जाता है जहां मोबाइल डिवाइस प्रबंधन (MDM) नीतियां क्रेडेंशियल भंडारण को नियंत्रित करती हैं। प्रबंधित उपकरणों पर पासकी का परीक्षण करने के लिए, प्रबंधित iOS और Android उपकरणों पर पासकी देखें।

नेटिव और एम्बेडेड वेबव्यू प्रवाह को आपके ऐप और वेब डोमेन के बीच क्रिप्टोग्राफ़िक विश्वास स्थापित करने के लिए एसोसिएशन फ़ाइलों की आवश्यकता होती है। सिस्टम वेबव्यू (ASWebAuthenticationSession) और क्रोम कस्टम टैब को ऐप-टू-साइट एसोसिएशन की आवश्यकता नहीं होती है।

AASA फ़ाइल आपके iOS ऐप और आपके वेब डोमेन के बीच संबंध स्थापित करती है, जिससे पासकी दोनों प्लेटफार्मों पर काम कर सकती है।

फ़ाइल स्थान: https://yourdomain.com/.well-known/apple-app-site-association

कॉन्फ़िगरेशन आवश्यकताएँ:

• अपने डोमेन पर /.well-known/apple-app-site-association पर होस्ट करें
• एक वैध SSL प्रमाणपत्र के साथ HTTPS पर परोसें
• कंटेंट-टाइप: application/json
• .well-known पथ पर कोई पुनर्निर्देशन नहीं
• अपने ऐप का टीम आईडी और बंडल आईडी शामिल करें

उदाहरण AASA फ़ाइल:

{
    "webcredentials": {
        "apps": ["TEAMID123.com.example.app"]
    }
}

AASA कैशिंग और परीक्षण:

Apple AASA फ़ाइलों को आक्रामक रूप से कैश करता है (24-48 घंटे तक) एक CDN का उपयोग करके, जो विकास और परीक्षण को निराशाजनक बना सकता है। विकास के दौरान कैशिंग को बायपास करने के लिए:

1. अपने परीक्षण उपकरण पर डेवलपर मोड सक्षम करें
2. Xcode में अपने संबंधित डोमेन में ?mode=developer जोड़ें
3. यह iOS को सीधे आपके सर्वर से नवीनतम AASA फ़ाइल लाने के लिए मजबूर करता है

⚠️ महत्वपूर्ण: उत्पादन रिलीज़ में ?mode=developer का उपयोग न करें। यह पैरामीटर केवल विकास के लिए है - इसे उत्पादन में उपयोग करने से iOS आपकी AASA फ़ाइल को ठीक से पता लगाने से रोकेगा, जिससे पासकी कार्यक्षमता टूट जाएगी।

सत्यापन: अपने कॉन्फ़िगरेशन को सत्यापित करने के लिए Apple का AASA वैलिडेटर का उपयोग करें।

Android आपके ऐप और वेबसाइट के बीच संबंध को सत्यापित करने के लिए डिजिटल एसेट लिंक का उपयोग करता है।

फ़ाइल स्थान: https://yourdomain.com/.well-known/assetlinks.json

कॉन्फ़िगरेशन आवश्यकताएँ:

• अपने डोमेन पर /.well-known/assetlinks.json पर होस्ट करें
• वैध प्रमाणपत्र के साथ HTTPS पर परोसें
• कंटेंट-टाइप: application/json
• अपने ऐप का SHA256 फिंगरप्रिंट (हस्ताक्षर प्रमाणपत्र से) शामिल करें

उदाहरण assetlinks.json फ़ाइल:

[
    {
        "relation": [
            "delegate_permission/common.handle_all_urls",
            "delegate_permission/common.get_login_creds"
        ],
        "target": {
            "namespace": "android_app",
            "package_name": "com.example.app",
            "sha256_cert_fingerprints": [
                "AA:BB:CC:DD:EE:FF:00:11:22:33:44:55:66:77:88:99:AA:BB:CC:DD:EE:FF:00:11:22:33:44:55:66:77:88:99"
            ]
        }
    }
]

सत्यापन: अपने कॉन्फ़िगरेशन को बनाने और सत्यापित करने के लिए Google का डिजिटल एसेट लिंक जेनरेटर का उपयोग करें।

iOS ऐप्स को पासकी कार्यक्षमता तक पहुंचने के लिए उचित एंटाइटलमेंट की आवश्यकता होती है। आवश्यकताएं आपके कार्यान्वयन दृष्टिकोण के आधार पर थोड़ी भिन्न होती हैं।

एंटाइटलमेंट फ़ाइल (अक्सर Flutter ऐप्स में Runner.entitlements या नेटिव iOS प्रोजेक्ट में YourApp.entitlements नाम दिया गया) Apple के सिस्टम द्वारा दी गई विशेष अनुमतियों और क्षमताओं को परिभाषित करती है। पासकी के लिए, यह फ़ाइल एसोसिएटेड डोमेन को कॉन्फ़िगर करती है।

फ़ाइल स्थान: आमतौर पर आपके Xcode प्रोजेक्ट में ios/Runner/Runner.entitlements पर

नेटिव कार्यान्वयन और एम्बेडेड वेबव्यू को आपके ऐप को आपके वेब डोमेन से लिंक करने के लिए एसोसिएटेड डोमेन क्षमता की आवश्यकता होती है। सिस्टम वेबव्यू (ASWebAuthenticationSession) को इसकी आवश्यकता नहीं होती है क्योंकि यह सफारी संदर्भ में चलता है।

Xcode में सेटअप:

1. अपना प्रोजेक्ट Xcode में खोलें
2. अपना ऐप लक्ष्य चुनें
3. "Signing & Capabilities" टैब पर जाएं
4. "+ Capability" पर क्लिक करें और "Associated Domains" जोड़ें
5. webcredentials: उपसर्ग के साथ अपना डोमेन जोड़ें

उदाहरण कॉन्फ़िगरेशन:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>com.apple.developer.associated-domains</key>
    <array>
        <string>webcredentials:yourdomain.com</string>
        <string>webcredentials:subdomain.yourdomain.com</string>
    </array>
</dict>
</plist>

एकाधिक डोमेन: यदि आपके ऐप को कई डोमेन के साथ काम करने की आवश्यकता है तो आपको Related Origin Requests (ROR) की आवश्यकता हो सकती है।

Android एम्बेडेड वेबव्यू ने AndroidX WebKit 1.12 के साथ नेटिव WebAuthn समर्थन प्राप्त किया, जिससे कस्टम जावास्क्रिप्ट ब्रिज कोड की आवश्यकता समाप्त हो गई। सिस्टम वेबव्यू (क्रोम कस्टम टैब) को किसी कॉन्फ़िगरेशन की आवश्यकता नहीं होती है - क्रेडेंशियल स्वचालित रूप से काम करते हैं।

आवश्यकताएँ:

• AndroidX WebKit 1.12.1 या नया (1.14.0+ अनुशंसित)
• डिजिटल एसेट लिंक कॉन्फ़िगर किया गया
• WebAuthn समर्थन के साथ वेबव्यू APK (सुविधा का पता लगाने के माध्यम से जांचें)
• ध्यान दें: वेबव्यू WebAuthn के लिए AndroidX क्रेडेंशियल लाइब्रेरी की आवश्यकता नहीं है, केवल पूरी तरह से नेटिव कार्यान्वयन के लिए

कार्यान्वयन:

import androidx.webkit.WebSettingsCompat
import androidx.webkit.WebViewFeature
 
// Check if Web Authentication is supported
if (WebViewFeature.isFeatureSupported(WebViewFeature.WEB_AUTHENTICATION)) {
    // Enable Web Authentication
    WebSettingsCompat.setWebAuthenticationSupport(
        webView.settings,
        WebSettingsCompat.WEB_AUTHENTICATION_SUPPORT_FOR_APP
    )
 
    // Enable JavaScript
    webView.settings.javaScriptEnabled = true
}

मुख्य बिंदु:

• जावास्क्रिप्ट ब्रिज की आवश्यकता नहीं: WebAuthn वेबव्यू में नेटिव रूप से काम करता है
• सुविधा का पता लगाना आवश्यक: रनटाइम पर हमेशा WebViewFeature.WEB_AUTHENTICATION की जांच करें
• कंडीशनल UI समर्थित नहीं: mediation:"conditional" (इनपुट फ़ील्ड में पासकी ऑटोफिल) एम्बेडेड वेबव्यू में काम नहीं करता है
• फ़ॉलबैक रणनीति: यदि सुविधा उपलब्ध नहीं है, तो इसके बजाय क्रोम कस्टम टैब का उपयोग करें

संस्करण नोट:

• WebKit 1.12.1 या नया का उपयोग करें (1.12.0 में रनटाइम उपलब्धता की समस्या थी)
• सुविधा समर्थन उपयोगकर्ता के वेबव्यू APK संस्करण पर निर्भर करता है - डिवाइस पर पुराने APK सुविधा को उजागर नहीं करेंगे

AndroidX WebKit 1.12.0 से पहले, एम्बेडेड वेबव्यू में नेटिव WebAuthn समर्थन मौजूद नहीं था। टीमों को या तो करना पड़ता था:

1. क्रोम कस्टम टैब या प्रमाणीकरण टैब का उपयोग करें (अनुशंसित)
2. एक कस्टम जावास्क्रिप्ट ब्रिज बनाएं

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

सिफारिश: AndroidX WebKit 1.12.1+ के साथ नेटिव WebAuthn समर्थन का उपयोग करें। यदि रनटाइम पर अनुपलब्ध है, तो क्रोम कस्टम टैब पर वापस जाएं जो साझा क्रेडेंशियल के साथ उत्कृष्ट पासकी समर्थन प्रदान करता है।

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

एकल डोमेन (जैसे kayak.com) का उपयोग करने वाले ऐप्स के लिए, आपको चाहिए:

• iOS के लिए एक AASA फ़ाइल https://kayak.com/.well-known/apple-app-site-association पर
• Android के लिए एक assetlinks.json फ़ाइल https://kayak.com/.well-known/assetlinks.json पर
• webcredentials:kayak.com के साथ कॉन्फ़िगर किया गया एसोसिएटेड डोमेन एंटाइटलमेंट

संबंधित ऑरिजिन्स (ROR) एक WebAuthn सुविधा है जो पासकी के एक ही सेट को कई संबंधित डोमेनों (जैसे kayak.com, kayak.de, kayak.co.uk) में काम करने की अनुमति देती है। ROR संबंधित ऑरिजिन्स को परिभाषित करने के लिए प्रत्येक साइट पर /.well-known/webauthn एंडपॉइंट का उपयोग करता है, न कि AASA या assetlinks फ़ाइलों का।

मुख्य बिंदु:

• ROR कॉन्फ़िगरेशन: प्रत्येक डोमेन संबंधित ऑरिजिन्स की सूची के साथ /.well-known/webauthn होस्ट करता है
• ऐप एसोसिएशन फ़ाइलें (AASA/assetlinks): केवल ऐप्स को उनकी संबंधित वेबसाइटों पर मैप करने के लिए उपयोग किया जाता है
• iOS 18+ एम्बेडेड वेबव्यू: ठीक से कॉन्फ़िगर होने पर ROR का समर्थन करता है
• एसोसिएटेड डोमेन एंटाइटलमेंट: उन सभी डोमेनों को शामिल करें जिनके साथ आपके ऐप को प्रमाणित करने की आवश्यकता है

कॉन्फ़िगरेशन उदाहरण:

यदि आपका ऐप kayak.com और kayak.de के साथ काम करता है, तो दोनों डोमेनों को चाहिए:

• एक ही टीम आईडी और बंडल आईडी के साथ अपनी संबंधित AASA फ़ाइलें होस्ट करें
• आपके ऐप के एसोसिएटेड डोमेन एंटाइटलमेंट में सूचीबद्ध हों
• ठीक से कॉन्फ़िगर और सुलभ वेल-नोन फ़ाइलें हों

लाइव होने से पहले, सत्यापित करें कि आपकी वेल-नोन फ़ाइलें ठीक से कॉन्फ़िगर और सुलभ हैं। Apple और Google फ़ाइल उपलब्धता की जांच के लिए CDN-आधारित परीक्षण URL प्रदान करते हैं:

इन परीक्षण URL का उपयोग करना:

• यह सत्यापित करने के लिए लिंक पर क्लिक करें कि क्या Apple/Google आपकी वेल-नोन फ़ाइलों को पुनः प्राप्त कर सकते हैं
• Apple का ?nocache=1 पैरामीटर ताज़ा पुनर्प्राप्ति को मजबूर करता है, CDN कैश को बायपास करता है
• यदि इन URL के माध्यम से फ़ाइलें सुलभ नहीं हैं, तो आपके ऐप में पासकी कार्यक्षमता काम नहीं करेगी
• ऊपर दिए गए URL पैटर्न में kayak.com या kayak.de को अपने स्वयं के डोमेन (डोमेनों) से बदलें

परीक्षण की एक खास बात: सुनिश्चित करें कि सभी डोमेनों में ठीक से कॉन्फ़िगर की गई वेल-नोन फ़ाइलें हैं। किसी भी डोमेन पर एक लापता या गलत कॉन्फ़िगर की गई फ़ाइल उस डोमेन के लिए पासकी कार्यक्षमता को तोड़ सकती है।

अधिक जानकारी: नेटिव ऐप्स में WebAuthn Relying Party ID

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

इन प्रमुख प्रश्नों से शुरू करें:

1. क्या आपका ऐप OAuth-आधारित लॉगिन (OAuth2, OIDC, सामाजिक लॉगिन प्रदाता) का उपयोग करता है?

   • हाँ → सिस्टम वेबव्यू (अनुभाग 1.2)
     • iOS: ASWebAuthenticationSession का उपयोग करें
     • Android: क्रोम कस्टम टैब का उपयोग करें
     • साझा क्रेडेंशियल के साथ उत्कृष्ट OAuth समर्थन

2. क्या आप नेटिव-जैसे शेल में वेब प्रमाणीकरण का पुन: उपयोग करना चाहते हैं (कोई URL बार नहीं, पूर्ण UI नियंत्रण)?

   • हाँ → कॉन्फ़िगरेशन के साथ एम्बेडेड वेबव्यू (अनुभाग 1.3)
   • iOS: WKWebView + एसोसिएटेड डोमेन एंटाइटलमेंट
   • Android: WebView + AndroidX WebKit 1.12.1+ कॉन्फ़िगरेशन
   • वेब घटकों का पुन: उपयोग करते हुए नेटिव-जैसा स्वरूप प्रदान करता है
   • ध्यान दें: एम्बेडेड वेबव्यू में कंडीशनल UI समर्थित नहीं है
   • नहीं → सिस्टम वेबव्यू या नेटिव पर विचार करें

3. क्या आप एक नया नेटिव ऐप बना रहे हैं या आपके पास नेटिव लॉगिन स्क्रीन हैं?

   • हाँ → नेटिव कार्यान्वयन (अनुभाग 1.1)
     • सर्वश्रेष्ठ उपयोगकर्ता अनुभव
     • तुरंत, साइलेंट प्रमाणीकरण
     • प्लेटफ़ॉर्म-विशिष्ट विकास की आवश्यकता है

4. क्या आपके पास मौजूदा वेब प्रमाणीकरण है जिसे आप पुन: उपयोग करना चाहते हैं?

   • हाँ → त्वरित कार्यान्वयन के लिए सिस्टम वेबव्यू
   • नहीं → इष्टतम UX के लिए नेटिव कार्यान्वयन

यहां बताया गया है कि प्रत्येक दृष्टिकोण प्रमुख आयामों में कैसा प्रदर्शन करता है:

आयाम स्पष्टीकरण:

• पासकी बनाएं: उपयोगकर्ता इस दृष्टिकोण के माध्यम से कितनी आसानी से पासकी बना सकते हैं
• पासकी का उपयोग करें: मौजूदा पासकी का उपयोग करते समय प्रमाणीकरण अनुभव
• पासकी प्रबंधित करें: उपयोगकर्ता पासकी कैसे देखते, संपादित करते, या हटाते हैं
• तकनीकी जटिलता: विकास प्रयास और चल रहे रखरखाव
• OAuth समर्थन: दृष्टिकोण OAuth2/OIDC प्रमाणीकरण प्रवाह को कितनी अच्छी तरह से संभालता है
• सेटअप समय: विशिष्ट कार्यान्वयन समयरेखा

अनुशंसित: सिस्टम वेबव्यू

यदि आपका ऐप OAuth2, OIDC या सामाजिक लॉगिन प्रदाताओं (Google, GitHub, Microsoft, आदि) के माध्यम से प्रमाणित होता है, तो सिस्टम वेबव्यू इष्टतम विकल्प है:

• iOS: ASWebAuthenticationSession OAuth प्रवाह के लिए विशेष रूप से बनाया गया है
• Android: क्रोम कस्टम टैब सहज OAuth एकीकरण प्रदान करते हैं
• लाभ: न्यूनतम नेटिव कोड, स्वचालित क्रेडेंशियल साझाकरण
• कार्यान्वयन: अपने वेब प्रमाणीकरण पृष्ठ पर WebAuthn जोड़ें, फिर इसे सिस्टम वेबव्यू के माध्यम से लोड करें

उदाहरण: kayak.com और kayak.de जैसे ट्रैवल ऐप्स प्रमाणीकरण के लिए OAuth का उपयोग करते हैं। सिस्टम वेबव्यू उन्हें अपने मौजूदा OAuth बुनियादी ढांचे को बनाए रखते हुए अपने वेब प्रमाणीकरण पृष्ठों के माध्यम से पासकी समर्थन जोड़ने की अनुमति देता है।

अनुशंसित: हाइब्रिड दृष्टिकोण

प्रारंभिक OAuth प्रमाणीकरण के लिए सिस्टम वेबव्यू का उपयोग करें, फिर पोस्ट-ऑथ सत्रों के लिए एम्बेडेड वेबव्यू का उपयोग करें:

1. प्रारंभिक प्रमाणीकरण: सिस्टम वेबव्यू OAuth + पासकी लॉगिन को संभालता है
2. सत्र प्रबंधन: प्रमाणित वेब सामग्री के लिए एम्बेडेड वेबव्यू पर स्विच करें जहां आपको कुकी/सत्र नियंत्रण की आवश्यकता होती है
3. तकनीकी सेटअप: सिस्टम और एम्बेडेड वेबव्यू दोनों आवश्यकताओं को कॉन्फ़िगर करें - Android के लिए, सुनिश्चित करें कि AndroidX WebKit 1.12.1+ शामिल है (अनुभाग 5 देखें)

कब उपयोग करें: वे ऐप्स जो OAuth के माध्यम से प्रमाणित होते हैं लेकिन फिर प्रमाणित वेब सामग्री प्रदर्शित करने की आवश्यकता होती है जहां प्रत्यक्ष सत्र हेरफेर की आवश्यकता होती है।

अनुशंसित: नेटिव कार्यान्वयन

स्क्रैच से निर्माण कर रहे हैं या नेटिव स्क्रीन हैं? पूरी तरह से नेटिव जाएं:

• iOS: AuthenticationServices फ्रेमवर्क का उपयोग करें
• Android: क्रेडेंशियल मैनेजर API का उपयोग करें
• लाभ: सर्वश्रेष्ठ UX, तुरंत प्रमाणीकरण, पूर्ण नियंत्रण
• अद्वितीय लाभ: ऐप शुरू होने पर स्वचालित पासकी ओवरले प्रदर्शित करने के लिए preferImmediatelyAvailableCredentials का उपयोग करें - केवल नेटिव कार्यान्वयन के लिए विशेष और उच्चतम रूपांतरण दर प्रदान करता है
• SDK सिफारिश: उत्पादन-परीक्षणित एज केस हैंडलिंग के साथ विकास में तेजी लाने के लिए कॉर्बाडो SDK (iOS, Android) का उपयोग करें

नए ऐप्स के लिए: पहले दिन से नेटिव लॉगिन बनाने की दृढ़ता से सलाह देते हैं। आपको इष्टतम UX के लिए स्थापित करता है और भविष्य के वेबव्यू-टू-नेटिव माइग्रेशन से बचाता है।

अनुशंसित: चरणबद्ध प्रवासन

• चरण 1: सिस्टम वेबव्यू पासकी - मौजूदा वेब लॉगिन में पासकी समर्थन जोड़ें, सिस्टम वेबव्यू (ASWebAuthenticationSession/क्रोम कस्टम टैब) के माध्यम से लोड करें। न्यूनतम नेटिव कोड के साथ त्वरित जीत।
• चरण 2: नेटिव इंटरसेप्ट - वेबव्यू दिखाने से पहले नेटिव पासकी जांच जोड़ें। उदाहरण: kayak.com पहले नेटिव पासकी प्रमाणीकरण का प्रयास करता है, यदि आवश्यक हो तो वेबव्यू पर वापस आता है। पिछड़े संगतता बनाए रखते हुए तेज़ बायोमेट्रिक लॉगिन प्रदान करता है।
• चरण 3: पूर्ण नेटिव - धीरे-धीरे पासकी उपयोगकर्ताओं के लिए नेटिव प्रमाणीकरण में माइग्रेट करें, लिगेसी विधियों के लिए वेबव्यू रखते हुए।

यह चरणबद्ध दृष्टिकोण मौजूदा उपयोगकर्ताओं को बाधित किए बिना वृद्धिशील सुधारों की अनुमति देता है।

विस्तृत कॉन्फ़िगरेशन निर्देशों के लिए अनुभाग 5 देखें।

नेटिव ऐप्स में पासकी का परीक्षण करने के लिए एक संरचित, बहु-स्तरीय दृष्टिकोण की आवश्यकता होती है। परीक्षण पिरामिड का पालन करें: यूनिट परीक्षण (पृथक तर्क), एकीकरण परीक्षण (सिमुलेटर/एम्यूलेटर पर WebAuthn समारोह), और सिस्टम परीक्षण (भौतिक उपकरणों पर एंड-टू-एंड)।

आवश्यक परीक्षण श्रेणियां:

• मुख्य यात्राएँ: पंजीकरण, प्रमाणीकरण, क्रॉस-डिवाइस प्रवाह, पासकी हटाना
• प्लेटफ़ॉर्म कवरेज: iOS (नेटिव), Android (नेटिव), OS संस्करणों में वेब ब्राउज़र
• डोमेन एसोसिएशन: सत्यापित करें कि AASA फ़ाइलें (iOS) और डिजिटल एसेट लिंक (Android) सुलभ हैं
• रद्दीकरण प्रवाह: OS संकेतों और बायोमेट्रिक स्क्रीन पर उपयोगकर्ता रद्दीकरण का परीक्षण करें
• त्रुटि हैंडलिंग: बैकएंड विफलताएं, नेटवर्क टाइमआउट, क्रेडेंशियल बेमेल
• एज केस: स्क्रीन लॉक अक्षम, iCloud/Google पासवर्ड मैनेजर अक्षम
• OAuth प्रवाह: OAuth + पासकी एकीकरण का एंड-टू-एंड पूरा करें
• प्रबंधित डिवाइस: MDM-नियंत्रित वातावरण (प्रबंधित डिवाइस परीक्षण देखें)
• तृतीय-पक्ष प्रबंधक: 1Password, Bitwarden, Dashlane संगतता
• क्रॉस-डिवाइस प्रमाणीकरण: QR कोड प्रवाह और हाइब्रिड परिवहन परीक्षण
• एम्बेडेड वेबव्यू विशिष्ट: यदि एम्बेडेड वेबव्यू का उपयोग कर रहे हैं, तो Android पर WebKit 1.12.1+ कॉन्फ़िगरेशन सत्यापित करें
• उत्पादन निगरानी: सफलता दर, विफलताओं और विलंबता के लिए डैशबोर्ड

स्वचालन रणनीतियों, प्लेटफ़ॉर्म-विशिष्ट समस्याओं और एक पूर्ण प्री-फ़्लाइट चेकलिस्ट सहित व्यापक परीक्षण मार्गदर्शन के लिए, हमारी समर्पित गाइड देखें: नेटिव iOS और Android ऐप्स में पासकी प्रवाह का परीक्षण।

सफल पारंपरिक लॉगिन (पासवर्ड, OAuth) के बाद उपयोगकर्ताओं को पासकी बनाने के लिए संकेत देने पर विचार करें। यह क्रमिक रूपांतरण दृष्टिकोण:

• मौजूदा प्रमाणीकरण प्रवाह को बाधित नहीं करता है
• यदि उपयोगकर्ता मना कर देता है तो सुंदर गिरावट की अनुमति देता है
• परिवर्तनों को मजबूर किए बिना समय के साथ पासकी अपनाने को बढ़ाता है
• सभी तीन कार्यान्वयन दृष्टिकोणों के साथ अच्छा काम करता है

उदाहरण: सिस्टम वेबव्यू के माध्यम से OAuth लॉगिन के बाद, एक नेटिव संकेत दिखाएं: "फेस आईडी के साथ तेज़ लॉगिन सक्षम करें?" यदि स्वीकार किया जाता है, तो सिस्टम वेबव्यू में लोड किए गए वेब पेज के माध्यम से पासकी बनाएं।

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

OAuth-आधारित ऐप्स के लिए: सिस्टम वेबव्यू (ASWebAuthenticationSession, क्रोम कस्टम टैब) अनुशंसित प्रारंभिक बिंदु है। यह उत्कृष्ट OAuth समर्थन, न्यूनतम कार्यान्वयन प्रयास और स्वचालित क्रेडेंशियल साझाकरण प्रदान करता है।

नेटिव-फर्स्ट ऐप्स के लिए: जितनी जल्दी हो सके नेटिव बनें। एक नेटिव पासकी लॉगिन preferImmediatelyAvailableCredentials जैसी विशेष क्षमताओं के साथ सबसे सहज UX प्रदान करता है, जो ऐप शुरू होने पर स्वचालित पासकी ओवरले को सक्षम करता है - कुछ ऐसा जो वेबव्यू कार्यान्वयन प्रदान नहीं कर सकता है। अब iOS और Android पासकी के लिए प्रथम-श्रेणी का समर्थन प्रदान कर रहे हैं, वास्तविक दुनिया की सफलताएँ उच्च अपनाने को प्रदर्शित करती हैं। टूलिंग (ओपन-सोर्स SDK और प्लेटफ़ॉर्म लाइब्रेरी सहित) उचित समय सीमा में नेटिव एकीकरण को प्राप्त करने योग्य बनाने के लिए परिपक्व हो गई है। जबकि आपको डिवाइस प्रबंधन नीतियों, क्रॉस-डिवाइस सिंक, और तृतीय-पक्ष प्रदाताओं से सावधान रहना चाहिए, इन चुनौतियों को सावधानीपूर्वक इंजीनियरिंग और परीक्षण के साथ प्रबंधित किया जा सकता है। परिणाम एक ऐप लॉगिन है जो उपयोगकर्ताओं को इसकी आसानी और गति से प्रसन्न करता है जबकि सुरक्षा में काफी सुधार करता है।

एम्बेडेड वेबव्यू फ्रेम आवश्यकताओं के लिए: एम्बेडेड वेबव्यू का उपयोग आमतौर पर दो वास्तविक दुनिया के परिदृश्यों में किया जाता है। पहला, OAuth-आधारित ऐप्स अक्सर प्रारंभिक लॉगिन प्रवाह के लिए सिस्टम वेबव्यू का उपयोग करते हैं, फिर सत्र नियंत्रण की आवश्यकता होने पर सेटिंग्स स्क्रीन में पासकी प्रबंधन विकल्पों को प्रस्तुत करने के लिए एम्बेडेड वेबव्यू पर स्विच करते हैं - हालांकि कुछ ऐप्स दोनों प्रवाह के लिए सिस्टम वेबव्यू रखकर इसे सरल बनाते हैं। दूसरा, वे ऐप्स जो पासकी अपनाने से पहले अपने प्रमाणीकरण प्रवाह को वेबव्यू फ्रेम में पहले से ही एम्बेड कर चुके हैं, वे संगति के लिए इस पैटर्न को जारी रखते हैं। नेटिव WebAuthn समर्थन (AndroidX WebKit 1.12.1+) के साथ एम्बेडेड वेबव्यू को कॉन्फ़िगरेशन और सेटअप (अनुमतियाँ, एंटाइटलमेंट, वेबव्यू सेटिंग्स) की आवश्यकता होती है, लेकिन अब कस्टम जावास्क्रिप्ट ब्रिज कोड की आवश्यकता नहीं है। ध्यान दें कि एम्बेडेड वेबव्यू में कंडीशनल UI समर्थित नहीं है। इस दृष्टिकोण को तब चुनें जब मौजूदा एम्बेडेड प्रमाणीकरण पैटर्न को बनाए रखना हो या जब आपको पोस्ट-प्रमाणीकरण स्क्रीन के लिए सत्र/कुकी नियंत्रण की आवश्यकता हो।

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

यदि आपके नेटिव ऐप में पासकी काम नहीं कर रही हैं, तो कार्यान्वयन दृष्टिकोण के अनुसार इन सामान्य समस्याओं की जाँच करें:

• फ़ाइलें वैध प्रमाणपत्र के साथ HTTPS पर परोसी जाती हैं
• सही MIME प्रकार: application/json
• .well-known पथ पर कोई पुनर्निर्देशन नहीं
• iOS: टीम आईडी और बंडल आईडी AASA फ़ाइल में बिल्कुल मेल खाते हैं
• Android: SHA256 फिंगरप्रिंट assetlinks.json में आपके हस्ताक्षर प्रमाणपत्र से मेल खाता है
• Relying Party ID आपके डोमेन से मेल खाता है (कोई प्रोटोकॉल नहीं, कोई पोर्ट नहीं)
• RP ID में कोई अंतिम स्लैश नहीं
• WebAuthn ऑरिजिन: https://your-domain.com (app:// नहीं)

• iOS: Xcode में webcredentials:yourdomain.com के साथ एसोसिएटेड डोमेन क्षमता सक्षम है
• Android: AndroidManifest.xml में डिजिटल एसेट लिंक घोषित हैं
• उपयोगकर्ता के पास स्क्रीन लॉक सक्षम है (बायोमेट्रिक या पिन)
• Apple के AASA वैलिडेटर और Google के डिजिटल एसेट लिंक टूल के साथ परीक्षण करें
• सत्यापित करें कि Runner.entitlements फ़ाइल में सही संबंधित डोमेन हैं

• iOS: ASWebAuthenticationSession (अनुशंसित) या SFSafariViewController का उपयोग करना
• Android: क्रोम कस्टम टैब का उपयोग करना (सादा वेबव्यू नहीं)
• iOS: सत्यापित करें कि यदि आवश्यक हो तो एसोसिएटेड डोमेन कॉन्फ़िगर किए गए हैं
• परीक्षण करें कि कुकीज़/क्रेडेंशियल सिस्टम ब्राउज़र के साथ साझा किए गए हैं
• सत्यापित करें कि वेब प्रमाणीकरण पृष्ठ में उचित WebAuthn कार्यान्वयन है

• iOS: उचित एंटाइटलमेंट के साथ कॉन्फ़िगर किया गया
• iOS: एसोसिएटेड डोमेन में सभी प्रासंगिक डोमेन शामिल हैं
• iOS: AASA फ़ाइल सुलभ और ठीक से स्वरूपित है
• iOS: विकास के दौरान ?mode=developer के साथ परीक्षण करें (उत्पादन के लिए हटा दें)
• Android: AndroidX WebKit 1.12.1+ (या नया) प्रोजेक्ट में शामिल है
• Android: WebViewFeature.WEB_AUTHENTICATION के लिए रनटाइम सुविधा जाँच
• Android: setWebAuthenticationSupport() को WEB_AUTHENTICATION_SUPPORT_FOR_APP के साथ कॉल किया गया
• Android: वेबव्यू सेटिंग्स में जावास्क्रिप्ट सक्षम है
• Android: उपयोगकर्ता का वेबव्यू APK संस्करण WebAuthn सुविधा का समर्थन करता है (OS संस्करण नहीं, सुविधा का पता लगाने का उपयोग करें)
• कंडीशनल UI का उपयोग नहीं किया गया (एम्बेडेड वेबव्यू में समर्थित नहीं)
• यदि WebAuthn सुविधा अनुपलब्ध है तो क्रोम कस्टम टैब पर वापस जाएं

• जाँचें कि क्या उपयोगकर्ता के पास गैर-डिफ़ॉल्ट क्रेडेंशियल प्रदाता सक्रिय है (1Password, Bitwarden, आदि)
• सत्यापित करें कि प्रदाता पासकी का समर्थन करता है (सभी पासवर्ड मैनेजर नहीं करते हैं)
• प्लेटफ़ॉर्म-नेटिव क्रेडेंशियल मैनेजर (iCloud Keychain, Google पासवर्ड मैनेजर) के साथ परीक्षण करें

"NotAllowedError: The request is not allowed by the user agent or the platform in the current context"

• आमतौर पर इसका मतलब है: लापता एंटाइटलमेंट (iOS) या वेबव्यू सुविधा उपलब्ध/सक्षम नहीं है (Android एम्बेडेड वेबव्यू)
• जाँचें: एसोसिएटेड डोमेन कॉन्फ़िगरेशन, AASA फ़ाइल पहुँच, WebKit संस्करण, सुविधा का पता लगाना, setWebAuthenticationSupport() कॉल

कोई पासकी संकेत दिखाई नहीं देता

• इसका मतलब हो सकता है: AASA/assetlinks.json लोड नहीं हो रहा है, गलत वेबव्यू प्रकार, कैश्ड AASA फ़ाइल
• प्रयास करें: एसोसिएशन फ़ाइलों को मान्य करें, परीक्षण के लिए iOS पर ?mode=developer का उपयोग करें, वेबव्यू प्रकार सत्यापित करें

विस्तृत डीबगिंग के लिए, नेटिव ऐप्स में Relying Party IDs पर हमारा लेख देखें।

कॉर्बाडो नेटिव SDK:

• iOS SDK (Swift)
• Android SDK (Kotlin)
• Flutter Package

प्लेटफ़ॉर्म दस्तावेज़ीकरण:

• Apple: पासकी का समर्थन
• Google: क्रेडेंशियल मैनेजर

सत्यापन उपकरण:

• Apple AASA वैलिडेटर
• Google डिजिटल एसेट लिंक जेनरेटर