Passkeys और iframes: Passkey कैसे बनाएँ और उससे लॉगिन कैसे करें?

संकेत
✅ = समर्थित ❌ = समर्थित नहीं

हर हफ्ते, ज़्यादा से ज़्यादा संगठन अपने passkey रोलआउट की घोषणा कर रहे हैं (जैसे हाल ही में Visa, Mastercard या Vercel)। जैसे-जैसे अन्य कंपनियों के डेवलपर्स और प्रोडक्ट मैनेजर्स इन रोल मॉडल्स का अनुसरण करते हैं, passkey कार्यान्वयन के और भी उपयोग के मामलों पर चर्चा हो रही है।

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

Integrate passkeys as Payment Provider via 3rd party SDK.

Read article

यह ब्लॉग पोस्ट iframes में passkeys और WebAuthn का उपयोग करने के लिए एक व्यापक गाइड प्रदान करता है। हम करेंगे

• वर्तमान क्षमताओं का पता लगाना
• क्रॉस-ओरिजिन iframe सपोर्ट पर चर्चा करना
• iframe इंटीग्रेशन के लाभों को उजागर करना और
• एक स्टेप-बाय-स्टेप कार्यान्वयन गाइड प्रदान करना

इस पोस्ट के अंत तक, आपको यह स्पष्ट समझ हो जाएगी कि iframes के भीतर passkeys का लाभ कैसे उठाया जाए।

iframes, या इनलाइन फ्रेम्स, HTML एलिमेंट्स होते हैं जो डेवलपर्स को वर्तमान डॉक्यूमेंट के भीतर एक और HTML डॉक्यूमेंट एम्बेड करने की अनुमति देते हैं। इस क्षमता का व्यापक रूप से बाहरी स्रोतों से कंटेंट, जैसे वीडियो, मैप्स और अन्य वेब पेजों को एक वेबसाइट में शामिल करने के लिए उपयोग किया जाता है।

आइए विभिन्न प्रकार के iframes पर एक नज़र डालें।

Subscribe to our Passkeys Substack for the latest news.

Subscribe

बेसिक iframe सबसे अधिक इस्तेमाल किया जाने वाला प्रकार है। यह बस वर्तमान पेज के भीतर किसी अन्य URL से कंटेंट एम्बेड करता है।

<iframe src="https://example.com"></iframe>

इस बेसिक iframe का उपयोग अक्सर एक वेब पेज के भीतर स्थिर कंटेंट, जैसे एक लेख, को शामिल करने के लिए किया जाता है।

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

<iframe src="https://example.com" style="width: 100%; height: 500px;"></iframe>

CSS मीडिया क्वेरीज़ का उपयोग iframe को व्यूपोर्ट आकार के आधार पर गतिशील रूप से समायोजित करने के लिए भी किया जा सकता है।

Get a free passkey assessment in 15 minutes.

Book free consultation

एक सुरक्षित या सैंडबॉक्स्ड iframe उन क्रियाओं को प्रतिबंधित करता है जो iframe के भीतर की जा सकती हैं। यह अविश्वसनीय स्रोतों से कंटेंट एम्बेड करने या सुरक्षा बढ़ाने के लिए उपयोगी है।

<iframe src="https://example.com" sandbox></iframe>

sandbox एट्रिब्यूट में विभिन्न प्रतिबंध शामिल हो सकते हैं, जैसे:

<iframe src="https://example.com" sandbox="allow-scripts allow-same-origin"></iframe>

sandbox एट्रिब्यूट स्क्रिप्ट को चलाने की अनुमति देता है लेकिन संभावित रूप से खतरनाक क्रियाओं को प्रतिबंधित करता है, जैसे फॉर्म सबमिशन या प्लगइन उपयोग।

Become part of our Passkeys Community for updates & support.

Join

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

क्रॉस-ओरिजिन का मतलब है कि लोड किया जा रहा कंटेंट एक अलग ओरिजिन से है, जहां एक ओरिजिन को स्कीम (प्रोटोकॉल), होस्ट (डोमेन), और पोर्ट नंबर के संयोजन द्वारा परिभाषित किया गया है। उदाहरण के लिए, https://example.com और http://example.com को अलग-अलग ओरिजिन माना जाता है क्योंकि वे अलग-अलग स्कीम (HTTP बनाम HTTPS) का उपयोग करते हैं।

