--- url: 'https://www.corbado.com/ru/blog/passkeys-iframe-webauthn' title: 'Passkeys и iframes: как создать Passkey и войти с его помощью?' description: 'Узнайте из нашего руководства, как создавать Passkeys и входить в систему с их помощью в междоменных iframe. Мы расскажем об iframe в WebAuthn, политиках безопасности и практической реализации.' lang: 'ru' author: 'Vincent Delitz' date: '2025-07-15T13:22:42.738Z' lastModified: '2026-08-28T12:00:57.790Z' keywords: 'iframe, междоменный, cross-origin' category: 'WebAuthn Know-How' --- # Passkeys и iframes: как создать Passkey и войти с его помощью? ### Краткий справочник: поддержка междоменных Passkeys (июль 2025 г.) | Браузер | **Междоменный вход**
(`navigator.credentials.get`) | **Междоменное создание**
(`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. Введение: как использовать Passkeys в iframe? Неделя за неделей все больше организаций объявляют о внедрении Passkeys (например, недавно это сделали [Visa](https://www.corbado.com/blog/visa-passkeys), [Mastercard](https://www.corbado.com/blog/mastercard-passkeys) или [Vercel](https://www.corbado.com/blog/vercel-passkeys)). По мере того как разработчики и менеджеры продуктов из других компаний следуют этим примерам, обсуждается все больше сценариев применения Passkeys. Один из вопросов, который нам постоянно задают, — это **как Passkeys работают в iframe**, поскольку [iframe](https://www.corbado.com/blog/iframe-passkeys-webauthn) широко используются в современной веб-разработке для бесшовного встраивания контента из разных источников. В контексте Passkeys и WebAuthn использование [iframe](https://www.corbado.com/blog/iframe-passkeys-webauthn) сопряжено с рядом проблем, особенно в части безопасности и взаимодействия с пользователем. Эта статья представляет собой **исчерпывающее руководство по использованию Passkeys и WebAuthn в iframe**. Мы: - изучим текущие возможности; - обсудим поддержку междоменных [iframe](https://www.corbado.com/blog/iframe-passkeys-webauthn); - выделим преимущества интеграции с iframe и - предоставим пошаговое руководство по реализации. Прочитав эту статью, вы получите четкое представление о том, как эффективно использовать Passkeys внутри iframe. ## 2. Типы iframe iframe, или встроенные фреймы, — это HTML-элементы, которые позволяют разработчикам встраивать один HTML-документ внутрь другого. Эта возможность широко используется для включения контента из внешних источников, таких как видео, карты и другие веб-страницы, на сайт. Давайте рассмотрим различные типы iframe. ### 2.1 Базовый iframe **Базовый iframe** — это наиболее распространенный тип. Он просто встраивает контент с другого URL-адреса на текущую страницу. `` Такой iframe часто используется для включения статического контента, например статьи, на веб-страницу. ### 2.2 Адаптивный iframe **Адаптивные iframe** спроектированы так, чтобы их размер подстраивался под размер экрана или контейнера, в котором они находятся. Это гарантирует, что встроенный контент будет хорошо выглядеть на всех устройствах, включая настольные компьютеры, планшеты и мобильные телефоны. `` Также можно использовать медиазапросы CSS, чтобы iframe динамически подстраивался под размер области просмотра. ### 2.3 Безопасный iframe (iframe в «песочнице») **Безопасный iframe, или iframe в «песочнице» (sandboxed iframe)**, ограничивает действия, которые можно выполнять внутри него. Это полезно для встраивания контента из ненадежных источников или для повышения безопасности. ` ` Атрибут **sandbox** может включать различные ограничения, например: `` Атрибут **sandbox** позволяет запускать скрипты, но ограничивает потенциально опасные действия, такие как отправка форм или использование плагинов. ### 2.4 Междоменный iframe / межсайтовый iframe Междоменные iframe (cross-origin iframe) встраивают контент с другого домена. Они часто используются для интеграции сторонних сервисов, таких как [платежные](https://www.corbado.com/passkeys-for-payment) шлюзы или виджеты социальных сетей. Из-за ограничений безопасности такие iframe имеют ограниченный доступ к содержимому встраивающей страницы, и наоборот. **Междоменный (cross-origin) означает, что загружаемый контент поступает из другого источника (origin)**, где источник определяется комбинацией схемы (протокола), хоста (домена) и номера порта. Например, `https://example.com` и `http://example.com` считаются разными источниками, потому что они используют разные схемы (HTTP и HTTPS). Аналогично, поддомены рассматриваются как отдельные источники по отношению к их родительским доменам. Например, `https://example.com` и `https://sub.example.com` являются междоменными, хотя у них общий базовый домен. Такое разделение гарантирует, что скрипты и данные с одного поддомена не могут напрямую взаимодействовать с данными другого без явного разрешения, что повышает безопасность. Вот примеры, иллюстрирующие концепции междоменного и однодоменного происхождения: **Пример междоменного (cross-origin) iframe:** Встраивание контента с **[https://payment.example.com](https://payment.example.com)** на веб-страницу, размещенную на **[https://www.mystore.com](https://www.mystore.com)**. Они являются междоменными, так как у них разные домены. **Пример однодоменного (same-origin) iframe:** Встраивание контента с **[https://www.example.com/shop](https://www.example.com/shop)** на веб-страницу, размещенную на **[https://www.example.com/blog](https://www.example.com/blog)**. Они являются однодоменными, так как у них одинаковые схема, хост и порт. Междоменные iframe отличаются от базовых тем, что их источник находится на другом домене, в то время как у односайтового iframe источник находится на том же домене, куда он встроен. `` ## 3. Как iframe поддерживают Passkeys? Использование Passkeys в iframe открывает новые возможности и накладывает ограничения, которые разработчикам необходимо понимать. В основном это касается установки правильных разрешений и обеспечения безопасного взаимодействия пользователя во встроенном контексте. Исторически Web Authentication API был по умолчанию отключен в междоменных iframe, в первую очередь из соображений безопасности. Это ограничение означало, что разработчикам приходилось перенаправлять пользователей или использовать всплывающие окна для аутентификации, что ухудшало пользовательский опыт. В Passkeys / WebAuthn есть две основные операции (также называемые церемониями): 1. Регистрация / создание Passkey 2. Аутентификация / вход с помощью Passkey Эти две операции поддерживались и поддерживаются в междоменных iframe по-разному: Сначала **стала возможной аутентификация через междоменные iframe**, но **создание ключа в таком контексте еще не было доступно**, потому что не было никого с подходящим сценарием использования. Недавние улучшения (например, в [Chrome](https://www.corbado.com/ru/blog/client-hints-user-agent-chrome-safari-firefox) 123) **добавили поддержку создания Passkeys в междоменных iframe** при определенных условиях. Однако на май 2024 года не все браузеры полностью поддерживают создание Passkeys через междоменные iframe, хотя вход возможен в большинстве из них. Более того, поддержка междоменных iframe (для операций регистрации и аутентификации) уже включена в разрабатываемую спецификацию [WebAuthn Level 3](https://www.corbado.com/blog/passkeys-prf-webauthn). Некоторым браузерам (например, [Safari](https://www.corbado.com/ru/blog/client-hints-user-agent-chrome-safari-firefox)) еще предстоит догнать спецификацию. К сожалению, Apple пока не объявила, разрешит ли и когда разрешит междоменную регистрацию Passkeys в [Safari](https://www.corbado.com/ru/blog/client-hints-user-agent-chrome-safari-firefox). Это сняло бы самое значительное техническое ограничение на использование Passkeys в междоменных iframe. В следующих частях статьи мы будем исходить из того, что используются междоменные iframe. ### 3.1 Вход с помощью Passkeys в междоменных iframe Следующие таблицы дают обзор поддержки браузерами/стандартами аутентификации в iframe и входа с помощью Passkeys в контексте междоменных iframe: | **Браузер/Стандарт** | **Контекст основного домена (First-Party)** | **Контекст стороннего домена (Third-Party)** | | ---------------------------- | ------------------------------------------- | -------------------------------------------- | | Требуется в WebAuthn Level 2 | ✔️ | ✔️ | | Требуется в WebAuthn Level 3 | ✔️ | ✔️ | | Реализовано в Chrome | ✔️ | ✔️ | | Реализовано в Firefox | ✔️ | ✔️ | | Реализовано в Safari | ✔️ | ✔️ | ### 3.2 Создание Passkeys в междоменных iframe На май 2024 года создание Passkey в междоменном iframe возможно еще не во всех браузерах. Следующая таблица дает обзор поддержки браузерами/стандартами регистрации/создания Passkeys в междоменных iframe: | **Браузер/Стандарт** | **Контекст основного домена (First-Party)** | **Контекст стороннего домена (Third-Party)** | | ------------------------------------------------------------------------------ | ----------------------------------------------------------- | ------------------------------------------------------------------------- | | Требуется в 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://www.corbado.com/ru/blog/client-hints-user-agent-chrome-safari-firefox) | ✔️ [Подробнее](https://issues.chromium.org/issues/40258856) | Ожидается решение о реализации | Если вас интересует более подробная информация об этой разработке и поддержке, рекомендуем ознакомиться с этим [issue на GitHub](https://github.com/w3c/webauthn/issues/1656) и этим [Pull Request](https://github.com/w3c/webauthn/pull/1801). ### 3.3 Сценарии использования Passkeys в iframe Существует два основных сценария использования Passkeys в междоменных iframe. #### 3.3.1 Федеративная идентификация Включение Passkeys в междоменных iframe имеет решающее значение для сценариев федеративной идентификации, где задействовано несколько доменов, но должны использоваться одни и те же учетные записи пользователей. Рассмотрим следующий сценарий. Вы — международная компания, как [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). Чтобы преодолеть эту проблему, вы бы использовали iframe с источником [www.kayak.com](https://www.kayak.com) на всех остальных своих доменах. То есть вы встраиваете iframe с источником [www.kayak.com](https://www.kayak.com) на [www.kayak.us](https://www.kayak.us) и на [www.kayak.de](https://www.kayak.de) (междоменный iframe). В противном случае использование ваших Passkeys, привязанных к «[www.kayak.com](https://www.kayak.com)», на этих других доменах было бы невозможно из-за устойчивости Passkeys к фишингу. К слову: в качестве альтернативы можно было бы использовать новую функцию WebAuthn [Related Origin Requests (RoR)](https://passkeys.dev/docs/advanced/related-origins/). Эта функция позволяет «связанным источникам» получать доступ к Passkeys без iframe, но пока она поддерживается не всеми браузерами. #### 3.3.2 Платежи Для бесшовных [платежных](https://www.corbado.com/passkeys-for-payment) потоков использование Passkeys в междоменных iframe также играет важную роль. Рассмотрим следующий сценарий: клиент хочет купить новые туфли на сайте продавца (например, [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). Таким образом, интеграция Passkeys через междоменные iframe в [платежные](https://www.corbado.com/passkeys-for-payment) потоки обеспечивает безопасные и оптимизированные транзакции между потребителями, продавцами и банками: | **Потребители** | **Продавцы** | **Банки** | | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | | | | В контексте платежей и Passkeys мы также рекомендуем ознакомиться с нашей статьей о [Secure Payment Confirmation](https://www.corbado.com/blog/dynamic-linking-passkeys-spc) (SPC) и динамической привязке с помощью Passkeys. Обязательно обратите внимание на ограничения для стороннего контекста в нативных приложениях, описанные ниже. Кроме того, для более глубокого понимания междоменных платежных потоков с использованием Passkeys, см. нашу статью Passkeys для платежных провайдеров: как создать сторонний SDK. ## 4. Преимущества использования Passkeys в iframe В целом, интеграция Passkeys в iframe дает несколько преимуществ, в основном за счет улучшения пользовательского опыта и безопасности. Вот разбивка этих преимуществ: **Улучшенный пользовательский опыт** 1. **Никаких всплывающих окон или перенаправлений:** Пользователи могут проходить аутентификацию непосредственно во встроенном контенте без перенаправлений или всплывающих окон, что делает процесс более плавным и менее навязчивым. 2. **Единообразный UX на разных сайтах:** Встраивание потоков аутентификации в iframe обеспечивает единообразный пользовательский опыт в разных разделах веб-сайта или на разных сайтах, использующих один и тот же сервис аутентификации. **Повышенная безопасность** 1. **Безопасные транзакции:** В таких сценариях, как платежи, Passkeys в iframe повышают безопасность транзакций, гарантируя, что аутентификация происходит в безопасном, встроенном контексте. 2. **Использование одной учетной записи на разных сайтах:** В системах федеративной идентификации Passkeys в междоменных iframe позволяют безопасно и эффективно проверять личность на нескольких доменах. ## 5. Пошаговое руководство по реализации Passkeys в iframe Реализация Passkeys в iframe включает несколько ключевых шагов для обеспечения безопасности и функциональности. Мы предоставляем подробное руководство для разработчиков. Пожалуйста, ознакомьтесь также с примером реализации на [https://cross-origin-iframe.vercel.app/](https://cross-origin-iframe.vercel.app/). ![Демонстрация Passkey в междоменном iframe](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. Чтобы включить вход с помощью Passkey в iframe, вы должны установить **политики разрешений** [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). Эти политики позволяют встроенному контенту вызывать необходимые методы WebAuthn API для аутентификации (`navigator.credentials.get({publicKey})`) и создания Passkey (`navigator.credentials.create({publicKey})`). `` HTTP `Permissions Policy` ранее называлась `Feature Policy`. В рамках `Feature Policy` можно было предоставить доступ к функции междоменному iframe, либо добавив источник в список источников заголовка, либо включив атрибут `allow` в тег iframe. С `Permissions Policy` добавление междоменного фрейма в список источников требует, чтобы тег iframe для этого источника также включал атрибут `allow`. Если в ответе отсутствует заголовок `Permissions Policy`, список источников по умолчанию равен `*` (все источники). Включение атрибута `allow` в iframe предоставляет доступ к функции. Чтобы гарантировать, что междоменные iframe, не указанные в списке источников, будут заблокированы от доступа к функции, даже если присутствует атрибут `allow`, разработчики могут явно установить заголовок `Permissions Policy` в ответе. В [Chrome](https://www.corbado.com/ru/blog/client-hints-user-agent-chrome-safari-firefox) 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-заголовки Убедитесь, что HTTP-заголовки ответа от URL-адреса источника iframe включают соответствующую ´[Permissions-Policy](https://www.corbado.com/faq/enable-passkeys-iframe)\`. Это критически важно для поддержки междоменных 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. Этот процесс также называется [временной активацией (transient activation)](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) = { /* Параметры конфигурации */ }; const credential = await navigator.credentials.get({publicKey: publicKeyCredentialRequestOptions}); // Обработка созданных учетных данных } catch (err) { console.error('Ошибка аутентификации через Passkey:', err); } }); ``` В этом контексте также ознакомьтесь с нашей статьей о требованиях к жестам пользователя в Safari. ### 5.4 Пример реализации Ниже вы найдете полный пример кода файла `index.html`, размещенного на [https://cross-origin-iframe.vercel.com](https://cross-origin-iframe.vercel.com), который использует междоменный iframe для Passkeys через [https://passkeys.eu](https://passkeys.eu). ```html Демонстрация междоменного iframe с Passkeys

Демонстрация междоменного iframe с Passkeys

``` ## 6. Распространенные проблемы и способы их решения При реализации Passkeys в iframe могут возникнуть проблемы, которые разработчикам необходимо решить для обеспечения плавного и безопасного пользовательского опыта. Вот подробный разбор распространенных проблем и способов их преодоления. ### 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.»** Если вы неправильно добавите политики разрешений, браузер выдаст следующую ошибку: ![конфигурация политики разрешений для iframe с passkey](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-заголовки ответа сервера. - **Мета-заголовки вместо заголовков веб-сервера:** Используйте мета-теги `` для определения политик разрешений вместо установки заголовков на вашем веб-сервере. - **Точка с запятой вместо запятой в Permissions-Policy:** Ранее `Permissions-Policy` называлась `Feature-Policy`. Отдельные элементы `Feature-Policy` разделялись запятой, а не точкой с запятой (что является стандартом для `Permissions-Policy`). `Permissions-Policy` в iframe все еще следует синтаксису `Feature-Policy` и, таким образом, использует запятые. Однако атрибуты `sandbox` / `allow` по-прежнему разделяются точкой с запятой (см. фрагмент кода выше). **Совет:** Чтобы правильно проверить, что ваши заголовки `Permission-Policy` установлены верно, мы рекомендуем открыть инструменты разработчика вашего браузера, перейти в **Application** (здесь: в инструментах разработчика [Chrome](https://www.corbado.com/ru/blog/client-hints-user-agent-chrome-safari-firefox)), затем в **Frames** и найти источник iframe (здесь: passkeys.eu/). Если `Permissions-Policy` установлена правильно, `publickey-credential-create` и `publickey-credential-get` должны быть перечислены среди **Разрешенных функций (Allowed Features)**: ![разрешенные функции политики разрешений для passkey](https://www.corbado.com/website-assets/passkey_permissions_policy_allowed_features_ffadbc4302.png) ### 6.2 Проблема 2: Проблемы с междоменными iframe в Safari **Проблема:** Создание Passkey или вход с помощью Passkey в междоменном iframe не работает, и вы видите следующую ошибку в консоли браузера. **"NotAllowedError - The origin of the document is not the same as its ancestors."** Эта ошибка появляется при использовании браузера Safari и попытке создать Passkey из iframe, поскольку Safari не поддерживает создание Passkey в междоменном iframe (см. выше). ![ошибка not allowed в iframe с passkey](https://www.corbado.com/website-assets/passkey_iframe_not_allowed_error_a217258310.png) **Решение:** Здесь вы мало что можете сделать, так как Safari пока не поддерживает создание Passkey из междоменного iframe. **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, а скорее с междоменными iframe в Safari в целом. В рамках [инициативы Safari / WebKit по блокировке сторонних cookie](https://webkit.org/blog/10218/full-third-party-cookie-blocking-and-more/) или доступа к LocalStorage в стороннем контексте, часть логики JavaScript может быть нарушена. ![сторонние cookie в iframe с passkey](https://www.corbado.com/website-assets/passkey_iframe_third_party_cookie_199bb288c3.png) **Решение:** Здесь вам нужно убедиться, что вы не используете сторонние cookie внутри своих iframe, так как это вызывает ошибку. ### 6.3 Проблема 3: Совместимость с браузерами **Проблема:** Проблемы совместимости iframe с браузерами возникают, когда разные браузеры имеют разный уровень поддержки WebAuthn, разрешений iframe и атрибутов безопасности, что приводит к нестабильному поведению. **Решение:** Чтобы смягчить эти проблемы совместимости, протестируйте реализацию в нескольких браузерах, чтобы обеспечить совместимость и выявить любые специфичные для браузера проблемы. **Шаги:** 1. Проведите кросс-браузерное тестирование с помощью таких инструментов, как BrowserStack или Sauce Labs. 2. Устраните любые расхождения, реализовав специфичные для браузера исправления или запасные варианты. ### 6.4 Проблема 4: iframe в нативных приложениях **Проблема:** При использовании iframe, требующих Passkeys, внутри нативных приложений, необходимо делать важное различие между **контекстом основного домена (first-party)** и **сторонним контекстом (third-party)**: - **Контекст основного домена**: Passkeys привязаны к тому же домену, что и у компании, управляющей приложением. Например, приложение для [электронной коммерции](https://www.corbado.com/passkeys-for-e-commerce), которое полагается на свой собственный домен для аутентификации пользователей. - **Сторонний контекст**: Другой домен (например, платежный провайдер или провайдер идентификации) обрабатывает поток создания Passkey или входа в систему. Во **встроенном WebView (EWV)**, таком как [WKWebView](https://www.corbado.com/blog/native-app-passkeys) на [iOS](https://www.corbado.com/blog/how-to-enable-passkeys-ios) или [WebView](https://www.corbado.com/blog/native-app-passkeys) на [Android](https://www.corbado.com/blog/how-to-enable-passkeys-android), вызывающее приложение имеет обширный контроль над веб-сессией (например, может перехватывать запросы). Эта конфигурация обычно поддерживает Passkeys только в том случае, если домен Passkey (Relying Party ID) совпадает с доменом приложения (контекст основного домена). Однако в стороннем сценарии — например, в междоменном потоке платежного провайдера — встроенный [WebView](https://www.corbado.com/blog/native-app-passkeys) обычно не может получить доступ к необходимым учетным данным Passkey, потому что приложение продавца и сервис платежного провайдера имеют разные источники. Требуемые «привязки» для Passkeys (между доменом, учетными данными и источником) не будут совпадать во встроенном контексте. Это ограничение заставляет многие приложения использовать подход с **системным WebView** (например, [ASWebAuthenticationSession](https://www.corbado.com/blog/native-app-passkeys) на [iOS](https://www.corbado.com/blog/how-to-enable-passkeys-ios) или Custom Tabs на [Android](https://www.corbado.com/blog/how-to-enable-passkeys-android)). Системные [WebView](https://www.corbado.com/blog/native-app-passkeys) изолируют сторонний сайт (например, платежного провайдера) в безопасной, похожей на браузер среде, которая корректно разрешает междоменные Passkeys — если сам браузер это поддерживает. Тем не менее, помните, что **существующие ограничения iframe в Safari** также применяются к [ASWebAuthenticationSession](https://www.corbado.com/blog/native-app-passkeys), поэтому, если Safari не разрешает определенные операции с Passkey в сторонних iframe, то же самое будет справедливо и для системного WebView. В настоящее время «нативного» решения нет; лучшая практика для **сложных потоков** — таких как оформление заказа с участием внешних платежных провайдеров — это открывать системный WebView, а не встроенный. **Решение:** Для платежных провайдеров (и других третьих сторон, полагающихся на Passkeys между доменами) тщательно планируйте интеграцию, чтобы убедиться, что пользователь переводится из встроенного WebView в системный. Хотя это менее бесшовный опыт, чем чисто встроенный поток, часто это единственный способ гарантировать, что функциональность Passkey будет работать со сторонними сервисами. Для получения более подробной информации об обработке сторонних Passkeys в нативных приложениях и WebView, ознакомьтесь со статьей Passkeys для платежных провайдеров: сторонний SDK для платежей с Passkeys. ## 7. Дополнительное примечание для платежных провайдеров: междоменные iframe и сторонние SDK Хотя обсуждаемые выше темы применимы к различным сценариям, они **особенно важны для платежных провайдеров**, где многодоменные потоки (например, сайт продавца и платежный шлюз) должны встраивать аутентификацию пользователей в **междоменные iframe**. В таких конфигурациях: - **Пользователи** хотят беспрепятственного оформления заказа на странице без всплывающих окон с перенаправлением. - **Платежные провайдеры** должны обрабатывать регистрацию или вход с помощью Passkey на своем собственном домене (например, `pay.provider.com`), даже если они встроены в сайт продавца. - **Ограничения Safari** и лимиты **встроенных WebView** часто блокируют создание сторонних Passkeys в iframe. Чтобы справиться с этими проблемами и создать безопасный, бесшовный опыт, подобный **Apple Pay**, платежные провайдеры часто применяют **гибридный подход** — сочетая интеграцию на основе iframe с запасным вариантом в виде перенаправления для Safari (или старых браузеров). В некоторых случаях потоки через **системный браузер** (например, [ASWebAuthenticationSession](https://www.corbado.com/blog/native-app-passkeys) на [iOS](https://www.corbado.com/blog/how-to-enable-passkeys-ios)) становятся обязательными, если встроенный WebView вообще не позволяет использовать Passkeys. Для **глубокого погружения** в эти специфичные для платежей сценарии — включая сравнение **iframe и перенаправления**, соображения по **нативным приложениям** и лучшие практики для высокого уровня внедрения Passkeys, см. нашу специальную статью: В частности: - [**Стратегия 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) необходим для нативных приложений, так как встроенные WebView часто нарушают работу сторонних потоков с Passkeys. Это дополнительное руководство предоставляет **углубленные стратегии** для обеспечения безопасности транзакций, преодоления междоменных ограничений Safari и оптимизации использования Passkeys в сторонних контекстах. Сочетая технические шаги из этой статьи с теми методами, которые ориентированы на платежи, вы можете предоставить беспрепятственный, устойчивый к фишингу процесс оформления заказа непосредственно внутри iframe, открывая новый уровень безопасности и UX для онлайн-[платежей](https://www.corbado.com/passkeys-for-payment). ## 8. Заключение Интеграция Passkeys в iframe значительно улучшает аутентификацию пользователей, повышая как безопасность, так и пользовательский опыт. Это позволяет осуществлять бесшовную аутентификацию без необходимости перенаправлений или всплывающих окон, обеспечивая единообразный UX в различных разделах и на разных сайтах. Реальные примеры, такие как [интеграция Passkeys в Shopify](https://shopify.engineering/supporting-passkeys-in-shop-authentication-flows) в их компонент входа, демонстрируют практические преимущества и гибкость этого подхода.