パスキーとiframe：パスキーを作成してログインする方法は？

凡例
✅ = 対応済み ❌ = 未対応

毎週のように、ますます多くの組織がパスキーの導入を発表しています（最近ではVisa、Mastercard、Vercelなど）。他の企業の開発者やプロダクトマネージャーも、こうした先進事例に倣って、パスキー実装のユースケースをさらに検討するようになっています。

私たちが絶えず質問を受けるケースの1つが、iframeでパスキーがどのように機能するかです。iframeは、異なるソースからのコンテンツをシームレスに埋め込むために、現代のWeb開発で広く使用されています。パスキーとWebAuthnの文脈では、iframeには特有の課題があり、特にセキュリティとユーザーインタラクションに関して注意が必要です。

Integrate passkeys as Payment Provider via 3rd party SDK.

Read article

この記事では、iframeでパスキーとWebAuthnを使用するための包括的なガイドを提供します。ここでは、以下の点について解説します。

• 現在の機能を探る
• クロスオリジンiframeのサポートについて議論する
• iframe統合の利点を強調する
• ステップバイステップの実装ガイドを提供する

この記事を読み終える頃には、iframe内でパスキーを活用する方法を明確に理解できるでしょう。

iframe（インラインフレーム）は、現在のドキュメント内に別のHTMLドキュメントを埋め込むことを可能にするHTML要素です。この機能は、動画、地図、その他のWebページなど、外部ソースからのコンテンツをWebサイトに組み込むために広く使用されています。

それでは、さまざまな種類のiframeを見ていきましょう。

Subscribe to our Passkeys Substack for the latest news.

Subscribe

基本的なiframeは、最も一般的に使用されるタイプです。現在のページ内に別のURLからのコンテンツを単純に埋め込みます。

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

この基本的なiframeは、記事のような静的なコンテンツをWebページに含めるためによく使用されます。

レスポンシブiframeは、画面サイズや配置されたコンテナに基づいてサイズを調整するように設計されています。これにより、埋め込まれたコンテンツがデスクトップ、タブレット、携帯電話など、すべてのデバイスで見栄えが良くなります。

<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内で実行できるアクションを制限します。これは、信頼できないソースからのコンテンツを埋め込む場合や、セキュリティを強化する場合に役立ちます。

<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

クロスオリジンiframeは、異なるドメインのコンテンツを埋め込みます。これらは、決済ゲートウェイやソーシャルメディアウィジェットなど、サードパーティのサービスを統合するためによく使用されます。セキュリティ上の制限により、これらのiframeは埋め込みページのコンテンツへのアクセスが制限されており、その逆も同様です。

クロスオリジンとは、読み込まれるコンテンツが異なるオリジンからのものであることを意味します。オリジンは、スキーム（プロトコル）、ホスト（ドメイン）、ポート番号の組み合わせによって定義されます。たとえば、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.

多くの企業がCorbadoを信頼し、パスキーでユーザーを保護し、よりシームレスなログインを実現しています。今すぐ無料のパスキー相談をご利用ください。

無料相談を申し込む

クロスオリジンと同一オリジンの概念を説明するための例を以下に示します。

クロスオリジンの例：

**https://payment.example.comからのコンテンツを、https://www.mystore.com**でホストされているWebページに埋め込む場合。これらはドメインが異なるため、クロスオリジンです。

同一オリジンの例：

**https://www.example.com/shopからのコンテンツを、https://www.example.com/blog**でホストされているWebページに埋め込む場合。これらはスキーム、ホスト、ポートが同じであるため、同一オリジンです。

クロスオリジンiframeは、ソースが別のドメインからであるという点で基本的なiframeとは異なりますが、同一サイトのiframeは、埋め込まれている場所と同じドメインからソースを取得します。

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

iframeでパスキーを使用すると、開発者は新たな機能と制約を理解する必要があります。これらは主に、正しい権限を設定し、埋め込みコンテキスト内で安全なユーザーインタラクションを確保することを中心としています。