इसी तरह, सबडोमेन को उनके पैरेंट डोमेन से अलग ओरिजिन माना जाता है। उदाहरण के लिए, https://example.com और https://sub.example.com क्रॉस-ओरिजिन हैं, भले ही वे एक ही बेस डोमेन साझा करते हों। यह पृथक्करण सुनिश्चित करता है कि एक सबडोमेन से स्क्रिप्ट और डेटा स्पष्ट अनुमति के बिना दूसरे से सीधे इंटरैक्ट नहीं कर सकते, जिससे सुरक्षा बढ़ती है।

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.

Enterprises trust Corbado to protect their users and make logins more seamless with passkeys. Get your free passkey consultation now.

Get free consultation

क्रॉस-ओरिजिन और सेम-ओरिजिन की अवधारणाओं को स्पष्ट करने के लिए यहां कुछ उदाहरण दिए गए हैं:

क्रॉस-ओरिजिन उदाहरण:

https://payment.example.com से कंटेंट को https://www.mystore.com पर होस्ट किए गए वेबपेज में एम्बेड करना। ये क्रॉस-ओरिजिन हैं क्योंकि उनके डोमेन अलग-अलग हैं।

सेम-ओरिजिन उदाहरण:

https://www.example.com/shop से कंटेंट को https://www.example.com/blog पर होस्ट किए गए वेबपेज में एम्बेड करना। ये सेम-ओरिजिन हैं क्योंकि वे एक ही स्कीम, होस्ट और पोर्ट साझा करते हैं।

क्रॉस-ओरिजिन iframes बेसिक iframes से इस मायने में अलग हैं कि स्रोत दूसरे डोमेन से होता है, जबकि एक सेम-साइट iframe का स्रोत उसी डोमेन से होता है जहां इसे एम्बेड किया गया है।

<iframe src="https://anotherdomain.com"></iframe>

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

ऐतिहासिक रूप से, Web Authentication API को क्रॉस-ओरिजिन iframes में डिफ़ॉल्ट रूप से अक्षम कर दिया गया था, मुख्य रूप से सुरक्षा चिंताओं के कारण। इस सीमा का मतलब था कि डेवलपर्स को यूज़र्स को रीडायरेक्ट करना पड़ता था या ऑथेंटिकेशन के लिए पॉप-अप विंडो का उपयोग करना पड़ता था, जिससे यूज़र एक्सपीरियंस कम सहज होता था।

Passkeys / WebAuthn में, दो मुख्य ऑपरेशन (जिन्हें सेरेमनी भी कहा जाता है) होते हैं:

1. रजिस्टर / एक passkey बनाना
2. एक passkey के साथ ऑथेंटिकेट / लॉगिन करना

दोनों ऑपरेशन क्रॉस-ओरिजिन iframes में समान रूप से समर्थित नहीं थे और नहीं हैं:

पहले, क्रॉस-ओरिजिन iframes के माध्यम से लॉगिन संभव बनाया गया था लेकिन क्रॉस-ओरिजिन क्रिएशन अभी तक नहीं क्योंकि किसी के पास इसका कोई उपयोग का मामला नहीं था।

हाल के सुधारों (जैसे Chrome 123 में) ने विशिष्ट शर्तों के तहत क्रॉस-ओरिजिन iframe passkeys के क्रिएशन के लिए सपोर्ट पेश किया है। हालांकि, मई 2024 तक, सभी ब्राउज़र क्रॉस-ओरिजिन iframes के माध्यम से passkeys के क्रिएशन का पूरी तरह से समर्थन नहीं करते हैं, हालांकि अधिकांश ब्राउज़रों के साथ लॉगिन संभव है।

इसके अलावा, क्रॉस-ओरिजिन iframe सपोर्ट (रजिस्टर और ऑथेंटिकेशन ऑपरेशन के लिए) पहले से ही चल रहे WebAuthn Level 3 स्पेसिफिकेशन में शामिल है। कुछ ब्राउज़रों को अभी भी स्पेसिफिकेशन के साथ तालमेल बिठाने की आवश्यकता है (जैसे Safari)। दुर्भाग्य से, Apple ने अभी तक यह घोषणा नहीं की है कि वह Safari के भीतर passkeys के क्रॉस-ओरिजिन रजिस्ट्रेशन की अनुमति देगा या नहीं और कब देगा। यह क्रॉस-ओरिजिन iframes में passkeys का उपयोग करने के लिए सबसे महत्वपूर्ण तकनीकी सीमा को हटा देगा।

