नेटिव ऐप पासकीज़: नेटिव बनाम WebView इम्प्लीमेंटेशन

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

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

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

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

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

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

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

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

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

नेटिव इम्प्लीमेंटेशन कब चुनें:

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

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

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

नीचे दिया गया आरेख स्पष्ट करता है कि कैसे नेटिव ऑथेंटिकेशन WebView के Conditional UI दृष्टिकोण की तुलना में तेज़ उपयोगकर्ता यात्रा प्रदान करता है:

नेटिव का स्वचालित ओवरले उच्च पासकी उपयोग दरों के साथ बेहतर UX प्रदान करता है क्योंकि ऑथेंटिकेशन ऐप लॉन्च होने पर तुरंत शुरू होता है, जबकि WebView कार्यान्वयन के लिए उपयोगकर्ताओं को पहले इनपुट फ़ील्ड के साथ बातचीत करने की आवश्यकता होती है।

तकनीकी आवश्यकताएँ अवलोकन:

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

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

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

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

मुख्य घटक:

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

डेवलपमेंट टिप्स

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

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

Enterprise Passkey व्हाइटपेपर. passkey कार्यक्रमों के लिए व्यावहारिक मार्गदर्शन, रोलआउट पैटर्न और KPIs।

व्हाइटपेपर पाएं

मुख्य घटक:

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

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

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

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

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

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

Igor Gjorgjioski

Head of Digital Channels & Platform Enablement, VicRoads

We hit 80% mobile passkey activation across 5M+ users without replacing our IDP.

See how VicRoads scaled passkeys to 5M+ users — alongside their existing IDP.

Read the case study

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

सिस्टम WebView कब चुनें:

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

मुख्य लाभ:

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

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

• iOS: ASWebAuthenticationSession (ऑथेंटिकेशन फ्लो के लिए अनुशंसित) या SFSafariViewController (सामान्य ब्राउज़िंग)
• Android: Chrome Custom Tabs (CCT)

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

iOS ऑथेंटिकेशन के लिए दो प्राथमिक सिस्टम WebView घटक प्रदान करता है:

ASWebAuthenticationSession (ऑथेंटिकेशन के लिए अनुशंसित):

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

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

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

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

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

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

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

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

Live demo में passkeys आज़माएं.

Passkeys आज़माएं

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

एम्बेडेड WebView कब चुनें:

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

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

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

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

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

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

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

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

ट्रेड-ऑफ़:

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

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

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

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

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

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

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

Latest news के लिए हमारे Passkeys Substack को subscribe करें.

Subscribe करें

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

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

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

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

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

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

देखें कि वास्तव में कितने लोग passkeys इस्तेमाल करते हैं.

Adoption data देखें

Android पर, WebView का निर्णय क्लासिक WebView और Chrome Custom Tabs के बीच है:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

सत्यापन: अपने कॉन्फ़िगरेशन को सत्यापित करने के लिए Apple's AASA Validator का उपयोग करें।

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

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

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

• आपके डोमेन पर /.well-known/assetlinks.json पर होस्ट करें
• मान्य प्रमाणपत्र के साथ HTTPS पर सर्व करें
• Content-Type: 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's Digital Asset Links Generator का उपयोग करें।

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

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

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

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

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 एम्बेडेड WebViews दो अलग-अलग दृष्टिकोणों के माध्यम से पासकी का समर्थन करते हैं: नया WebKit-आधारित दृष्टिकोण (अनुभाग 5.3.1) और पुराना JavaScript ब्रिज दृष्टिकोण (अनुभाग 5.3.2)। सिस्टम WebView (Chrome Custom Tabs) को किसी कॉन्फ़िगरेशन की आवश्यकता नहीं है-क्रेडेंशियल स्वचालित रूप से काम करते हैं।

Android दोनों कार्यान्वयन दृष्टिकोणों को प्रदर्शित करते हुए आधिकारिक WebView पासकी नमूने प्रदान करता है।

नेटिव पासकी हैंडलिंग के साथ आधुनिक WebKit एकीकरण। यह दृष्टिकोण कस्टम ब्रिज कोड की आवश्यकता के बिना नेटिव WebAuthn समर्थन प्रदान करता है।

आधिकारिक नमूना: Webkit WebView MainActivity

आवश्यकताएँ:

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

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

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
}

मुख्य बिंदु:

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

संस्करण नोट्स:

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

AndroidX WebKit 1.12.0 से पहले, एम्बेडेड WebView में नेटिव WebAuthn समर्थन मौजूद नहीं था। यह पुराना दृष्टिकोण बिना नेटिव WebView WebAuthn समर्थन वाले उपकरणों के लिए पासकी को संभालने के लिए वेब-टू-नेटिव ब्रिज का उपयोग करता है।

आधिकारिक नमूने:

• PasskeyWebListener (Bridge Handler)
• JavaScript encode utilities

