---
url: 'https://www.corbado.com/hi/blog/iframe-me-passkeys-ka-upyog'
title: 'Passkeys और iframes: Passkey कैसे बनाएँ और उससे लॉगिन कैसे करें?'
description: 'हमारे गाइड के साथ जानें कि क्रॉस-ओरिजिन iframes में Passkeys कैसे बनाएँ और उनसे लॉगिन कैसे करें। WebAuthn में iframes, सुरक्षा नीतियों और कार्यान्वयन के बारे में जानें।'
lang: 'hi'
author: 'Vincent Delitz'
date: '2025-07-15T13:22:44.872Z'
lastModified: '2026-03-25T10:07:28.429Z'
keywords: 'iframe, क्रॉस-ओरिजिन'
category: 'WebAuthn Know-How'
---

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

### त्वरित संदर्भ: क्रॉस-ओरिजिन Passkey सपोर्ट (जुलाई 2025)

| ब्राउज़र        | **क्रॉस-ओरिजिन लॉगिन**<br/>(`navigator.credentials.get`)                                                  | **क्रॉस-ओरिजिन क्रिएशन**<br/>(`navigator.credentials.create`)                                    |
| --------------- | --------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------ |
| **Chrome/Edge** | ✅ [Chrome 84 (जुलाई 2020)](https://blog.chromium.org/2020/05/chrome-84-beta-web-otp-web-animations.html) | ✅ [Chrome 123 (मार्च 2024)](https://groups.google.com/a/chromium.org/g/blink-dev/c/Sq2WAVbPz6g) |
| **Firefox**     | ✅ [Firefox 118 (सितंबर 2023)](https://bugzilla.mozilla.org/show_bug.cgi?id=1460986)                      | ✅ [Firefox 123 (फरवरी 2024)](https://bugzilla.mozilla.org/show_bug.cgi?id=1870863)              |
| **Safari**      | ✅ [Safari 15.5 (मई 2022)](https://bugs.webkit.org/show_bug.cgi?id=222240)                                | ❌ [समर्थित नहीं](#62-challenge-2-cross-origin-iframe-issues-with-safari)                        |

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

## 1. परिचय: iframe में Passkeys का उपयोग कैसे करें?

हर हफ्ते, ज़्यादा से ज़्यादा संगठन अपने passkey रोलआउट की घोषणा कर रहे हैं (जैसे हाल ही
में [Visa](https://www.corbado.com/blog/visa-passkeys), [Mastercard](https://www.corbado.com/blog/mastercard-passkeys) या
[Vercel](https://www.corbado.com/blog/vercel-passkeys))। जैसे-जैसे अन्य कंपनियों के डेवलपर्स और प्रोडक्ट मैनेजर्स
इन रोल मॉडल्स का अनुसरण करते हैं, passkey कार्यान्वयन के और भी उपयोग के मामलों पर चर्चा हो
रही है।

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

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

- वर्तमान क्षमताओं का पता लगाना
- क्रॉस-ओरिजिन [iframe](https://www.corbado.com/blog/iframe-passkeys-webauthn) सपोर्ट पर चर्चा करना
- [iframe](https://www.corbado.com/blog/iframe-passkeys-webauthn) इंटीग्रेशन के लाभों को उजागर करना और
- एक स्टेप-बाय-स्टेप कार्यान्वयन गाइड प्रदान करना

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

## 2. iframes के प्रकार

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

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

### 2.1 बेसिक iframe

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

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

इस बेसिक [iframe](https://www.corbado.com/blog/iframe-passkeys-webauthn) का उपयोग अक्सर एक वेब पेज के भीतर स्थिर
कंटेंट, जैसे एक लेख, को शामिल करने के लिए किया जाता है।

### 2.2 रिस्पॉन्सिव iframe

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

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

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

### 2.3 सुरक्षित iframe (सैंडबॉक्स्ड iframe)

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

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

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

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

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

### 2.4 क्रॉस-ओरिजिन iframe / क्रॉस-साइट iframe

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

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

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

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

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

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

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

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

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

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

## 3. iframes Passkeys को कैसे सपोर्ट करते हैं?

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](https://www.corbado.com/blog/passkeys-prf-webauthn) स्पेसिफिकेशन में शामिल है। कुछ
ब्राउज़रों को अभी भी स्पेसिफिकेशन के साथ तालमेल बिठाने की आवश्यकता है (जैसे Safari)।
दुर्भाग्य से, Apple ने अभी तक यह घोषणा नहीं की है कि वह Safari के भीतर passkeys के
क्रॉस-ओरिजिन रजिस्ट्रेशन की अनुमति देगा या नहीं और कब देगा। यह क्रॉस-ओरिजिन iframes में
passkeys का उपयोग करने के लिए सबसे महत्वपूर्ण तकनीकी सीमा को हटा देगा।

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

### 3.1 क्रॉस-ओरिजिन iframes में Passkeys के साथ लॉगिन करें

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

| **ब्राउज़र/मानक**           | **फर्स्ट-पार्टी-कॉन्टेक्स्ट** | **थर्ड-पार्टी-कॉन्टेक्स्ट** |
| --------------------------- | ----------------------------- | --------------------------- |
| WebAuthn Level 2 में आवश्यक | ✔️                            | ✔️                          |
| WebAuthn Level 3 में आवश्यक | ✔️                            | ✔️                          |
| Chrome में लागू             | ✔️                            | ✔️                          |
| Firefox में लागू            | ✔️                            | ✔️                          |
| Safari में लागू             | ✔️                            | ✔️                          |

### 3.2 क्रॉस-ओरिजिन iframes में Passkeys बनाएँ

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

| **ब्राउज़र/मानक**                                                           | **फर्स्ट-पार्टी-कॉन्टेक्स्ट**                           | **थर्ड-पार्टी-कॉन्टेक्स्ट**                                           |
| --------------------------------------------------------------------------- | ------------------------------------------------------- | --------------------------------------------------------------------- |
| WebAuthn Level 2 में आवश्यक                                                 | ✔️ [विवरण](https://issues.chromium.org/issues/40258856) | ❌                                                                    |
| WebAuthn Level 3 में आवश्यक                                                 | ✔️ [विवरण](https://issues.chromium.org/issues/40258856) | ✔️ [विवरण](https://issues.chromium.org/issues/40258856)               |
| Chrome में लागू                                                             | ✔️ [विवरण](https://issues.chromium.org/issues/40258856) | ✔️ [विवरण](https://issues.chromium.org/issues/40258856)               |
| Firefox में लागू                                                            | ✔️ [विवरण](https://issues.chromium.org/issues/40258856) | ✔️ [विवरण](https://github.com/mozilla/standards-positions/issues/964) |
| [Safari](https://github.com/WebKit/standards-positions/issues/304) में लागू | ✔️ [विवरण](https://issues.chromium.org/issues/40258856) | कार्यान्वयन के लिए संकेत की प्रतीक्षा है                              |

यदि आप इस विकास और समर्थन के बारे में अधिक पृष्ठभूमि में रुचि रखते हैं, तो हम इस
[GitHub इश्यू](https://github.com/w3c/webauthn/issues/1656) और इस
[पुल रिक्वेस्ट](https://github.com/w3c/webauthn/pull/1801) पर एक नज़र डालने की सलाह देते
हैं।

### 3.3 iframes में Passkeys के लिए उपयोग के मामले

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

#### 3.3.1 फ़ेडरेटेड आइडेंटिटी

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

आइए निम्नलिखित परिदृश्य पर विचार करें। आप [KAYAK](https://www.corbado.com/blog/kayak-passkeys) जैसी एक
बहुराष्ट्रीय कंपनी हैं और विभिन्न क्षेत्रों के लिए आपके पास अलग-अलग डोमेन हैं:

- [www.kayak.com](https://www.kayak.com)
- [www.kayak.us](https://www.kayak.us)
- [www.kayak.de](https://www.kayak.de)

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

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

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

#### 3.3.2 पेमेंट्स

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

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

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

| **उपभोक्ता**                                                                                                                                                               | **मर्चेंट्स**                                                                                                                                                                                       | **बैंक**                                                                                                                                                                                                       |
| -------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| <ul><li>चेकआउट के दौरान न्यूनतम घर्षण का अनुभव करते हैं, जिससे विश्वास और सुरक्षा बढ़ती है और</li><br/><li>खरीदारी के दौरान संभावित सुरक्षा चिंताओं से बचते हैं।</li></ul> | <ul><li>बैंक-पंजीकृत passkeys का लाभ उठाकर चेकआउट वर्कफ़्लो को सरल बनाते हैं और</li><br/><li>तेज़ और अधिक सुरक्षित चेकआउट से लाभान्वित होते हैं, जिससे संभावित रूप से रूपांतरण बढ़ते हैं।</li></ul> | <ul><li>डिजिटल और सुरक्षित FIDO2-आधारित भुगतान साधनों में संक्रमण करते हैं और</li><br/><li>उपभोक्ता इंटरैक्शन के लिए passkeys का उपयोग करके अनुपालन सुनिश्चित करते हैं और जोखिम और लागत कम करते हैं।</li></ul> |

पेमेंट और passkeys के संदर्भ में, हम
[Secure Payment Confirmation](https://www.corbado.com/blog/dynamic-linking-passkeys-spc) (SPC) और passkeys के साथ
डायनेमिक लिंकिंग पर हमारे ब्लॉग पोस्ट पर एक नज़र डालने की भी सलाह देते हैं। नीचे नेटिव
ऐप्स में थर्ड-पार्टी-कॉन्टेक्स्ट के लिए सीमाओं पर भी एक नज़र डालना सुनिश्चित करें।

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

## 4. iframes में Passkeys उपयोग करने के लाभ

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

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

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

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

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

## 5. iframes में Passkeys लागू करने के लिए स्टेप-बाय-स्टेप गाइड

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

![Cross-Origin iframe Passkey Demo](https://www.corbado.com/website-assets/cross_origin_iframe_passkey_demo_8879588a51.png)

### 5.1 publickey-credentials-get और publickey-credentials-create के लिए परमिशन पॉलिसी सेट करें

HTTP `Permissions-Policy` हेडर एक डॉक्यूमेंट में या एक iframe एलिमेंट के भीतर कुछ ब्राउज़र
सुविधाओं के उपयोग की अनुमति देने या अस्वीकार करने में मदद करता है। एक iframe में passkey
लॉगिन को सक्षम करने के लिए, आपको
[publickey-credentials-get](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Permissions-Policy/publickey-credentials-get)
और
[publickey-credentials-create](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Permissions-Policy/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 टीम द्वारा इस ब्लॉग पोस्ट](https://developer.chrome.com/docs/privacy-security/permissions-policy)
को भी देखें।

### 5.2 HTTP हेडर्स कॉन्फ़िगर करें

सुनिश्चित करें कि iframe के स्रोत URL से HTTP प्रतिक्रिया हेडर्स में प्रासंगिक
´[Permissions-Policy](https://www.corbado.com/faq/enable-passkeys-iframe)\` शामिल है। यह क्रॉस-ओरिजिन समर्थन के
लिए महत्वपूर्ण है।

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

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

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

### 5.3 यूज़र एक्टिवेशन को हैंडल करें

सुनिश्चित करें कि iframe कंटेंट को passkey ऑथेंटिकेशन को ट्रिगर करने के लिए एक यूज़र एक्शन
की आवश्यकता है। यह iframe के भीतर क्लिक या फॉर्म सबमिशन के लिए इवेंट श्रोताओं का उपयोग
करके किया जा सकता है। इस प्रक्रिया को
[ट्रांजिएंट एक्टिवेशन](https://developer.mozilla.org/en-US/docs/Glossary/Transient_activation)
भी कहा जाता है।

```javascript
document.getElementById('loginPasskeyButton').addEventListener('click',
    async () => {
        try {
            const [publicKeyCredentialRequestOptions](https://www.corbado.com/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 यूज़र जेस्चर आवश्यकताओं पर हमारा ब्लॉग पोस्ट भी देखें।

### 5.4 उदाहरण कार्यान्वयन

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

```html
<!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>
```

## 6. आम चुनौतियाँ और उनसे कैसे निपटें

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

### 6.1 चुनौती 1: परमिशन पॉलिसी कॉन्फ़िगरेशन

**समस्या:** परमिशन पॉलिसी को गलत तरीके से कॉन्फ़िगर करने से 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.”**

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

![passkey iframe permission policy configuration](https://www.corbado.com/website-assets/passkey_iframe_permission_policy_configuration_4819cbebec.png)

**समाधान:**

- **दोबारा जांचें कि 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** के बीच
सूचीबद्ध किया जाना चाहिए:

![passkey permissions policy allowed features](https://www.corbado.com/website-assets/passkey_permissions_policy_allowed_features_ffadbc4302.png)

### 6.2 चुनौती 2: Safari के साथ क्रॉस-ओरिजिन iframe की समस्याएँ

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

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

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

![passkey iframe not allowed error](https://www.corbado.com/website-assets/passkey_iframe_not_allowed_error_a217258310.png)

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

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

यह त्रुटि सीधे passkeys से नहीं बल्कि सामान्य रूप से Safari में क्रॉस-ओरिजिन iframes से
जुड़ी है।
[Safari / WebKit की थर्ड-पार्टी कुकीज़ को ब्लॉक करने की पहल](https://webkit.org/blog/10218/full-third-party-cookie-blocking-and-more/)
या थर्ड-पार्टी-कॉन्टेक्स्ट में LocalStorage तक पहुंच के हिस्से के रूप में, JavaScript
लॉजिक के कुछ हिस्से टूट सकते हैं।

![passkey iframe third party cookie](https://www.corbado.com/website-assets/passkey_iframe_third_party_cookie_199bb288c3.png)

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

### 6.3 चुनौती 3: ब्राउज़र कम्पैटिबिलिटी

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

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

**चरण:**

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

### 6.4 चुनौती 4: नेटिव ऐप्स में iframes

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

- **फर्स्ट-पार्टी संदर्भ**: passkeys उसी डोमेन से जुड़े होते हैं जिस कंपनी का ऐप है।
  उदाहरण के लिए, एक [ई-कॉमर्स](https://www.corbado.com/passkeys-for-e-commerce) ऐप जो अपने स्वयं के डोमेन पर
  यूज़र ऑथेंटिकेशन के लिए निर्भर करता है।
- **थर्ड-पार्टी संदर्भ**: एक अलग डोमेन (जैसे, एक पेमेंट प्रोवाइडर या आइडेंटिटी प्रोवाइडर)
  passkey क्रिएशन या लॉगिन प्रवाह को संभालता है।

एक **एम्बेडेड WebView (EWV)** जैसे [iOS](https://www.corbado.com/blog/how-to-enable-passkeys-ios) पर
[WKWebView](https://www.corbado.com/blog/native-app-passkeys) या एक
[Android](https://www.corbado.com/blog/how-to-enable-passkeys-android) [WebView](https://www.corbado.com/blog/native-app-passkeys) में -
कॉलिंग ऐप का वेब सत्र पर व्यापक नियंत्रण होता है (जैसे, अनुरोधों को इंटरसेप्ट करना)। यह
सेटअप आमतौर पर passkeys का समर्थन केवल तभी करता है जब passkey का डोमेन (Relying Party ID)
ऐप के डोमेन (फर्स्ट-पार्टी) से मेल खाता हो। हालांकि, एक थर्ड-पार्टी परिदृश्य में - जैसे कि
एक पेमेंट प्रोवाइडर का क्रॉस-ओरिजिन प्रवाह - एक एम्बेडेड
[WebView](https://www.corbado.com/blog/native-app-passkeys) आम तौर पर आवश्यक passkey क्रेडेंशियल्स तक नहीं पहुंच
सकता है क्योंकि मर्चेंट का ऐप और पेमेंट प्रोवाइडर की सेवा अलग-अलग ओरिजिन हैं। passkeys के
लिए आवश्यक "बाइंडिंग" (डोमेन, क्रेडेंशियल और ओरिजिन के बीच) एम्बेडेड संदर्भ में मेल नहीं
खाएंगे।

यह सीमा कई ऐप्स को एक **सिस्टम WebView** दृष्टिकोण अपनाने के लिए प्रेरित करती है (जैसे,
[iOS](https://www.corbado.com/blog/how-to-enable-passkeys-ios) पर
[ASWebAuthenticationSession](https://www.corbado.com/blog/native-app-passkeys) या
[Android](https://www.corbado.com/blog/how-to-enable-passkeys-android) पर कस्टम टैब)। सिस्टम WebViews थर्ड-पार्टी
साइट (जैसे, पेमेंट प्रोवाइडर) को एक सुरक्षित, ब्राउज़र-जैसे वातावरण में अलग करते हैं जो
क्रॉस-ओरिजिन passkeys को सही ढंग से अनुमति देता है - यदि ब्राउज़र स्वयं इसका समर्थन करता
है। फिर भी, याद रखें कि **Safari की मौजूदा iframe सीमाएँ**
[ASWebAuthenticationSession](https://www.corbado.com/blog/native-app-passkeys) पर भी लागू होती हैं, इसलिए यदि
Safari थर्ड-पार्टी iframes में कुछ passkey संचालन की अनुमति नहीं देता है, तो वही सिस्टम
[WebView](https://www.corbado.com/blog/native-app-passkeys) में भी सच होगा। वर्तमान में कोई "नेटिव" फिक्स नहीं
है; **जटिल प्रवाह** के लिए सबसे अच्छा अभ्यास - जैसे कि बाहरी पेमेंट प्रोवाइडर्स को शामिल
करने वाले चेकआउट - एक एम्बेडेड के बजाय एक सिस्टम WebView खोलना है।

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

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

## 7. पेमेंट प्रोवाइडर्स के लिए अतिरिक्त नोट: क्रॉस-ओरिजिन iframes और थर्ड-पार्टी SDKs

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

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

इन चुनौतियों से निपटने और **Apple Pay** के समान एक सुरक्षित, सहज अनुभव बनाने के लिए,
पेमेंट प्रोवाइडर्स अक्सर एक **हाइब्रिड दृष्टिकोण** अपनाते हैं - iframe-आधारित इंटीग्रेशन
को Safari (या पुराने ब्राउज़रों) के लिए एक रीडायरेक्ट फ़ॉलबैक के साथ जोड़ते हैं। कुछ
मामलों में, **सिस्टम ब्राउज़र** प्रवाह (जैसे, [iOS](https://www.corbado.com/blog/how-to-enable-passkeys-ios) पर
[ASWebAuthenticationSession](https://www.corbado.com/blog/native-app-passkeys)) अनिवार्य हो जाते हैं यदि एक
एम्बेडेड WebView passkeys की अनुमति बिल्कुल नहीं देगा।

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

विशेष रूप से:

- [**रणनीति A: एक क्रॉस-ओरिजिन iframe एम्बेड करना**](https://www.corbado.com/blog/payment-provider-passkeys-third-party-sdk#51-strategy-a-embedding-a-cross-origin-iframe-pros--cons)
  बताता है कि इनलाइन passkey क्रिएशन और लॉगिन को कैसे संभालना है, यहाँ पेश की गई
  `Permissions-Policy` सेटिंग्स का संदर्भ देते हुए।
- [**रणनीति B: व्यापक कम्पैटिबिलिटी के लिए रीडायरेक्ट-आधारित दृष्टिकोण**](https://www.corbado.com/blog/payment-provider-passkeys-third-party-sdk#52-strategy-b-redirect-based-approach-for-broader-compatibility)
  एक सरल इंटीग्रेशन दिखाता है जो अधिकांश क्रॉस-ओरिजिन नुकसानों को दरकिनार करता है, हालांकि
  मर्चेंट के डोमेन को छोड़ने की कीमत पर।
- [**सिस्टम WebView**](https://www.corbado.com/blog/payment-provider-passkeys-third-party-sdk#63-using-system-webview-or-redirect-for-third-party-passkeys)
  नेटिव ऐप्स के लिए आवश्यक है, क्योंकि एम्बेडेड WebViews अक्सर थर्ड-पार्टी passkey प्रवाह
  को तोड़ देते हैं।

यह पूरक गाइड लेनदेन को सुरक्षित करने, Safari के क्रॉस-ओरिजिन प्रतिबंधों को दूर करने और 3rd
पार्टी संदर्भों में passkey उपयोग को अनुकूलित करने के लिए **गहन रणनीतियाँ** प्रदान करता
है। इस लेख में तकनीकी चरणों को उन पेमेंट-केंद्रित तरीकों के साथ जोड़कर, आप सीधे एक iframe
के अंदर एक घर्षण रहित, फ़िशिंग-प्रतिरोधी चेकआउट प्रवाह प्रदान कर सकते हैं जो ऑनलाइन
[पेमेंट्स](https://www.corbado.com/passkeys-for-payment) के लिए सुरक्षा और UX के अगले स्तर को अनलॉक करता है।

## 8. निष्कर्ष

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

वास्तविक दुनिया के कार्यान्वयन, जैसे कि
[Shopify का अपने लॉगिन कंपोनेंट में passkeys का इंटीग्रेशन](https://shopify.engineering/supporting-passkeys-in-shop-authentication-flows),
इस दृष्टिकोण के व्यावहारिक लाभ और लचीलेपन को प्रदर्शित करते हैं।