ब्लॉग पोस्ट के निम्नलिखित भागों में, हम क्रॉस-ओरिजिन iframes के उपयोग को मानकर चल रहे हैं।

Want to find out how many people use passkeys?

View Adoption Data

निम्नलिखित तालिकाएँ iframe ऑथेंटिकेशन और क्रॉस-ओरिजिन iframe संदर्भों में passkeys के माध्यम से iframe लॉगिन के लिए ब्राउज़र/मानक समर्थन का एक सिंहावलोकन प्रदान करती हैं:

मई 2024 तक, एक क्रॉस-ओरिजिन iframe में passkey बनाना अभी तक सभी ब्राउज़रों में संभव नहीं है। निम्नलिखित तालिका क्रॉस-ओरिजिन iframes में passkeys के पंजीकरण / निर्माण के लिए ब्राउज़र / मानक समर्थन का एक सिंहावलोकन प्रदान करती है:

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

क्रॉस-ओरिजिन iframes में passkeys का समर्थन करने के दो प्रमुख उपयोग के मामले हैं।

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

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

• www.kayak.com
• www.kayak.us
• www.kayak.de

हालांकि, आपके पास एक केंद्रीय पहचान प्रबंधन प्रणाली है जो यूज़र्स को इन सभी डोमेन पर एक ही अकाउंट और क्रेडेंशियल्स के साथ लॉगिन करने में सक्षम बनाती है। WebAuthn मानक इन परिदृश्यों के लिए एक चुनौती पेश करेगा, क्योंकि passkeys केवल एक डोमेन (Relying Party ID) से बंधे हो सकते हैं, जैसे www.kayak.com।

इस चुनौती से पार पाने के लिए, आप अपने सभी अन्य डोमेन पर www.kayak.com ओरिजिन से एक iframe का उपयोग करेंगे। तो आप www.kayak.us और www.kayak.de (क्रॉस-ओरिजिन iframe) पर www.kayak.com ओरिजिन के साथ एक iframe एम्बेड करते हैं। अन्यथा, इन अन्य डोमेन पर आपके "www.kayak.com"-बाउंड passkeys का उपयोग passkeys के फ़िशिंग-प्रतिरोध के कारण संभव नहीं होगा।

एक साइड नोट पर: Related Origin Requests (RoR) की नई WebAuthn सुविधा का भी वैकल्पिक रूप से उपयोग किया जा सकता है। यह सुविधा "संबंधित ओरिजिन" को iframes के बिना passkeys तक पहुंचने की अनुमति देती है, लेकिन अभी तक सभी ब्राउज़रों पर इसका समर्थन नहीं है।

सहज पेमेंट प्रवाह के लिए भी, क्रॉस-ओरिजिन iframes में passkeys का उपयोग एक महत्वपूर्ण भूमिका निभाता है। निम्नलिखित परिदृश्य पर विचार करें: एक ग्राहक एक मर्चेंट की वेबसाइट (जैसे www.amazon.com) पर नए जूते खरीदना चाहता है। यह मर्चेंट की वेबसाइट ग्राहक को बैंक खाते के माध्यम से भुगतान करने की अनुमति देती है (जैसे www.revolut.com पर) और इस प्रकार यूज़र को बैंक की वेबसाइट पर लॉगिन करने की आवश्यकता होती है (यह एक सरलीकृत प्रक्रिया है)। यूज़र बैंक की वेबसाइट पर एक passkey के साथ लॉगिन करता है जो बैंक के Relying Party ID से बंधा होता है, जैसे "revolut.com"।

Integrate passkeys as Payment Provider via 3rd party SDK.

Read article

चेकआउट प्रक्रिया में यूज़र को मर्चेंट की वेबसाइट (www.amazon.com) से बैंक की वेबसाइट (www.revolut.com) पर रीडायरेक्ट करने से बचने और यूज़र को वहां बैंक के खाते में लॉगिन करने देने के लिए, एक क्रॉस-ओरिजिन iframe का उपयोग किया जा सकता है। इसके द्वारा, यूज़र www.amazon.com पर रहता है और ऑथेंटिकेशन के लिए क्रॉस-ओरिजिन iframe में उस passkey का उपयोग करता है जिसे उन्होंने www.revolut.com के लिए बनाया था।