कब उपयोग करें: पुराने Android संस्करणों या विरासत WebView कार्यान्वयन वाले उपकरणों का समर्थन करना।

टीमों को या तो करना पड़ा:

1. Chrome Custom Tabs या Auth Tab का उपयोग करें (अनुशंसित)
2. एक कस्टम JavaScript ब्रिज बनाएँ

विस्तृत कार्यान्वयन के लिए, Android's Credential Manager WebView Integration guide देखें। हालाँकि, हम आधुनिक ऐप्स के लिए नेटिव WebKit 1.12.1+ दृष्टिकोण का उपयोग करने की दृढ़ता से अनुशंसा करते हैं।

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

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

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

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

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

मुख्य बिंदु:

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

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

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

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

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

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

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

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

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

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

निम्नलिखित फ़्लोचार्ट आपके ऐप की आवश्यकताओं के आधार पर सही कार्यान्वयन दृष्टिकोण का चयन करने में आपका मार्गदर्शन करता है:

प्रत्येक पथ के लिए त्वरित संदर्भ:

• OAuth-आधारित लॉगिन? → सिस्टम WebView (ASWebAuthenticationSession / Chrome Custom Tabs)
• नेटिव शेल में वेब ऑथ का पुन: उपयोग करें? → कॉन्फ़िगरेशन के साथ एम्बेडेड WebView (WKWebView / Android WebView + WebKit 1.12.1+)
• नेटिव-फर्स्ट बना रहे हैं? → नेटिव इम्प्लीमेंटेशन (AuthenticationServices / Credential Manager)
• पुन: उपयोग करने के लिए मौजूदा वेब ऑथ? → त्वरित कार्यान्वयन के लिए सिस्टम WebView; अन्यथा इष्टतम UX के लिए नेटिव

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

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

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

अनुशंसित: सिस्टम WebView

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

• iOS: ASWebAuthenticationSession OAuth फ्लो के लिए उद्देश्य-निर्मित है
• Android: Chrome Custom Tabs निर्बाध OAuth एकीकरण प्रदान करते हैं
• लाभ: न्यूनतम नेटिव कोड, स्वचालित क्रेडेंशियल साझाकरण
• कार्यान्वयन: अपने वेब ऑथेंटिकेशन पेज में WebAuthn जोड़ें, फिर इसे सिस्टम WebView के माध्यम से लोड करें

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

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

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

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

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

अनुशंसित: नेटिव इम्प्लीमेंटेशन

शुरू से बना रहे हैं या नेटिव स्क्रीन हैं? पूरी तरह से नेटिव जाएं:

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

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

अनुशंसित: चरणबद्ध माइग्रेशन

निम्नलिखित आरेख वृद्धिशील माइग्रेशन पथ दिखाता है:

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

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

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

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

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

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

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

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

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

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

OAuth-आधारित ऐप्स के लिए: सिस्टम WebView (ASWebAuthenticationSession, Chrome Custom Tabs) अनुशंसित प्रारंभिक बिंदु है। यह बेहतरीन OAuth सपोर्ट, न्यूनतम कार्यान्वयन प्रयास और स्वचालित क्रेडेंशियल शेयरिंग प्रदान करता है।

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

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

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

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

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

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

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

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

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

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

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

कोई पासकी प्रॉम्प्ट प्रकट नहीं होता है

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

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

एक सामान्य नुकसान: प्रतिबंधित पहुंच (IP व्हाइटलिस्टिंग, केवल-VPN) वाले स्टेजिंग वातावरण विफल हो जाएंगे क्योंकि Apple और Google CDN को आपकी एसोसिएशन फ़ाइलें लाने में सक्षम होना चाहिए।

• AASA/assetlinks फ़ाइलें सार्वजनिक रूप से सुलभ हैं (कोई IP व्हाइटलिस्टिंग नहीं, कोई VPN आवश्यकता नहीं)
• सत्यापित करें कि Apple CDN आपकी फ़ाइल तक पहुँच सकता है: https://app-site-association.cdn-apple.com/a/v1/your-staging-domain.com?nocache=1
• सत्यापित करें कि Google आपकी फ़ाइल तक पहुँच सकता है: https://digitalassetlinks.googleapis.com/v1/statements:list/?source.web.site=https://your-staging-domain.com&relation=delegate_permission/common.handle_all_urls

उत्पादन rpID के साथ स्टेजिंग सबडोमेन:

यदि आपका स्टेजिंग वातावरण (उदा., stg.login.example.com) उत्पादन डोमेन का उपयोग rpID (उदा., example.com) के रूप में करता है, तो AASA लुकअप rpID डोमेन पर होता है, आपके स्टेजिंग सबडोमेन पर नहीं। इसका मतलब है:

