--- url: 'https://www.corbado.com/ja/blog/iframe-passkeys-webauthn' title: 'パスキーとiframe：パスキーを作成してログインする方法は？' description: 'このガイドでは、クロスオリジンiframeでパスキーを作成し、ログインする方法を解説します。WebAuthnにおけるiframe、セキュリティポリシー、実装について学びましょう。' lang: 'ja' author: 'Vincent Delitz' date: '2025-07-15T13:22:31.482Z' lastModified: '2026-08-29T06:02:12.188Z' keywords: 'iframe, クロスオリジン, パスキー' category: 'WebAuthn Know-How' --- # パスキーとiframe：パスキーを作成してログインする方法は？ ### クイックリファレンス：クロスオリジンでのパスキーサポート（2025年7月時点） | ブラウザ | **クロスオリジンでのログイン**
(`navigator.credentials.get`) | **クロスオリジンでの作成**
(`navigator.credentials.create`) | | --------------- | -------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------- | | **Chrome/Edge** | ✅ [Chrome 84 (2020年7月)](https://blog.chromium.org/2020/05/chrome-84-beta-web-otp-web-animations.html) | ✅ [Chrome 123 (2024年3月)](https://groups.google.com/a/chromium.org/g/blink-dev/c/Sq2WAVbPz6g) | | **Firefox** | ✅ [Firefox 118 (2023年9月)](https://bugzilla.mozilla.org/show_bug.cgi?id=1460986) | ✅ [Firefox 123 (2024年2月)](https://bugzilla.mozilla.org/show_bug.cgi?id=1870863) | | **Safari** | ✅ [Safari 15.5 (2022年5月)](https://bugs.webkit.org/show_bug.cgi?id=222240) | ❌ [未対応](#62-challenge-2-cross-origin-iframe-issues-with-safari) | **凡例**\ ✅ = 対応済み ❌ = 未対応 ## 1. はじめに：iframeでパスキーを使用する方法は？ 毎週のように、ますます多くの組織がパスキーの導入を発表しています（最近では[Visa](https://www.corbado.com/blog/visa-passkeys)、[Mastercard](https://www.corbado.com/blog/mastercard-passkeys)、[Vercel](https://www.corbado.com/blog/vercel-passkeys)など）。他の企業の開発者やプロダクトマネージャーも、こうした先進事例に倣って、パスキー実装のユースケースをさらに検討するようになっています。 私たちが絶えず質問を受けるケースの1つが、**iframeでパスキーがどのように機能するか**です。[iframe](https://www.corbado.com/blog/iframe-passkeys-webauthn)は、異なるソースからのコンテンツをシームレスに埋め込むために、現代のWeb開発で広く使用されています。パスキーとWebAuthnの文脈では、[iframe](https://www.corbado.com/blog/iframe-passkeys-webauthn)には特有の課題があり、特にセキュリティとユーザーインタラクションに関して注意が必要です。 この記事では、**iframeでパスキーとWebAuthnを使用するための包括的なガイド**を提供します。ここでは、以下の点について解説します。 - 現在の機能を探る - クロスオリジン[iframe](https://www.corbado.com/blog/iframe-passkeys-webauthn)のサポートについて議論する - iframe統合の利点を強調する - ステップバイステップの実装ガイドを提供する この記事を読み終える頃には、iframe内でパスキーを活用する方法を明確に理解できるでしょう。 ## 2. iframeの種類 iframe（インラインフレーム）は、現在のドキュメント内に別のHTMLドキュメントを埋め込むことを可能にするHTML要素です。この機能は、動画、地図、その他のWebページなど、外部ソースからのコンテンツをWebサイトに組み込むために広く使用されています。 それでは、さまざまな種類のiframeを見ていきましょう。 ### 2.1 基本的なiframe **基本的なiframe**は、最も一般的に使用されるタイプです。現在のページ内に別のURLからのコンテンツを単純に埋め込みます。 `` この基本的なiframeは、記事のような静的なコンテンツをWebページに含めるためによく使用されます。 ### 2.2 レスポンシブiframe **レスポンシブiframe**は、画面サイズや配置されたコンテナに基づいてサイズを調整するように設計されています。これにより、埋め込まれたコンテンツがデスクトップ、タブレット、携帯電話など、すべてのデバイスで見栄えが良くなります。 `` CSSのメディアクエリを使用して、ビューポートサイズに基づいてiframeを動的に調整することもできます。 ### 2.3 セキュアなiframe（サンドボックス化されたiframe） **セキュアなiframe、またはサンドボックス化されたiframe**は、iframe内で実行できるアクションを制限します。これは、信頼できないソースからのコンテンツを埋め込む場合や、セキュリティを強化する場合に役立ちます。 ` ` **sandbox**属性には、次のようなさまざまな制限を含めることができます。 `` **sandbox**属性は、スクリプトの実行を許可しますが、フォームの送信やプラグインの使用など、潜在的に危険なアクションを制限します。 ### 2.4 クロスオリジンiframe / クロスサイトiframe クロスオリジンiframeは、異なるドメインのコンテンツを埋め込みます。これらは、決済ゲートウェイやソーシャルメディアウィジェットなど、サードパーティのサービスを統合するためによく使用されます。セキュリティ上の制限により、これらのiframeは埋め込みページのコンテンツへのアクセスが制限されており、その逆も同様です。 **クロスオリジンとは、読み込まれるコンテンツが異なるオリジンからのものであること**を意味します。オリジンは、スキーム（プロトコル）、ホスト（ドメイン）、ポート番号の組み合わせによって定義されます。たとえば、`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)\*\*でホストされているWebページに埋め込む場合。これらはドメインが異なるため、クロスオリジンです。 **同一オリジンの例：** \*\*[https://www.example.com/shop](https://www.example.com/shop)**からのコンテンツを、**[https://www.example.com/blog](https://www.example.com/blog)\*\*でホストされているWebページに埋め込む場合。これらはスキーム、ホスト、ポートが同じであるため、同一オリジンです。 クロスオリジンiframeは、ソースが別のドメインからであるという点で基本的なiframeとは異なりますが、同一サイトのiframeは、埋め込まれている場所と同じドメインからソースを取得します。 `` ## 3. iframeはどのようにパスキーをサポートするか？ iframeでパスキーを使用すると、開発者は新たな機能と制約を理解する必要があります。これらは主に、正しい権限を設定し、埋め込みコンテキスト内で安全なユーザーインタラクションを確保することを中心としています。 歴史的に、Web Authentication APIは、主にセキュリティ上の懸念から、クロスオリジンiframeではデフォルトで無効にされていました。この制限により、開発者はユーザーをリダイレクトしたり、認証のためにポップアップウィンドウを使用したりする必要があり、シームレスなユーザーエクスペリエンスとは言えませんでした。 パスキー / WebAuthnには、2つの主要な操作（セレモニーとも呼ばれます）があります。 1. パスキーの登録 / 作成 2. パスキーでの認証 / ログイン この2つの操作は、クロスオリジンiframeで同等にサポートされてきたわけではありません。 当初は、**クロスオリジンiframeを介したログインは可能になりました**が、ユースケースがなかったため、クロスオリジンでの**作成はまだできませんでした**。 最近の進歩（例：[Chrome](https://www.corbado.com/ja/blog/digital-credentials-api) 123）により、**特定の条件下でクロスオリジンiframeでのパスキー作成がサポートされるようになりました**。しかし、2024年5月現在、すべてのブラウザがクロスオリジンiframeを介したパスキーの作成を完全にサポートしているわけではありませんが、ログインはほとんどのブラウザで可能です。 さらに、クロスオリジンiframeのサポート（登録および認証操作）は、進行中の[WebAuthn Level 3](https://www.corbado.com/blog/passkeys-prf-webauthn)仕様にすでに組み込まれています。一部のブラウザ（例：[Safari](https://www.corbado.com/ja/blog/digital-credentials-api)）は、まだ仕様に追いつく必要があります。残念ながら、[Apple](https://www.corbado.com/ja/blog/how-to-enable-passkeys-macos)は[Safari](https://www.corbado.com/ja/blog/digital-credentials-api)内でパスキーのクロスオリジン登録を許可するかどうか、またいつ許可するかをまだ発表していません。これが実現すれば、クロスオリジンiframeでパスキーを使用する上での最も大きな技術的制約が解消されることになります。 ブログ記事の以下の部分では、クロスオリジンiframeの使用を前提としています。 ### 3.1 クロスオリジンiframeでのパスキーによるログイン 以下の表は、クロスオリジンiframeコンテキストでのiframe認証およびパスキーによるiframeログインに関するブラウザ/標準のサポート状況の概要です。 | **ブラウザ/標準** | **ファーストパーティコンテキスト** | **サードパーティコンテキスト** | | ---------------------- | ---------------------------------- | ------------------------------ | | WebAuthn Level 2で必須 | ✔️ | ✔️ | | WebAuthn Level 3で必須 | ✔️ | ✔️ | | Chromeで実装済み | ✔️ | ✔️ | | Firefoxで実装済み | ✔️ | ✔️ | | Safariで実装済み | ✔️ | ✔️ | ### 3.2 クロスオリジンiframeでのパスキー作成 2024年5月現在、クロスオリジンiframeでのパスキー作成は、すべてのブラウザで可能なわけではありません。以下の表は、クロスオリジンiframeでのパスキー登録/作成に関するブラウザ/標準のサポート状況の概要です。 | **ブラウザ/標準** | **ファーストパーティコンテキスト** | **サードパーティコンテキスト** | | ---------------------------------------------------- | ------------------------------------------------------ | -------------------------------------------------------------------- | | 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/ja/blog/digital-credentials-api)で実装済み | ✔️ [詳細](https://issues.chromium.org/issues/40258856) | 実装のシグナル待ち | この開発とサポートの背景についてさらに詳しく知りたい場合は、こちらの[GitHub issue](https://github.com/w3c/webauthn/issues/1656)とこちらの[Pull Request](https://github.com/w3c/webauthn/pull/1801)をご覧になることをお勧めします。 ### 3.3 iframeでのパスキーのユースケース クロスオリジンiframeでパスキーをサポートする主なユースケースは2つあります。 #### 3.3.1 フェデレーションID クロスオリジンiframeでパスキーを有効にすることは、複数のドメインが関与するが同じユーザーアカウントを使用すべきフェデレーションIDのシナリオにとって不可欠です。 [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) しかし、ユーザーがこれらすべてのドメインで同じアカウントと認証情報でログインできる中央のID管理システムがあります。WebAuthn標準は、パスキーが1つのドメイン（リライングパーティ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)に[www.kayak.com](https://www.kayak.com)オリジンのiframeを埋め込みます（クロスオリジンiframe）。そうしないと、パスキーのフィッシング耐性のために、これらの他のドメインで「[www.kayak.com](https://www.kayak.com)」に紐付いたパスキーを使用することができません。 余談ですが、新しいWebAuthn機能であるRelated Origin Requests (RoR)も代替として使用できます。この機能により、「関連するオリジン」がiframeなしでパスキーにアクセスできますが、まだすべてのブラウザでサポートされているわけではありません。 #### 3.3.2 決済 シームレスな決済フローにおいても、クロスオリジンiframeでのパスキーの使用は重要な役割を果たします。次のシナリオを考えてみましょう。顧客がマーチャントのWebサイト（例：[www.amazon.com](http://www.amazon.com)）で新しい靴を購入したいとします。このマーチャントのWebサイトでは、顧客が銀行口座（例：[www.revolut.com](http://www.revolut.com)）経由で支払うことができ、そのためにはユーザーが銀行のWebサイトにログインする必要があります（これは簡略化されたプロセスです）。ユーザーは、銀行のリライングパーティID（例：「[revolut](https://www.corbado.com/blog/revolut-passkeys).com」）に紐付いたパスキーで銀行のWebサイトにログインします。 チェックアウトプロセス中にユーザーをマーチャントのWebサイト（[www.amazon.com](https://www.amazon.com)）から銀行のWebサイト（[www.revolut.com](https://www.revolut.com)）にリダイレクトさせ、そこで銀行口座にログインさせるのを避けるために、クロスオリジンiframeを使用できます。これにより、ユーザーは[www.amazon.com](https://www.amazon.com)に留まり、[www.revolut.com](https://www.revolut.com)用に作成したパスキーをクロスオリジンiframe内で認証に使用します。 したがって、クロスオリジンiframeを介してパスキーを決済フローに統合することで、消費者、マーチャント、銀行の間で安全かつ合理化された取引が保証されます。 | **消費者** | **マーチャント** | **銀行** | | ---------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | | | | 決済とパスキーの文脈では、[Secure Payment Confirmation](https://www.corbado.com/blog/dynamic-linking-passkeys-spc) (SPC)とパスキーによる動的リンキングに関するブログ記事もご覧になることをお勧めします。また、ネイティブアプリにおけるサードパーティコンテキストの制限についても、以下で必ずご確認ください。 さらに、パスキーを使用したクロスオリジン決済フローの詳細については、決済プロバイダー向けパスキー：サードパーティSDKの構築方法をご覧ください。 ## 4. iframeでパスキーを使用する利点 一般的に、iframe内にパスキーを統合することは、主にUXとセキュリティを向上させることで、いくつかの利点をもたらします。以下にこれらの利点をまとめます。 **ユーザーエクスペリエンスの向上** 1. **ポップアップやリダイレクトが不要：** ユーザーはリダイレクトやポップアップなしで、埋め込みコンテンツ内で直接認証できるため、よりスムーズで中断の少ない体験が実現します。 2. **サイト間での一貫したUX：** 認証フローをiframe内に埋め込むことで、Webサイトの異なるセクション間や、同じ認証サービスを使用する異なるWebサイト間で一貫したユーザーエクスペリエンスが保証されます。 **セキュリティの向上** 1. **安全な取引：** 決済のようなシナリオでは、iframe内のパスキーは、安全な埋め込みコンテキスト内で認証が行われることを保証することで、取引のセキュリティを強化します。 2. **異なるWebサイトでのユーザーアカウントの使用：** フェデレーションIDの設定では、クロスオリジンiframe内のパスキーにより、複数のドメイン間で安全かつ効率的な本人確認が可能になります。 ## 5. iframeにパスキーを実装するためのステップバイステップガイド iframeにパスキーを実装するには、セキュリティと機能性を確保するためのいくつかの重要なステップが含まれます。開発者向けに詳細なガイドを提供します。また、[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でパスキーログインを有効にするには、[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})`）とパスキーの作成（`navigator.credentials.create({publicKey})`）に必要なWebAuthn APIメソッドを呼び出すことができます。 `` HTTPの`Permissions Policy`は、以前は`Feature Policy`と呼ばれていました。`Feature Policy`では、ヘッダーのオリジンリストにオリジンを追加するか、iframeタグに`allow`属性を含めることで、クロスオリジンiframeに機能を付与できました。`Permissions Policy`では、オリジンリストにクロスオリジンフレームを追加するには、そのオリジンのiframeタグに`allow`属性を含める必要があります。レスポンスに`Permissions Policy`ヘッダーがない場合、オリジンリストはデフォルトで`*`（すべてのオリジン）になります。iframeに`allow`属性を含めると、その機能へのアクセスが許可されます。 オリジンリストに指定されていないクロスオリジンiframeが、`allow`属性が存在する場合でも機能にアクセスできないようにするために、開発者はレスポンスで`Permissions Policy`ヘッダーを明示的に設定できます。 [Chrome](https://www.corbado.com/ja/blog/digital-credentials-api) 88以降では、`Feature Policy`も使用できますが、`Permissions Policy`のエイリアスとして機能します。構文の違いを除けば、ロジックは同じです。`Permissions Policy`と`Feature Policy`の両方のヘッダーが同時に使用された場合、`Permissions Policy`ヘッダーが優先され、`Feature Policy`ヘッダーによって設定された値を上書きします。実装の詳細については、[Chrome](https://www.corbado.com/ja/blog/digital-credentials-api)チームによるこのブログ記事も参照してください。 ### 5.2 HTTPヘッダーの設定 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")` ### 5.3 ユーザーアクティベーションの処理 iframeコンテンツがパスキー認証をトリガーするためにユーザーのアクションを必要とすることを確認してください。これは、iframe内のクリックやフォーム送信に対するイベントリスナーを使用して行うことができます。このプロセスは、一時的なアクティベーションとも呼ばれます。 ```javascript document.getElementById("loginPasskeyButton").addEventListener("click", async () => { try { const 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)を介してパスキー用のクロスオリジンiframeを使用しています。 ```html Cross-Origin iframe with Passkeys Demo

Cross-Origin iframe with Passkeys Demo

``` ## 6. 一般的な課題とその克服方法 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.”** パーミッションポリシーを正しく追加しないと、ブラウザは次のエラーをスローします。 ![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レスポンスヘッダーの両方に含まれていることを再確認してください。 - **Webサーバーヘッダーの代わりにメタヘッダーを使用する：** Webサーバーでヘッダーを設定する代わりに、``ヘッダーを使用してパーミッションポリシーを定義します。 - **Permissions-Policyでコンマの代わりにセミコロンを使用する：** 以前、`Permissions-Policy`は`Feature-Policy`と呼ばれていました。`Feature-Policy`の単一要素はセミコロンではなくコンマで区切られていました（これは`Permissions-Policy`の標準です）。iframeの`Permissions-Policy`は依然として`Feature-Policy`の構文に従っているため、コンマを使用します。ただし、sandbox / `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でのパスキー作成またはパスキーログインが機能せず、ブラウザのコンソールに次のエラーが表示される。 **"NotAllowedError - The origin of the document is not the same as its ancestors."** このエラーは、Safariブラウザを使用してiframe内からパスキーを作成しようとすると表示されます。Safariはクロスオリジンiframeでのパスキー作成をサポートしていないためです（上記参照）。 ![passkey iframe not allowed error](https://www.corbado.com/website-assets/passkey_iframe_not_allowed_error_a217258310.png) **解決策：** Safariはまだクロスオリジン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.** このエラーはパスキーに直接関連するものではなく、Safariでのクロスオリジンiframe全般に関連するものです。Safari / WebKitのサードパーティCookieのブロックやサードパーティコンテキストでのLocalStorageへのアクセスをブロックする取り組みの一環として、JavaScriptロジックの一部が壊れる可能性があります。 ![passkey iframe third party cookie](https://www.corbado.com/website-assets/passkey_iframe_third_party_cookie_199bb288c3.png) **解決策：** ここでは、iframe内でサードパーティCookieを使用していないことを確認する必要があります。これがエラーの原因となります。 ### 6.3 課題3：ブラウザの互換性 **問題：** ブラウザによってWebAuthn、iframeの権限、セキュリティ属性のサポートレベルが異なるため、一貫性のない動作につながり、iframeのブラウザ互換性の問題が発生します。 **解決策：** これらのiframeブラウザ互換性の問題を軽減するには、複数のブラウザで実装をテストして互換性を確保し、ブラウザ固有の問題を特定します。 **手順：** 1. BrowserStackやSauce Labsなどのツールを使用して、クロスブラウザテストを実施します。 2. ブラウザ固有の修正やフォールバックを実装して、不一致に対処します。 ### 6.4 課題4：ネイティブアプリ内のiframe **問題：** ネイティブアプリ内でパスキーを必要とするiframeを使用する場合、**ファーストパーティ**と**サードパーティ**のコンテキストを明確に区別する必要があります。 - **ファーストパーティコンテキスト**：パスキーは、アプリを運営する会社と同じドメインに紐付けられています。例えば、ユーザー認証に自社ドメインを利用するeコマースアプリなどです。 - **サードパーティコンテキスト**：異なるドメイン（例：決済プロバイダーやIDプロバイダー）がパスキーの作成やログインフローを処理します。 [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)などの\*\*埋め込み[WebView](https://www.corbado.com/blog/native-app-passkeys)（EWV）\*\*では、呼び出し元のアプリがWebセッションを広範囲に制御できます（例：リクエストの傍受）。この設定は通常、パスキーのドメイン（リライングパーティID）がアプリのドメインと一致する場合（ファーストパーティ）にのみパスキーをサポートします。しかし、決済プロバイダーのクロスオリジンフローのようなサードパーティのシナリオでは、マーチャントのアプリと決済プロバイダーのサービスはオリジンが異なるため、埋め込み[WebView](https://www.corbado.com/blog/native-app-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)のCustom Tabs）を採用しています。システムWebViewは、サードパーティのサイト（例：決済プロバイダー）を安全なブラウザのような環境に分離し、ブラウザ自体がサポートしていればクロスオリジンのパスキーを正しく許可します。ただし、**Safariの既存のiframeの制限**は[ASWebAuthenticationSession](https://www.corbado.com/blog/native-app-passkeys)にも適用されるため、Safariがサードパーティのiframeで特定のパスキー操作を許可しない場合、システムWebViewでも同様のことが言えます。現在、「ネイティブ」な修正方法はありません。外部の決済プロバイダーが関与する**複雑なフロー**（チェックアウトなど）のベストプラクティスは、埋め込みWebViewではなくシステムWebViewを開くことです。 **解決策：** 決済プロバイダー（およびドメイン間でパスキーに依存する他のサードパーティ）は、ユーザーが埋め込みWebViewからシステムWebViewに移動するように、統合を慎重に計画する必要があります。これは純粋な埋め込みフローよりもシームレスさに欠ける体験ですが、サードパーティサービスでパスキー機能が動作することを保証する唯一の方法であることが多いです。 ネイティブアプリやWebView内でサードパーティのパスキーを処理する方法の詳細については、決済プロバイダー向けパスキー：サードパーティパスキー決済SDKをご覧ください。 ## 7. 決済プロバイダー向けの追記：クロスオリジンiframeとサードパーティSDK 上記で説明したトピックはさまざまなシナリオに適用されますが、**特に決済プロバイダーにとって重要**です。決済プロバイダーでは、マルチドメインフロー（例：マーチャントサイトと決済ゲートウェイ）が**クロスオリジンiframe**内にユーザー認証を埋め込む必要があります。これらの設定では、 - **ユーザー**は、リダイレクトポップアップなしで、ページ内で完結する摩擦のないチェックアウトを望んでいます。 - **決済プロバイダー**は、マーチャントのサイトに埋め込まれている場合でも、自社のドメイン（例：`pay.provider.com`）でパスキーの登録またはログインを処理する必要があります。 - **Safariの制約**や**埋め込みWebView**の制限により、iframe内でのサードパーティのパスキー作成がしばしばブロックされます。 これらの課題に取り組み、**Apple Pay**と同様の安全でシームレスな体験を構築するために、決済プロバイダーはしばしば**ハイブリッドアプローチ**を採用します。これは、iframeベースの統合と、Safari（または古いブラウザ）用のリダイレクトフォールバックを組み合わせたものです。場合によっては、埋め込みWebViewがパスキーをまったく許可しない場合、**システムブラウザ**フロー（例：[iOS](https://www.corbado.com/blog/how-to-enable-passkeys-ios)の[ASWebAuthenticationSession](https://www.corbado.com/blog/native-app-passkeys)）が必須になります。 これらの決済固有のシナリオ（**iframe対リダイレクト**の比較、**ネイティブアプリ**の考慮事項、高いパスキー採用率のためのベストプラクティスなど）についての**詳細な解説**については、専用の記事をご覧ください。 特に、 - **戦略A：クロスオリジンiframeの埋め込み**では、ここで紹介した`Permissions-Policy`設定を参照しながら、パスキーの作成とログインをインラインで処理する方法を説明しています。 - **戦略B：幅広い互換性のためのリダイレクトベースのアプローチ**では、ほとんどのクロスオリジンの落とし穴を回避する、よりシンプルな統合を示していますが、マーチャントのドメインを離れるという代償が伴います。 - **システムWebView**は、埋め込みWebViewがサードパーティのパスキーフローを頻繁に壊すため、ネイティブアプリにとって不可欠です。 この補足ガイドは、取引を保護し、Safariのクロスオリジン制限を克服し、サードパーティコンテキストでのパスキー使用を最適化するための**詳細な戦略**を提供します。この記事の技術的な手順と、それらの決済に焦点を当てた方法を組み合わせることで、オンライン決済のセキュリティとUXを次のレベルに引き上げる、摩擦のないフィッシング耐性のあるチェックアウトフローをiframe内で直接提供できます。 ## 8. まとめ iframe内にパスキーを統合することは、セキュリティとユーザーエクスペリエンスの両方を向上させることで、ユーザー認証を大幅に強化します。これにより、リダイレクトやポップアップを必要としないシームレスな認証が可能になり、さまざまなセクションやサイトで一貫したUXが保証されます。 [Shopify](https://www.corbado.com/blog/shopify-passkeys)によるログインコンポーネント内へのパスキーの統合のような実際の導入事例は、このアプローチの実用的な利点と柔軟性を示しています。