歴史的に、Web Authentication APIは、主にセキュリティ上の懸念から、クロスオリジンiframeではデフォルトで無効にされていました。この制限により、開発者はユーザーをリダイレクトしたり、認証のためにポップアップウィンドウを使用したりする必要があり、シームレスなユーザーエクスペリエンスとは言えませんでした。

パスキー / WebAuthnには、2つの主要な操作（セレモニーとも呼ばれます）があります。

1. パスキーの登録 / 作成
2. パスキーでの認証 / ログイン

この2つの操作は、クロスオリジンiframeで同等にサポートされてきたわけではありません。

当初は、クロスオリジンiframeを介したログインは可能になりましたが、ユースケースがなかったため、クロスオリジンでの作成はまだできませんでした。

最近の進歩（例：Chrome 123）により、特定の条件下でクロスオリジンiframeでのパスキー作成がサポートされるようになりました。しかし、2024年5月現在、すべてのブラウザがクロスオリジンiframeを介したパスキーの作成を完全にサポートしているわけではありませんが、ログインはほとんどのブラウザで可能です。

さらに、クロスオリジンiframeのサポート（登録および認証操作）は、進行中のWebAuthn Level 3仕様にすでに組み込まれています。一部のブラウザ（例：Safari）は、まだ仕様に追いつく必要があります。残念ながら、AppleはSafari内でパスキーのクロスオリジン登録を許可するかどうか、またいつ許可するかをまだ発表していません。これが実現すれば、クロスオリジンiframeでパスキーを使用する上での最も大きな技術的制約が解消されることになります。

ブログ記事の以下の部分では、クロスオリジンiframeの使用を前提としています。

Want to find out how many people use passkeys?

View Adoption Data

以下の表は、クロスオリジンiframeコンテキストでのiframe認証およびパスキーによるiframeログインに関するブラウザ/標準のサポート状況の概要です。

2024年5月現在、クロスオリジンiframeでのパスキー作成は、すべてのブラウザで可能なわけではありません。以下の表は、クロスオリジンiframeでのパスキー登録/作成に関するブラウザ/標準のサポート状況の概要です。

この開発とサポートの背景についてさらに詳しく知りたい場合は、こちらのGitHub issueとこちらのPull Requestをご覧になることをお勧めします。

クロスオリジンiframeでパスキーをサポートする主なユースケースは2つあります。

クロスオリジンiframeでパスキーを有効にすることは、複数のドメインが関与するが同じユーザーアカウントを使用すべきフェデレーションIDのシナリオにとって不可欠です。

KAYAKのような多国籍企業で、地域ごとに異なるドメインを持っている次のようなシナリオを考えてみましょう。

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

しかし、ユーザーがこれらすべてのドメインで同じアカウントと認証情報でログインできる中央のID管理システムがあります。WebAuthn標準は、パスキーが1つのドメイン（リライングパーティID）、例えばwww.kayak.comにしか紐付けられないため、これらのシナリオに課題をもたらします。

この課題を克服するために、他のすべてのドメインでオリジンwww.kayak.comからのiframeを使用します。つまり、www.kayak.usとwww.kayak.deにwww.kayak.comオリジンのiframeを埋め込みます（クロスオリジンiframe）。そうしないと、パスキーのフィッシング耐性のために、これらの他のドメインで「www.kayak.com」に紐付いたパスキーを使用することができません。

余談ですが、新しいWebAuthn機能であるRelated Origin Requests (RoR)も代替として使用できます。この機能により、「関連するオリジン」がiframeなしでパスキーにアクセスできますが、まだすべてのブラウザでサポートされているわけではありません。