इस प्रकार, पेमेंट प्रवाह में क्रॉस-ओरिजिन iframes के माध्यम से passkeys को एकीकृत करना उपभोक्ताओं, मर्चेंट्स और बैंकों के बीच सुरक्षित और सुव्यवस्थित लेनदेन सुनिश्चित करता है:

पेमेंट और passkeys के संदर्भ में, हम Secure Payment Confirmation (SPC) और passkeys के साथ डायनेमिक लिंकिंग पर हमारे ब्लॉग पोस्ट पर एक नज़र डालने की भी सलाह देते हैं। नीचे नेटिव ऐप्स में थर्ड-पार्टी-कॉन्टेक्स्ट के लिए सीमाओं पर भी एक नज़र डालना सुनिश्चित करें।

इसके अतिरिक्त, passkeys का उपयोग करके क्रॉस-ओरिजिन पेमेंट प्रवाह के बारे में अधिक गहराई से देखने के लिए, हमारा पेमेंट प्रोवाइडर Passkeys: 3rd पार्टी SDK कैसे बनाएँ देखें।

सामान्य तौर पर, iframes के भीतर passkeys को एकीकृत करने से कई लाभ मिलते हैं, मुख्य रूप से UX और सुरक्षा में सुधार करके। यहाँ इन लाभों का एक विश्लेषण है:

बेहतर यूज़र एक्सपीरियंस

1. कोई पॉप-अप या रीडायरेक्ट नहीं: यूज़र्स रीडायरेक्ट या पॉप-अप के बिना सीधे एम्बेडेड कंटेंट के भीतर ऑथेंटिकेट कर सकते हैं, जिसके परिणामस्वरूप एक सहज और कम विघटनकारी अनुभव होता है।
2. साइटों पर सुसंगत UX: iframes के भीतर ऑथेंटिकेशन प्रवाह को एम्बेड करना एक वेबसाइट के विभिन्न वर्गों में या एक ही ऑथेंटिकेशन सेवा का उपयोग करने वाली विभिन्न वेबसाइटों पर एक सुसंगत यूज़र एक्सपीरियंस सुनिश्चित करता है।

बेहतर सुरक्षा

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

iframes में passkeys को लागू करने में सुरक्षा और कार्यक्षमता सुनिश्चित करने के लिए कुछ प्रमुख चरण शामिल हैं। हम डेवलपर्स के लिए एक विस्तृत गाइड प्रदान करते हैं। कृपया https://cross-origin-iframe.vercel.app/ पर उदाहरण कार्यान्वयन भी देखें।

HTTP Permissions-Policy हेडर एक डॉक्यूमेंट में या एक iframe एलिमेंट के भीतर कुछ ब्राउज़र सुविधाओं के उपयोग की अनुमति देने या अस्वीकार करने में मदद करता है। एक iframe में passkey लॉगिन को सक्षम करने के लिए, आपको publickey-credentials-get और publickey-credentials-create परमिशन पॉलिसी सेट करनी होगी। ये पॉलिसी एम्बेडेड कंटेंट को ऑथेंटिकेट (navigator.credentials.get({publicKey})) करने और एक passkey बनाने (navigator.credentials.create({publicKey})) के लिए आवश्यक WebAuthn API विधि को लागू करने की अनुमति देती हैं।

<iframe src="https://passkeys.eu" allow="publickey-credentials-get; publickey-credentials-create"></iframe>

HTTP Permissions Policy को पहले Feature Policy कहा जाता था। Feature Policy के तहत, आप हेडर ओरिजिन सूची में ओरिजिन जोड़कर या iframe टैग में allow एट्रिब्यूट शामिल करके एक क्रॉस-ओरिजिन iframe को एक सुविधा प्रदान कर सकते थे। Permissions Policy के साथ, ओरिजिन सूची में एक क्रॉस-ओरिजिन फ्रेम जोड़ने के लिए यह आवश्यक है कि उस ओरिजिन के लिए iframe टैग में allow एट्रिब्यूट शामिल हो। यदि प्रतिक्रिया में Permissions Policy हेडर की कमी है, तो ओरिजिन सूची डिफ़ॉल्ट रूप से * (सभी ओरिजिन) हो जाती है। iframe में allow एट्रिब्यूट शामिल करने से सुविधा तक पहुंच मिलती है।

यह सुनिश्चित करने के लिए कि ओरिजिन सूची में निर्दिष्ट नहीं किए गए क्रॉस-ओरिजिन iframes को सुविधा तक पहुंचने से रोका जाता है, भले ही allow एट्रिब्यूट मौजूद हो, डेवलपर्स प्रतिक्रिया में Permissions Policy हेडर को स्पष्ट रूप से सेट कर सकते हैं।