• अपनी उत्पादन AASA फ़ाइल में स्टेजिंग ऐप बंडल आईडी जोड़ें
• ध्यान रखें कि स्टेजिंग में बनाई गई पासकी उत्पादन लॉगिन फ्लो में दिखाई देंगी (संभावित भ्रम)

उदाहरण (एक AASA साझा करने वाले कई वातावरण):

{
    "webcredentials": {
        "apps": [
            "TEAMID123.com.example.app",
            "TEAMID123.com.example.app.dev",
            "TEAMID123.com.example.app.stg",
            "TEAMID123.com.example.app.pre"
        ]
    }
}

अनुशंसा: वातावरण के बीच क्रेडेंशियल ओवरलैप से बचने के लिए अपने स्टेजिंग डोमेन से मेल खाने वाली एक अलग स्टेजिंग rpID का उपयोग करें। इसके लिए स्टेजिंग डोमेन पर सार्वजनिक रूप से सुलभ AASA फ़ाइलों की आवश्यकता होती है।

?mode=developer स्पष्टीकरण:

Associated Domains में ?mode=developer पैरामीटर Apple के CDN कैश को बायपास करता है लेकिन पहुंच आवश्यकता को बायपास नहीं करता है। आपकी AASA फ़ाइल अभी भी डिवाइस से पहुँच योग्य होनी चाहिए (Apple के CDN के माध्यम से नहीं, बल्कि सीधे)। यह AASA परिवर्तनों पर पुनरावृति करते समय विकास के दौरान मदद करता है, लेकिन यदि आपका स्टेजिंग सर्वर IP-व्हाइटलिस्टेड है तो यह मदद नहीं करेगा।

Corbado नेटिव SDK:

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

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

• Apple: Supporting Passkeys
• Google: Credential Manager

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

• Apple AASA Validator
• Google Digital Asset Links Generator

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

विकल्प आपके ऑथेंटिकेशन आर्किटेक्चर पर निर्भर करता है। यदि आपका ऐप OAuth2 या OIDC का उपयोग करता है, तो सिस्टम WebView (iOS पर ASWebAuthenticationSession या Android पर Chrome Custom Tabs) को न्यूनतम कार्यान्वयन प्रयास की आवश्यकता होती है और कोई एसोसिएशन फ़ाइल सेटअप नहीं होता है। नए नेटिव-फर्स्ट ऐप्स के लिए, नेटिव इम्प्लीमेंटेशन बेहतर UX प्रदान करता है, जबकि एम्बेडेड WebView उन ऐप्स के लिए उपयुक्त है जो पहले से ही एक WebView फ्रेम में ऑथेंटिकेशन एम्बेड करते हैं और लॉगिन के बाद सत्र या कुकी नियंत्रण की आवश्यकता होती है।

SFSafariViewController Safari के इंजन का लाभ उठाता है, SSL संकेतकों के साथ URL बार दिखाता है और फ़िशिंग सुरक्षा प्रदान करता है, जिससे यह ऑथेंटिकेशन फ्लो के लिए अधिक भरोसेमंद हो जाता है। WKWebView अधिक UI अनुकूलन प्रदान करता है लेकिन इसमें Safari से अलग एक अलग कुकी स्टोर है, इसके लिए Associated Domains एंटाइटेलमेंट और पासकी को सक्षम करने के लिए एक AASA फ़ाइल की आवश्यकता होती है, और URL बार प्रदर्शित नहीं करता है, जिससे उपयोगकर्ता विश्वास संकेत कम हो जाते हैं।

Chrome Custom Tabs उपयोगकर्ता के Chrome ब्राउज़र के साथ कुकीज़ और संग्रहीत क्रेडेंशियल साझा करते हैं, जिसका अर्थ है कि Google Password Manager में सहेजी गई पासकी ऑथेंटिकेशन के दौरान सुलभ हैं। मानक Android WebView में एक अलग कुकी स्टोर होता है, URL या SSL संकेतक नहीं दिखाता है, और संभावित फ़िशिंग जोखिमों के कारण Google ने Google खाता साइन-इन के लिए इसे स्पष्ट रूप से प्रतिबंधित कर दिया है।

यदि किसी उपयोगकर्ता के पास सक्रिय प्रदाता के रूप में 1Password जैसा तृतीय-पक्ष क्रेडेंशियल मैनेजर सेट है, तो यह अक्सर पासकी निर्माण और भंडारण को रोक देगा, जो प्लेटफ़ॉर्म के नेटिव क्रेडेंशियल मैनेजर (iCloud Keychain या Google Password Manager) पर प्राथमिकता लेता है। इसका मतलब है कि क्रॉस-डिवाइस सिंक और पासकी प्रबंधन व्यवहार को प्रभावित करते हुए, पासकी प्लेटफ़ॉर्म कीचेन के बजाय तृतीय-पक्ष ऐप में संग्रहीत की जा सकती हैं।

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