シームレスな決済フローにおいても、クロスオリジンiframeでのパスキーの使用は重要な役割を果たします。次のシナリオを考えてみましょう。顧客がマーチャントのWebサイト（例：www.amazon.com）で新しい靴を購入したいとします。このマーチャントのWebサイトでは、顧客が銀行口座（例：www.revolut.com）経由で支払うことができ、そのためにはユーザーが銀行のWebサイトにログインする必要があります（これは簡略化されたプロセスです）。ユーザーは、銀行のリライングパーティID（例：「revolut.com」）に紐付いたパスキーで銀行のWebサイトにログインします。

Integrate passkeys as Payment Provider via 3rd party SDK.

Read article

チェックアウトプロセス中にユーザーをマーチャントのWebサイト（www.amazon.com）から銀行のWebサイト（www.revolut.com）にリダイレクトさせ、そこで銀行口座にログインさせるのを避けるために、クロスオリジンiframeを使用できます。これにより、ユーザーはwww.amazon.comに留まり、www.revolut.com用に作成したパスキーをクロスオリジンiframe内で認証に使用します。

したがって、クロスオリジンiframeを介してパスキーを決済フローに統合することで、消費者、マーチャント、銀行の間で安全かつ合理化された取引が保証されます。

決済とパスキーの文脈では、Secure Payment Confirmation (SPC)とパスキーによる動的リンキングに関するブログ記事もご覧になることをお勧めします。また、ネイティブアプリにおけるサードパーティコンテキストの制限についても、以下で必ずご確認ください。

さらに、パスキーを使用したクロスオリジン決済フローの詳細については、決済プロバイダー向けパスキー：サードパーティSDKの構築方法をご覧ください。

一般的に、iframe内にパスキーを統合することは、主にUXとセキュリティを向上させることで、いくつかの利点をもたらします。以下にこれらの利点をまとめます。

ユーザーエクスペリエンスの向上

1. ポップアップやリダイレクトが不要： ユーザーはリダイレクトやポップアップなしで、埋め込みコンテンツ内で直接認証できるため、よりスムーズで中断の少ない体験が実現します。
2. サイト間での一貫したUX： 認証フローをiframe内に埋め込むことで、Webサイトの異なるセクション間や、同じ認証サービスを使用する異なるWebサイト間で一貫したユーザーエクスペリエンスが保証されます。

セキュリティの向上

1. 安全な取引： 決済のようなシナリオでは、iframe内のパスキーは、安全な埋め込みコンテキスト内で認証が行われることを保証することで、取引のセキュリティを強化します。
2. 異なるWebサイトでのユーザーアカウントの使用： フェデレーションIDの設定では、クロスオリジンiframe内のパスキーにより、複数のドメイン間で安全かつ効率的な本人確認が可能になります。

iframeにパスキーを実装するには、セキュリティと機能性を確保するためのいくつかの重要なステップが含まれます。開発者向けに詳細なガイドを提供します。また、https://cross-origin-iframe.vercel.app/にある実装例も参照してください。

HTTPのPermissions-Policyヘッダーは、ドキュメント内またはiframe要素内で特定のブラウザ機能の使用を許可または拒否するのに役立ちます。iframeでパスキーログインを有効にするには、publickey-credentials-getとpublickey-credentials-createのパーミッションポリシーを設定する必要があります。このポリシーにより、埋め込みコンテンツは、パスキーでの認証（navigator.credentials.get({publicKey})）とパスキーの作成（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属性を含めると、その機能へのアクセスが許可されます。

オリジンリストに指定されていないクロスオリジンiframeが、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コンテンツがパスキー認証をトリガーするためにユーザーのアクションを必要とすることを確認してください。これは、iframe内のクリックやフォーム送信に対するイベントリスナーを使用して行うことができます。このプロセスは、一時的なアクティベーションとも呼ばれます。

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のユーザージェスチャー要件に関するブログ記事も参照してください。

以下に、https://cross-origin-iframe.vercel.comでホストされているindex.htmlファイルの完全なサンプルコードスニペットを示します。これは、https://passkeys.euを介してパスキー用のクロスオリジン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>