Chrome 88+ में, Feature Policy का अभी भी उपयोग किया जा सकता है लेकिन यह Permissions Policy के लिए एक उपनाम के रूप में कार्य करता है। सिंटैक्स अंतर के अलावा, तर्क वही रहता है। जब Permissions Policy और Feature Policy दोनों हेडर्स का एक साथ उपयोग किया जाता है, तो Permissions Policy हेडर को प्राथमिकता मिलती है और यह Feature Policy हेडर द्वारा सेट किए गए मान को ओवरराइड कर देगा। कृपया अधिक कार्यान्वयन विवरण के लिए Chrome टीम द्वारा इस ब्लॉग पोस्ट को भी देखें।

सुनिश्चित करें कि iframe के स्रोत URL से HTTP प्रतिक्रिया हेडर्स में प्रासंगिक ´Permissions-Policy` शामिल है। यह क्रॉस-ओरिजिन समर्थन के लिए महत्वपूर्ण है।

Permissions-Policy: publickey-credentials-get=*, publickey-credentials-create=*

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

Permissions-Policy: publickey-credentials-get=("https://passkeys.eu"), publickey-credentials-create=("https://passkeys.eu")

सुनिश्चित करें कि iframe कंटेंट को passkey ऑथेंटिकेशन को ट्रिगर करने के लिए एक यूज़र एक्शन की आवश्यकता है। यह iframe के भीतर क्लिक या फॉर्म सबमिशन के लिए इवेंट श्रोताओं का उपयोग करके किया जा सकता है। इस प्रक्रिया को ट्रांजिएंट एक्टिवेशन भी कहा जाता है।

document.getElementById('loginPasskeyButton').addEventListener('click',
    async () => {
        try {
            const [publicKeyCredentialRequestOptions](/glossary/publickeycredentialrequestoptions) = { /* Configuration options */ };
 
            const credential = await navigator.credentials.get({publicKey: publicKeyCredentialRequestOptions});
            // Handle the created credential
        } catch (err) {
            console.error('Error authenticating via passkey:', err);
        }
    });

इस संदर्भ में, Safari यूज़र जेस्चर आवश्यकताओं पर हमारा ब्लॉग पोस्ट भी देखें।

निम्नलिखित में, आपको https://cross-origin-iframe.vercel.com पर होस्ट की गई एक index.html फ़ाइल का एक पूरा नमूना कोड स्निपेट मिलेगा जो https://passkeys.eu के माध्यम से passkeys के लिए एक क्रॉस-ओरिजिन iframe का उपयोग करता है।

<!doctype html>
<html lang="en">
    <head>
        <meta charset="UTF-8" />
        <meta name="viewport" content="width=device-width, initial-scale=1.0" />
        <meta
            http-equiv="Permissions-Policy"
            content="publickey-credentials-get=*; publickey-credentials-create=*"
        />
        <meta
            http-equiv="Content-Security-Policy"
            content="default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline'; font-src 'self'; img-src 'self'; frame-src https://passkeys.eu;"
        />
 
        <title>Cross-Origin iframe with Passkeys Demo</title>
        <style>
            body {
                font-family: Arial, sans-serif;
                padding: 20px;
                display: flex;
                flex-direction: column;
                justify-content: center;
                align-items: center;
                height: 100vh;
                margin: 0;
            }
 
            h1 {
                width: 100%;
                text-align: center;
            }
 
            .iframe-container {
                width: 80%;
                max-width: 800px;
                height: 80%;
                max-height: 600px;
                border: 1px solid #ccc;
                box-shadow: 0 0 10px rgba(0, 0, 0, 0.1);
                margin-top: 20px;
            }
 
            iframe {
                width: 100%;
                height: 100%;
                border: none;
            }
 
            @media (max-width: 768px) {
                h1 {
                    width: 95%;
                }
 
                .iframe-container {
                    width: 95%;
                }
            }
        </style>
    </head>
    <body>
        <h1>Cross-Origin iframe with Passkeys Demo</h1>
 
        <div class="iframe-container">
            <iframe
                src="https://passkeys.eu"
                allow="publickey-credentials-create; publickey-credentials-get"
            ></iframe>
        </div>
    </body>
</html>

iframes में passkeys को लागू करने में कुछ चुनौतियाँ आ सकती हैं जिन्हें डेवलपर्स को एक सहज और सुरक्षित यूज़र एक्सपीरियंस सुनिश्चित करने के लिए संबोधित करने की आवश्यकता होती है। यहाँ आम चुनौतियों और उनसे निपटने के तरीकों पर एक विस्तृत नज़र है।

समस्या: परमिशन पॉलिसी को गलत तरीके से कॉन्फ़िगर करने से iframe को WebAuthn API तक पहुंचने से रोका जा सकता है।

“NotAllowedError - The 'publickey-credentials-create' feature is not enabled in this document. Permissions Policy may be used to delegate Web Authentication capabilities to cross-origin child frames.”

यदि आप परमिशन पॉलिसी को सही ढंग से नहीं जोड़ते हैं, तो ब्राउज़र निम्नलिखित त्रुटि देगा:

समाधान:

• दोबारा जांचें कि Allow एट्रिब्यूट और HTTP हेडर्स सेट हैं: सुनिश्चित करें कि allow एट्रिब्यूट और HTTP हेडर्स सही ढंग से सेट हैं। दोबारा जांचें कि publickey-credentials-get और publickey-credentials-create अनुमतियाँ iframe एलिमेंट और सर्वर के HTTP प्रतिक्रिया हेडर्स दोनों में शामिल हैं।
• वेब सर्वर हेडर्स के बजाय मेटा हेडर्स: अपने वेब सर्वर में हेडर्स सेट करने के बजाय परमिशन पॉलिसी को परिभाषित करने के लिए <meta/> हेडर्स का उपयोग करें।
• Permissions-Policy में कॉमा के बजाय सेमीकोलन: पहले, Permissions-Policy को Feature-Policy कहा जाता था। Feature-Policy के एकल तत्वों को सेमीकोलन (जो Permissions-Policy के लिए मानक है) के बजाय कॉमा से अलग किया जाता था। iframe Permissions-Policy अभी भी Feature-Policy के सिंटैक्स का पालन करता है और इस प्रकार कॉमा का उपयोग करता है। हालांकि, सैंडबॉक्स / allow एट्रिब्यूट अभी भी एक सेमीकोलन के साथ अलग किए जाते हैं (ऊपर कोड स्निपेट देखें)।

टिप: यह ठीक से परीक्षण करने के लिए कि आपके Permission-Policy हेडर्स सही ढंग से सेट हैं, हम आपके ब्राउज़र के डेवलपर टूल खोलने, Application (यहाँ: Chrome डेवलपर टूल में) तक पहुंचने, Frames पर जाने और iframe के ओरिजिन (यहाँ: passkeys.eu/) की खोज करने की सलाह देते हैं। यदि Permissions-Policy सही ढंग से सेट है, तो publickey-credential-create और publickey-credential-get को Allowed Features के बीच सूचीबद्ध किया जाना चाहिए:

समस्या: क्रॉस-ओरिजिन iframe passkey क्रिएशन या passkey लॉगिन काम नहीं करता है, और आप अपने ब्राउज़र कंसोल में निम्नलिखित त्रुटि देखते हैं।

"NotAllowedError - The origin of the document is not the same as its ancestors."

यह त्रुटि तब दिखाई देती है जब Safari ब्राउज़र का उपयोग करते हुए iframe के भीतर से एक passkey बनाने का प्रयास किया जाता है, क्योंकि Safari क्रॉस-ओरिजिन iframe passkey क्रिएशन का समर्थन नहीं करता है (ऊपर देखें)।

समाधान: यहाँ, आप वास्तव में कुछ नहीं कर सकते क्योंकि Safari अभी तक एक क्रॉस-ओरिजिन iframe के भीतर से एक passkey के निर्माण का समर्थन नहीं करता है (अभी तक)।

Blocked a frame with origin "https://passkeys.eu" from accessing a frame with origin "https://cross-origin-iframe.vercel.app". Protocols, domains, and ports must match.

यह त्रुटि सीधे passkeys से नहीं बल्कि सामान्य रूप से Safari में क्रॉस-ओरिजिन iframes से जुड़ी है। Safari / WebKit की थर्ड-पार्टी कुकीज़ को ब्लॉक करने की पहल या थर्ड-पार्टी-कॉन्टेक्स्ट में LocalStorage तक पहुंच के हिस्से के रूप में, JavaScript लॉजिक के कुछ हिस्से टूट सकते हैं।

समाधान: यहाँ, आपको यह सुनिश्चित करने की आवश्यकता है कि आप अपने iframes के अंदर थर्ड-पार्टी कुकीज़ का उपयोग नहीं कर रहे हैं, क्योंकि इससे एक त्रुटि होती है।

समस्या: iframe ब्राउज़र कम्पैटिबिलिटी समस्याएँ तब उत्पन्न होती हैं जब विभिन्न ब्राउज़रों में WebAuthn, iframe अनुमतियों और सुरक्षा एट्रिब्यूट्स के लिए समर्थन के विभिन्न स्तर होते हैं, जिससे असंगत व्यवहार होता है।

समाधान: इन iframe ब्राउज़र कम्पैटिबिलिटी समस्याओं को कम करने के लिए, कम्पैटिबिलिटी सुनिश्चित करने और किसी भी ब्राउज़र-विशिष्ट मुद्दों की पहचान करने के लिए कई ब्राउज़रों में कार्यान्वयन का परीक्षण करें।

चरण:

1. BrowserStack या Sauce Labs जैसे टूल का उपयोग करके क्रॉस-ब्राउज़र परीक्षण करें।
2. ब्राउज़र-विशिष्ट सुधार या फ़ॉलबैक लागू करके किसी भी विसंगतियों को दूर करें।

समस्या: नेटिव ऐप्स के अंदर passkeys की आवश्यकता वाले iframes का उपयोग करते समय, फर्स्ट-पार्टी और थर्ड-पार्टी संदर्भों के बीच एक महत्वपूर्ण अंतर किया जाना चाहिए:

• फर्स्ट-पार्टी संदर्भ: passkeys उसी डोमेन से जुड़े होते हैं जिस कंपनी का ऐप है। उदाहरण के लिए, एक ई-कॉमर्स ऐप जो अपने स्वयं के डोमेन पर यूज़र ऑथेंटिकेशन के लिए निर्भर करता है।
• थर्ड-पार्टी संदर्भ: एक अलग डोमेन (जैसे, एक पेमेंट प्रोवाइडर या आइडेंटिटी प्रोवाइडर) passkey क्रिएशन या लॉगिन प्रवाह को संभालता है।

एक एम्बेडेड WebView (EWV) जैसे iOS पर WKWebView या एक Android WebView में - कॉलिंग ऐप का वेब सत्र पर व्यापक नियंत्रण होता है (जैसे, अनुरोधों को इंटरसेप्ट करना)। यह सेटअप आमतौर पर passkeys का समर्थन केवल तभी करता है जब passkey का डोमेन (Relying Party ID) ऐप के डोमेन (फर्स्ट-पार्टी) से मेल खाता हो। हालांकि, एक थर्ड-पार्टी परिदृश्य में - जैसे कि एक पेमेंट प्रोवाइडर का क्रॉस-ओरिजिन प्रवाह - एक एम्बेडेड WebView आम तौर पर आवश्यक passkey क्रेडेंशियल्स तक नहीं पहुंच सकता है क्योंकि मर्चेंट का ऐप और पेमेंट प्रोवाइडर की सेवा अलग-अलग ओरिजिन हैं। passkeys के लिए आवश्यक "बाइंडिंग" (डोमेन, क्रेडेंशियल और ओरिजिन के बीच) एम्बेडेड संदर्भ में मेल नहीं खाएंगे।

यह सीमा कई ऐप्स को एक सिस्टम WebView दृष्टिकोण अपनाने के लिए प्रेरित करती है (जैसे, iOS पर ASWebAuthenticationSession या Android पर कस्टम टैब)। सिस्टम WebViews थर्ड-पार्टी साइट (जैसे, पेमेंट प्रोवाइडर) को एक सुरक्षित, ब्राउज़र-जैसे वातावरण में अलग करते हैं जो क्रॉस-ओरिजिन passkeys को सही ढंग से अनुमति देता है - यदि ब्राउज़र स्वयं इसका समर्थन करता है। फिर भी, याद रखें कि Safari की मौजूदा iframe सीमाएँ ASWebAuthenticationSession पर भी लागू होती हैं, इसलिए यदि Safari थर्ड-पार्टी iframes में कुछ passkey संचालन की अनुमति नहीं देता है, तो वही सिस्टम WebView में भी सच होगा। वर्तमान में कोई "नेटिव" फिक्स नहीं है; जटिल प्रवाह के लिए सबसे अच्छा अभ्यास - जैसे कि बाहरी पेमेंट प्रोवाइडर्स को शामिल करने वाले चेकआउट - एक एम्बेडेड के बजाय एक सिस्टम WebView खोलना है।

समाधान: पेमेंट प्रोवाइडर्स (और डोमेन में passkeys पर निर्भर अन्य थर्ड पार्टी) के लिए, यह सुनिश्चित करने के लिए इंटीग्रेशन की सावधानीपूर्वक योजना बनाएं कि यूज़र को एक एम्बेडेड WebView से बाहर निकालकर एक सिस्टम में ले जाया जाए। हालांकि यह एक विशुद्ध रूप से एम्बेडेड प्रवाह की तुलना में कम सहज अनुभव है, यह अक्सर यह गारंटी देने का एकमात्र तरीका है कि passkey कार्यक्षमता थर्ड-पार्टी सेवाओं के साथ काम करेगी।

Integrate passkeys as Payment Provider via 3rd party SDK.

Read article

नेटिव ऐप्स और WebViews के भीतर थर्ड-पार्टी passkeys को संभालने के बारे में अधिक जानकारी के लिए, पेमेंट प्रोवाइडर Passkeys: थर्ड-पार्टी Passkeys पेमेंट SDK देखें।

हालांकि ऊपर चर्चा किए गए विषय विभिन्न परिदृश्यों पर लागू होते हैं, वे विशेष रूप से पेमेंट प्रोवाइडर्स के लिए महत्वपूर्ण हैं, जहां मल्टी-डोमेन प्रवाह (जैसे, मर्चेंट साइट और पेमेंट गेटवे) को क्रॉस-ओरिजिन iframes के भीतर यूज़र ऑथेंटिकेशन को एम्बेड करना होगा। इन सेटअप में:

• यूज़र्स रीडायरेक्ट पॉप-अप के बिना एक घर्षण रहित, इन-पेज चेकआउट चाहते हैं।
• पेमेंट प्रोवाइडर्स को अपने स्वयं के डोमेन (जैसे, pay.provider.com) पर passkey पंजीकरण या लॉगिन को संभालना होगा, भले ही वे एक मर्चेंट की साइट में एम्बेडेड हों।
• Safari की बाधाएं और एम्बेडेड WebView सीमाएं अक्सर iframes में थर्ड-पार्टी passkey क्रिएशन को ब्लॉक करती हैं।

इन चुनौतियों से निपटने और Apple Pay के समान एक सुरक्षित, सहज अनुभव बनाने के लिए, पेमेंट प्रोवाइडर्स अक्सर एक हाइब्रिड दृष्टिकोण अपनाते हैं - iframe-आधारित इंटीग्रेशन को Safari (या पुराने ब्राउज़रों) के लिए एक रीडायरेक्ट फ़ॉलबैक के साथ जोड़ते हैं। कुछ मामलों में, सिस्टम ब्राउज़र प्रवाह (जैसे, iOS पर ASWebAuthenticationSession) अनिवार्य हो जाते हैं यदि एक एम्बेडेड WebView passkeys की अनुमति बिल्कुल नहीं देगा।

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

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

Get free Whitepaper

विशेष रूप से:

• रणनीति A: एक क्रॉस-ओरिजिन iframe एम्बेड करना बताता है कि इनलाइन passkey क्रिएशन और लॉगिन को कैसे संभालना है, यहाँ पेश की गई Permissions-Policy सेटिंग्स का संदर्भ देते हुए।
• रणनीति B: व्यापक कम्पैटिबिलिटी के लिए रीडायरेक्ट-आधारित दृष्टिकोण एक सरल इंटीग्रेशन दिखाता है जो अधिकांश क्रॉस-ओरिजिन नुकसानों को दरकिनार करता है, हालांकि मर्चेंट के डोमेन को छोड़ने की कीमत पर।
• सिस्टम WebView नेटिव ऐप्स के लिए आवश्यक है, क्योंकि एम्बेडेड WebViews अक्सर थर्ड-पार्टी passkey प्रवाह को तोड़ देते हैं।

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

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

वास्तविक दुनिया के कार्यान्वयन, जैसे कि Shopify का अपने लॉगिन कंपोनेंट में passkeys का इंटीग्रेशन, इस दृष्टिकोण के व्यावहारिक लाभ और लचीलेपन को प्रदर्शित करते हैं।