iframeにパスキーを実装する際には、スムーズで安全なユーザーエクスペリエンスを確保するために開発者が対処する必要のある一連の課題が伴うことがあります。ここでは、一般的な課題とその克服方法について詳しく見ていきます。

問題： パーミッションポリシーを誤って設定すると、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レスポンスヘッダーの両方に含まれていることを再確認してください。
• Webサーバーヘッダーの代わりにメタヘッダーを使用する： Webサーバーでヘッダーを設定する代わりに、<meta/>ヘッダーを使用してパーミッションポリシーを定義します。
• 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（許可された機能）の中にリストされているはずです。

問題： クロスオリジンiframeでのパスキー作成またはパスキーログインが機能せず、ブラウザのコンソールに次のエラーが表示される。

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

このエラーは、Safariブラウザを使用してiframe内からパスキーを作成しようとすると表示されます。Safariはクロスオリジンiframeでのパスキー作成をサポートしていないためです（上記参照）。

解決策： Safariはまだクロスオリジンiframe内からのパスキー作成をサポートしていないため、ここでは実際には何もできません。

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.

このエラーはパスキーに直接関連するものではなく、Safariでのクロスオリジンiframe全般に関連するものです。Safari / WebKitのサードパーティCookieのブロックやサードパーティコンテキストでのLocalStorageへのアクセスをブロックする取り組みの一環として、JavaScriptロジックの一部が壊れる可能性があります。

解決策： ここでは、iframe内でサードパーティCookieを使用していないことを確認する必要があります。これがエラーの原因となります。

問題： ブラウザによってWebAuthn、iframeの権限、セキュリティ属性のサポートレベルが異なるため、一貫性のない動作につながり、iframeのブラウザ互換性の問題が発生します。

解決策： これらのiframeブラウザ互換性の問題を軽減するには、複数のブラウザで実装をテストして互換性を確保し、ブラウザ固有の問題を特定します。

手順：

1. BrowserStackやSauce Labsなどのツールを使用して、クロスブラウザテストを実施します。
2. ブラウザ固有の修正やフォールバックを実装して、不一致に対処します。

問題： ネイティブアプリ内でパスキーを必要とするiframeを使用する場合、ファーストパーティとサードパーティのコンテキストを明確に区別する必要があります。

• ファーストパーティコンテキスト：パスキーは、アプリを運営する会社と同じドメインに紐付けられています。例えば、ユーザー認証に自社ドメインを利用するeコマースアプリなどです。
• サードパーティコンテキスト：異なるドメイン（例：決済プロバイダーやIDプロバイダー）がパスキーの作成やログインフローを処理します。

iOSのWKWebViewやAndroidのWebViewなどの**埋め込みWebView（EWV）**では、呼び出し元のアプリがWebセッションを広範囲に制御できます（例：リクエストの傍受）。この設定は通常、パスキーのドメイン（リライングパーティID）がアプリのドメインと一致する場合（ファーストパーティ）にのみパスキーをサポートします。しかし、決済プロバイダーのクロスオリジンフローのようなサードパーティのシナリオでは、マーチャントのアプリと決済プロバイダーのサービスはオリジンが異なるため、埋め込みWebViewは通常、必要なパスキー認証情報にアクセスできません。パスキーに必要な「バインディング」（ドメイン、認証情報、オリジン間）が埋め込みコンテキストでは一致しないためです。

この制限により、多くのアプリはシステムWebViewアプローチ（例：iOSのASWebAuthenticationSessionやAndroidのCustom Tabs）を採用しています。システムWebViewは、サードパーティのサイト（例：決済プロバイダー）を安全なブラウザのような環境に分離し、ブラウザ自体がサポートしていればクロスオリジンのパスキーを正しく許可します。ただし、Safariの既存のiframeの制限はASWebAuthenticationSessionにも適用されるため、Safariがサードパーティのiframeで特定のパスキー操作を許可しない場合、システムWebViewでも同様のことが言えます。現在、「ネイティブ」な修正方法はありません。外部の決済プロバイダーが関与する複雑なフロー（チェックアウトなど）のベストプラクティスは、埋め込みWebViewではなくシステムWebViewを開くことです。

解決策： 決済プロバイダー（およびドメイン間でパスキーに依存する他のサードパーティ）は、ユーザーが埋め込みWebViewからシステムWebViewに移動するように、統合を慎重に計画する必要があります。これは純粋な埋め込みフローよりもシームレスさに欠ける体験ですが、サードパーティサービスでパスキー機能が動作することを保証する唯一の方法であることが多いです。

Integrate passkeys as Payment Provider via 3rd party SDK.

Read article

ネイティブアプリやWebView内でサードパーティのパスキーを処理する方法の詳細については、決済プロバイダー向けパスキー：サードパーティパスキー決済SDKをご覧ください。

上記で説明したトピックはさまざまなシナリオに適用されますが、特に決済プロバイダーにとって重要です。決済プロバイダーでは、マルチドメインフロー（例：マーチャントサイトと決済ゲートウェイ）がクロスオリジンiframe内にユーザー認証を埋め込む必要があります。これらの設定では、

• ユーザーは、リダイレクトポップアップなしで、ページ内で完結する摩擦のないチェックアウトを望んでいます。
• 決済プロバイダーは、マーチャントのサイトに埋め込まれている場合でも、自社のドメイン（例：pay.provider.com）でパスキーの登録またはログインを処理する必要があります。
• Safariの制約や埋め込みWebViewの制限により、iframe内でのサードパーティのパスキー作成がしばしばブロックされます。

これらの課題に取り組み、Apple Payと同様の安全でシームレスな体験を構築するために、決済プロバイダーはしばしばハイブリッドアプローチを採用します。これは、iframeベースの統合と、Safari（または古いブラウザ）用のリダイレクトフォールバックを組み合わせたものです。場合によっては、埋め込みWebViewがパスキーをまったく許可しない場合、システムブラウザフロー（例：iOSのASWebAuthenticationSession）が必須になります。

これらの決済固有のシナリオ（iframe対リダイレクトの比較、ネイティブアプリの考慮事項、高いパスキー採用率のためのベストプラクティスなど）についての詳細な解説については、専用の記事をご覧ください。

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

Get free Whitepaper

特に、

• 戦略A：クロスオリジンiframeの埋め込みでは、ここで紹介したPermissions-Policy設定を参照しながら、パスキーの作成とログインをインラインで処理する方法を説明しています。
• 戦略B：幅広い互換性のためのリダイレクトベースのアプローチでは、ほとんどのクロスオリジンの落とし穴を回避する、よりシンプルな統合を示していますが、マーチャントのドメインを離れるという代償が伴います。
• システムWebViewは、埋め込みWebViewがサードパーティのパスキーフローを頻繁に壊すため、ネイティブアプリにとって不可欠です。

この補足ガイドは、取引を保護し、Safariのクロスオリジン制限を克服し、サードパーティコンテキストでのパスキー使用を最適化するための詳細な戦略を提供します。この記事の技術的な手順と、それらの決済に焦点を当てた方法を組み合わせることで、オンライン決済のセキュリティとUXを次のレベルに引き上げる、摩擦のないフィッシング耐性のあるチェックアウトフローをiframe内で直接提供できます。

iframe内にパスキーを統合することは、セキュリティとユーザーエクスペリエンスの両方を向上させることで、ユーザー認証を大幅に強化します。これにより、リダイレクトやポップアップを必要としないシームレスな認証が可能になり、さまざまなセクションやサイトで一貫したUXが保証されます。

Shopifyによるログインコンポーネント内へのパスキーの統合のような実際の導入事例は、このアプローチの実用的な利点と柔軟性を示しています。