決済プロバイダー向けPasskeys：サードパーティSDKの構築方法

Passkeysは、オンライン取引を保護し、承認するための最も効果的な方法として台頭しています。従来の多要素認証（MFA）と比較して、セキュリティと利便性を大幅に向上させます。最近、PayPalが自己完結型の主要なMFAソリューションとしてPasskeysを採用したことは、世界中の決済プロバイダーにとって明確なトレンドを示しています。

しかし、Passkeysはもともとファーストパーティのコンテキストを念頭に設計されていました。つまり、ユーザーが認証情報を所有するウェブサイトやアプリで直接認証する場合に最適に機能します。決済プロバイダーは対照的に、通常サードパーティのコンテキストで運営されます。彼らのサービス（決済フォームやSDKなど）は、マーチャントのウェブサイトやアプリに埋め込まれます。Passkeysの設計と決済プロバイダーの運用モデルとの間のこの根本的な不一致は、シームレスな統合において重大な制約をもたらします。これらの課題に対処するためには、2つの重要な問いを探る必要があります。

1. 決済プロバイダーがサードパーティのコンテキストでPasskeysを使用する際の現在の制約とは何か？ 2. 決済プロバイダーはこれらの制約をどのように克服し、サードパーティのPasskeys統合を成功させることができるか？

これらの問いを検討することで、サードパーティのコンテキストにPasskeysを適応させるための業界の継続的な取り組み、特にSecure Payment Confirmation（SPC）のようなウェブ標準を通じた取り組みが、Appleによって暗黙のうちに課された戦略的な障壁によって妨げられていることが明らかになります。具体的には、AppleがSafariでのクロスオリジンのPasskey作成に対するサポートを限定し、Secure Payment Confirmation標準のサポートを欠いていることが、サードパーティの決済プロバイダーによるPasskeyベースの認証のシームレスな採用を複雑にする大きな障害となっています。これらのハードルを理解し、克服することは、摩擦のない安全な決済体験を提供しようとするすべてのプロバイダーにとって不可欠です。

Passkeysは、決済スタックのあらゆる層にフィッシング耐性のある生体認証ベースのログインをもたらします。以下は、決済バリューチェーンの各プレイヤーがPasskey認証を統合することで得られるメリットの内訳です。

インパクト： より速いチェックアウト、より高いコンバージョン率、カート放棄の減少。 機会： SDKやリダイレクトフローを介してPasskeysを提供するマーチャントは、Apple PayレベルのUXを模倣し、パスワードやOTPへの依存を減らすことができます。これにより、信頼性と売上の向上につながります。

インパクト： デバイス間でのシームレスなパスワードレス認証。 機会： PasskeysはOTPやSMSコードよりも優れたUXを提供し、フィッシングのリスクを排除します。広範な採用により、Passkeysはカード会員認証の新しいデフォルトになる可能性があります。

インパクト： より強力な不正防止。 機会： イシュアーは3DSフローでPasskeyベースのステップアップ認証を提供でき、OTPコストを削減し、ユーザー満足度を向上させることができます。

インパクト： より高い取引承認率と認証失敗の減少。 機会： PSPを通じてPasskeysをサポートすることで、マーチャントの成果を改善し、チェックアウトや定期請求フロー中の摩擦を減らすことができます。

インパクト： 不正行為の削減、マーチャントUXの向上、コンプライアンスの改善。 機会： Passkeyフローを埋め込むかリダイレクトすることで、PSPはブラウザやネイティブアプリ間の互換性を維持しながら、次世代の認証を提供できます。

インパクト： 決済の拒否が少ない、合理化された取引承認。 機会： 決済処理会社は、リスクを軽減し、コンプライアンスに準拠したフローのための生体認証SCA代替案をサポートするために、APIにPasskey検証を統合できます。

インパクト： 安全な認証情報ストレージと摩擦のない再認証。 機会： Apple PayやGoogle Payのようなウォレットプロバイダーは、すでにPasskeyのようなフローを使用しています。

以下では、主要な決済およびクレジットカードプロバイダーを簡単に見て、彼らがPasskeysを導入しているか、またどのように導入しているかを分析します。

Mastercardは公式にPayment Passkey Serviceを開始し、EMV 3DSフローに組み込まれたパスワードレス認証体験を提供しています。ユーザーはMastercardの認証ドメイン（例：verify.mastercard.com）に紐付けられたPasskeysを作成・使用でき、参加マーチャント間で安全な生体認証ログインを可能にします。この展開は、決済業界におけるフィッシング耐性のあるPSD2準拠の認証に向けた大きな一歩です。 詳細はこちら：Mastercard Passkeys

VisaはVisa Payment Passkey Serviceを導入し、「Click to Pay」フローにPasskeysを統合しました。パスワードやOTPの代わりに生体認証を使用してユーザーがシームレスに認証できるようにすることで、Visaはセキュリティとユーザーの利便性を向上させたオンラインチェックアウト体験の近代化を目指しています。 詳細はこちら：VISA Passkeys

American ExpressはまだPasskeyの提供を公に開始していません。しかし、FIDO Allianceのボードレベルのメンバーとして、American Expressが近い将来、より広範な業界のトレンドに沿ってPasskeyベースの認証ソリューションを展開する可能性は高いです。

PayPalはPasskeysを最初に採用した決済プロバイダーの一つです。彼らの展開は、個人およびビジネスアカウントでデバイスを問わずシームレスな生体認証ログインをサポートしています。PasskeyはPayPalのドメインに紐付けられており、すでに多くの地域で利用可能です。しかし、特にマルチデバイスフローやプラットフォーム検出に関しては、彼らの実装には改善の余地があります。 詳細はこちら：PayPal Passkeys

Klarnaはまだ公式にPasskeyサポートを導入していません。私たちの観察によると、KlarnaはアプリやチェックアウトSDKで埋め込みWebViewに大きく依存しています。SafariやiOSはiframes / WebViewsでのPasskey作成を制限しているため、これがKlarnaがこれまでPasskeysを展開してこなかった理由かもしれません。

Squareは開発者ダッシュボードと管理コンソールにPasskeyログインを導入し、内部ツールへの安全なパスワードレスアクセスを可能にしました。しかし、エンドユーザーやマーチャント向けの決済フローやAPIでのPasskeyサポートに関する発表はまだありません。

StripeはダッシュボードにPasskeyログインを展開し、開発者が生体認証を使用して認証できるようにしました。Stripe CheckoutやElements向けのPasskeysはまだ利用できません。Stripeがリダイレクトベースのフローを強く支持していることを考えると、もし決済にPasskeysが実装されるなら、同じリダイレクトアーキテクチャに従う可能性が高いです。

現時点では、BILLは認証に関するPasskeys関連の公式発表や製品アップデートを行っていません。

Remitlyは、自社サービスにPasskey認証を実装する計画や公開情報を開示していません。

PayoneerがPasskeyベースのログインや取引フローを採用した、あるいはテストしていることを示す公式レポートや製品ドキュメントはありません。

Adyenはまだ認証や決済フローにPasskeysを導入していません。Passkeyサポートに関する公式声明や開発者向けドキュメントはありません。

Worldpayは現時点でPasskeysのサポートを発表していません。彼らの認証スタックは、依然としてパスワード、OTP、3DSベースのフローといった従来の方法に依存しています。

Checkout.comは公にPasskeyサポートを展開していません。Passkey採用に関する開発者アップデート、ブログ投稿、公式発表はありません。

AliPayは公式にPasskeysをローンチしていません。中国の決済エコシステム内での生体認証のトレンドが高まっていることを考えると、将来的には展開されるかもしれませんが、現在のドキュメントでは確認できません。

Mollieは、認証やチェックアウトシステムでのPasskeysの採用に関する公式声明や製品アップデートを行っていません。

AmazonはメインプラットフォームでのユーザーログインにPasskeyサポートを展開しました。この技術をAmazon Payに拡張するのは自然な次のステップでしょう。特に、多くのユーザーがすでにAmazonにPasskeyを登録しているため、チェックアウト時のユーザーオンボーディングが大幅に簡素化されるはずです。

PayPal傘下のBraintreeは、まだ公式にPasskey認証を採用していません。現在のドキュメントでは、ユーザーログインやマーチャントAPIの文脈でPasskeysについて言及されていません。

StripeのワンクリックチェックアウトソリューションであるLinkはPasskeysを展開しており、これがStripeの消費者向け決済におけるPasskey戦略の基盤となる可能性があります。しかし、StripeはLinkのPasskeyサポートや展開に関する具体的な計画を公式に発表していません。

AfterpayはPasskeyサポートに関する声明や機能を発表していません。Klarnaと同様、彼らのチェックアウト統合はアプリベースが中心であり、埋め込みWebViewの制約により、Passkey採用に技術的なハードルがあるかもしれません。

サードパーティの決済プロバイダーによるPasskeysの採用は、主にAppleのSafariにおける制限的なポリシーによって引き起こされる戦略的な障害に直面しています。2つの重要な標準化の試みが一貫して妨げられてきました。

• Secure Payment Confirmation (SPC)
• iframesでのサードパーティPasskey作成

Secure Payment Confirmation (SPC)は、安全な決済承認に特化してPasskeysのシームレスなクロスオリジン利用を可能にするための、主にGoogleが推進する業界で最も重要な取り組みです。SPCは、決済プロバイダーがセキュリティやユーザーエクスペリエンスを損なうことなく、複数のマーチャントサイトでユーザーを認証する方法を標準化します。しかし、AppleはSafari内でのSPCのサポートを一貫して拒否してきました。これは、自社のエコシステム内でApple Payが最も摩擦のない、好まれる決済ソリューションであり続けることを確実にするための戦略的な動きである可能性が高いです。AppleがSPCの採用を拒否することは、サードパーティのコンテキストでのPasskeysの広範な展開を制限するだけでなく、標準化された決済認証のより広範な業界採用を事実上遅らせています。

詳細については、SPCに関するこのブログ記事をお読みください。

もう一つの重大な障壁は、Appleがクロスオリジンのiframes内でのPasskey作成を意図的に制限していることに関係します。Safariはサードパーティのiframe内で既存のPasskeysを認証に使用すること（navigator.credentials.get()）は許可していますが、そのようなコンテキストでのPasskey登録（navigator.credentials.create()）は明示的にブロックしています。

この制限は、マーチャントのチェックアウトフロー中にシームレスに新しいPasskeysを作成することに依存している決済プロバイダーを著しく制約します。その結果、プロバイダーはリダイレクトベースのアプローチを取るか、自社のドメインで直接以前に確立された既存のPasskeysに頼らざるを得なくなります。Appleによるこの決定は、マーチャント統合の実用性と流動性に直接影響を与え、消費者とプロバイダー双方にとって大きな摩擦点を生み出しています。

このアプローチでは、マーチャントはあなたの決済フォームを、あなたの決済プロバイダードメイン（例：https://pay.provider.com）から提供される<iframe>に含めます。ユーザーはマーチャントのドメイン（例：https://www.mystore.com）に留まり、埋め込まれたiframeであなたの決済UIを見て、Relying Party ID pay.provider.com に紐付けられたPasskeyで認証します。

キーポイント：

• クロスオリジン：iframeは異なるドメイン上にあるため、iframe内でPasskey操作を許可するには、publickey-credentials-getとpublickey-credentials-createのパーミッションポリシーを設定する必要があります。

• 作成の制限：一部のブラウザ（特に古いバージョンやSafari）は、クロスオリジンのiframeでのPasskey作成をまだ許可していません。認証（navigator.credentials.get()）はより広くサポートされていますが、登録（navigator.credentials.create()）は特定の環境、特にSafariで失敗する可能性があります。

• ユーザーアクティベーション：Passkeyフローは通常、「一時的なアクティベーション」（例：ユーザーからの直接のボタンクリック）を必要とします。あなたのiframeインターフェースがユーザー主導のイベント内でPasskeyセレモニーをトリガーすることを確認してください。

• セキュリティとUX：iframeアプローチはスムーズなインラインチェックアウト体験を提供しますが、ユーザーのブラウザがサードパーティのCookieやローカルストレージをブロックまたは制限している場合、Passkeyフローが中断される可能性があります。

リダイレクトベースのフローでは、ユーザーをマーチャントのドメインからあなたの決済ドメインに送るか、https://pay.provider.com/checkoutのような新しいタブ/ウィンドウを開きます。Passkeysはその後、あなたのドメイン上で直接ファーストパーティのコンテキストで作成または使用されます。

キーポイント：

• ファーストパーティのシンプルさ：Passkeyのワークフロー全体（作成、認証）が決済プロバイダーのドメイン上で行われるため、クロスオリジンの制限はありません。すべての主要なブラウザがファーストパーティのコンテキストでのPasskeyの作成とログインをサポートしています。

• リダイレクトUX：ユーザーは認証を完了するためにマーチャントページを離れる（またはポップアップを見る）ことになります。これはシームレスさに欠けるかもしれませんが、Passkeyアーキテクチャを簡素化し、クロスオリジンの複雑さを軽減します。

• 互換性のないブラウザのフォールバック：Passkeysが利用できない場合（例：古いブラウザ）、追加のクロスオリジンパーミッション処理を必要とせずに、あなたの決済ドメインで代替ログイン方法を提供することで、優雅にデグレードできます。

ネイティブモバイルアプリ内でのPasskeysの統合は、ウェブベースのシナリオと比較して特有の課題を提示します。マーチャント向けのネイティブアプリ（iOSとAndroidの両方）は、シームレスなユーザーエクスペリエンスを維持するために、埋め込みWebViewsを使用してアプリケーション内に決済フローを埋め込むことがよくあります。しかし、これらの埋め込みコンテキストでサードパーティのPasskey認証を実装することは、厳格なブラウザオリジンポリシーとプラットフォーム固有の制限のために問題となる可能性があります。

Passkeysは本質的に特定のドメイン（「Relying Party ID」）に紐付けられています。これは、認証情報が関連のないウェブサイトやアプリ間で悪用されないようにするための中心的なセキュリティ原則です。決済プロバイダーが自社のドメイン（例：pay.provider.com）でPasskeysを作成すると、それらのPasskeysはiOSとAndroidの両方でそのドメインに厳密にスコープされます。その結果、マーチャントのネイティブアプリ（当然、マーチャント自身のアプリ識別子とドメインで動作する）は、プロバイダーのPasskeysを「ファーストパーティ」の認証情報として直接呼び出すことはできません。そうするには秘密鍵のクロスオリジン共有が必要になりますが、これはオペレーティングシステムとWebAuthn仕様がフィッシングや認証情報の盗難を防ぐために明示的に禁止しています。

デバイスの観点から見ると、マーチャントのネイティブアプリは決済プロバイダーのドメインとは異なる「オリジン」です。別のオリジンに登録された認証情報に対してネイティブに認証を試みることは、Passkeysの基本的なオリジンに紐付いたセキュリティモデルを破ることになります。これがまさに、マーチャントのコンテキストでサードパーティのPasskeyを使用するには、システムブラウザまたはシステムベースのWebView（iOSのASWebAuthenticationSessionやAndroidのChrome Custom Tabsなど）に依存する理由です。これらの特別なフローは、プロバイダーの元のドメインコンテキストを保持し、Passkeysが安全にオリジンに紐付いたままであることを保証しつつ、ユーザーがマーチャントのアプリ内で決済プロバイダーと認証できるようにします。次のセクションでは、これがどのように機能するかを探ります。

埋め込みWebViews（例：iOSのWKWebViewやAndroidのWebView）は、アプリがウェブコンテンツをネイティブインターフェースに直接埋め込むことを可能にし、緊密な統合とUXの一貫性を提供するため、広く好まれています。しかし、これらの埋め込み環境は、オリジンとセキュリティポリシーのためにサードパーティのPasskeysを扱う際に著しく制限されます。

• オリジンの不一致：Passkeysは安全な認証情報処理のためにドメインオリジンに厳密に依存します。埋め込みWebViewは、表示するコンテンツのドメイン（多くの場合マーチャントのドメイン）で動作するため、サードパーティの決済プロバイダーのドメインに明示的に紐付けられたPasskeysを作成または認証することが困難または不可能になります。

• プラットフォームのセキュリティ制約：Apple（iOS）とGoogle（Android）の両方が、特に安全な認証情報を扱う際の埋め込みWebViewの認証能力を徐々に制限しています。これらの制約は、ユーザーのプライバシーとセキュリティを保護するために設計されていますが、サードパーティのPasskey実装を著しく複雑にします。

全体として、埋め込みWebViewはUXの観点からマーチャントにとって魅力的ですが、堅牢なサードパーティのPasskey認証フローを実装するための重大な実用上の制限をもたらします。

埋め込みWebViewに関連する制限を考慮して、決済プロバイダーは通常、ネイティブモバイルアプリでサードパーティのPasskeysを確実に実装するために、2つの代替戦略のいずれかを採用します。

iOS (ASWebAuthenticationSession):

Appleは、ホストアプリケーションのコンテキスト外で安全なブラウザのような環境としてASWebAuthenticationSessionを提供しています。これはデフォルトのSafariブラウザとCookieストレージを共有し、認証情報が決済プロバイダーのオリジンドメインと一致するため、サードパーティのPasskeysを確実にサポートします。

次の例は、BOSSネイティブアプリ内の「PayPalでチェックアウト」機能を示しています。これは、ASWebAuthenticationSessionシステムWebViewがどのように開かれ、SafariのCookieと状態を共有し、Passkeyダイアログがすぐに開始されることを可能にするかを示しています。

Android (Chrome Custom Tabs):

同様に、AndroidのCustom Tabsは、一貫したPasskeyの作成と認証を可能にする、ブラウザに近い環境を提供します。ASWebAuthenticationSessionと同様に、Custom Tabsはマーチャントのアプリコンテキストとは別に実行され、ドメインと認証情報の整合性を保証します。

Android上のBOSSネイティブアプリからの同じ例をここでご覧ください：

もう一つのアプローチは、ユーザーをネイティブアプリからモバイルデバイスのデフォルトウェブブラウザ（iOSではSafari、AndroidではChrome）にリダイレクトすることです。これにより、決済フロー、ひいてはPasskey管理が、決済プロバイダーのドメインに関連付けられた信頼できるファーストパーティのコンテキストで完全に行われることが保証されます。ユーザーは認証または支払いが正常に完了した後、マーチャントアプリに戻ります。このオプションは、アプリを離れなければならないため、顧客にとっては非常に不便です。

どちらのソリューションも、ユーザーを一時的にマーチャントのネイティブアプリ環境から移行させる必要があります。埋め込みソリューションと比較して若干シームレスさに欠けますが、これらのアプローチはサードパーティのPasskey操作の互換性、セキュリティ、信頼性を大幅に向上させます。

最終的に、ネイティブSDKを開発する決済プロバイダーは、ユーザーエクスペリエンスの考慮事項と実用的な技術的制約を慎重にバランスさせる必要があります。完全に埋め込まれた体験を好むマーチャントの嗜好にもかかわらず、システムWebViewや外部ブラウザリダイレクションを活用することが、ネイティブアプリ内で安全で信頼性の高いサードパーティのPasskey認証を保証するためのベストプラクティスであり続けます。

サードパーティのPasskeysを決済SDKに統合するために、埋め込み（iframe）アプローチとリダイレクトベースのアプローチのどちらかを選択することは、ユーザーエクスペリエンス、ブラウザの互換性、技術的な複雑さ、マーチャントの嗜好にわたるトレードオフを評価することを含みます。

どちらのソリューションにも明確な長所と短所があり、決済プロバイダーはターゲット市場、望ましいUX、技術インフラに基づいて慎重に検討する必要があります。

埋め込み（iframe）アプローチは、マーチャントにとって非常に魅力的なシームレスでマーチャントブランドのユーザーエクスペリエンスを提供しますが、特にSafariがクロスオリジンPasskey作成を許可しないというブラウザ互換性の制限によって妨げられています。この制限により、マーチャントとプロバイダーは、しばしば機能を損なうか、Passkey登録の不完全なサポートにつながる複雑な回避策ベースのソリューションに追い込まれます。

逆に、リダイレクトアプローチは、ファーストパーティのドメインコンテキストで動作することにより、ブラウザやネイティブモバイルプラットフォーム全体で包括的な互換性を提供します。これにより、統合が大幅に簡素化され、信頼性が向上し、完全なPasskeyの作成と認証のサポートが保証されます。主な欠点は、ユーザーをマーチャントのウェブサイトやアプリからリダイレクトすることによって生じる潜在的な摩擦ですが、これは慎重なUXデザイン、明確に伝えられる期待、またはCorbadoのような信頼できるプラットフォームとの統合によって軽減できます。

これらの考慮事項を考えると、ハイブリッドアプローチがしばしば理想的です。これにより、決済プロバイダーはユーザーのブラウザがサポートしている場合に埋め込みiframeモデルを活用し、それ以外の場合はリダイレクトアプローチに優雅にフォールバックできます。この組み合わせ戦略は、多様な環境全体で互換性、マーチャントへの魅力、顧客満足度を最大化します。

サードパーティのPasskeys決済SDKを実装するには、ユーザーエクスペリエンス、ブラウザの互換性、ネイティブアプリの制約、分析、セキュリティのバランスを取る必要があります。特に、Apple固有のハードル（例：クロスオリジンPasskey作成のブロック、SPCサポートの欠如）を考慮すると、これは重要です。以下は、ウェブまたはネイティブの決済フローにPasskeysを統合する際に最良の結果を保証するための主要な推奨事項です。

ブラウザのサポートがまちまちで、Appleの挙動が一貫していないため、埋め込み（iframeベース）アプローチとリダイレクトアプローチの両方をサポートすることが重要です。

• Iframeチェックアウト（埋め込み）

  • クロスオリジンPasskey操作を許可する最新のブラウザ（主に認証用）に、シームレスなページ内体験を提供します。

  • publickey-credentials-get/publickey-credentials-createに対して正しいPermissions-Policyを設定する必要があります。

  • Safariや一部の古いブラウザは、iframesでのクロスオリジンPasskey作成をブロックすることに注意してください。

• リダイレクトフロー

  • ファーストパーティのコンテキストでPasskeyの登録とログインの両方を確実にサポートします。

  • 追加のリダイレクトやポップアップによる摩擦がわずかにありますが、クロスブラウザの互換性のためには普遍的により安全です。

  • 現在iframesでのサードパーティPasskey作成を許可していないSafariの理想的なフォールバックです。

両方のアプローチを提供することで、どちらを使用するかを動的に決定する（またはマーチャントに決定させる）ことができ、すべてのユーザー環境で互換性を最大化できます。

User-Agentの粒度の低下と、プラットフォーム間でのClient Hintsのサポートの不一致により、ブラウザの機能を正確に検出することは依然として困難です。

ブラウザがユーザーのプライバシーを保護するためにUser-Agent文字列の詳細を減らしているため、従来の解析はますます信頼できなくなっています。Windows 10とWindows 11の区別、正確なmacOSのバージョン、CPUアーキテクチャなどの重要な詳細をUser-Agentだけで区別することは、現在困難または不可能です。

Client Hintsはプライバシーを尊重する方法で高エントロピーデータを提供しますが、Chromiumベースのブラウザのみが完全にサポートしています。SafariとFirefoxはClient Hintをサポートしていないため、Appleデバイスでの正確な機能検出が著しく制限されます。

埋め込みWebViewは通常、詳細なデバイス情報へのアクセスを制限し、Client Hintsをサポートすることはめったにありません。この制限により、ネイティブアプリのコンテキスト内でのPasskey機能の検出が特に困難になります。

これらの制約を考えると、特にサードパーティの決済SDKでクロスオリジンPasskeyサポートを確実に検出するには、動的なClient Hintクエリ（利用可能な場合）、フォールバックのUser-Agentヒューリスティクス、およびSafariやFirefoxのようなブラウザに対する保守的なデフォルトの挙動を慎重に組み合わせる必要があります。

ネイティブのマーチャントアプリは、ウェブコンテンツをWKWebView（iOS）やAndroid WebViewに埋め込むことがよくありますが、これらはPasskeysにとって非常に制限的です。一般的な戦略は次のとおりです。

• システムブラウザセッション：ASWebAuthenticationSession（iOS）またはCustom Tabs（Android）を使用して、Passkeyの作成/ログインを安全な「ファーストパーティ」ブラウザコンテキストに移行します。

• デフォルトブラウザへのリダイレクト：シームレスさは劣りますが、Passkey操作のドメイン整合性を確保するための非常に信頼性の高いアプローチです。

決済プロバイダーとして、強力なセキュリティと規制遵守（PCI、PSD2 SCAなど）が鍵となります。

• ヘッダーとコンテンツセキュリティ：クロスオリジンフローに対して厳格なPermissions-Policyヘッダーと堅牢なCSPルールを実装します。

• ロギングとモニタリング：不正防止とコンプライアンス監査のために、Passkeyの作成と使用イベントを徹底的にログに記録します。

• 最小限のPIIストレージ：ハッシュ化された識別子を使用してユーザーをPasskeysにマッピングし、GDPRや同様のデータ保護法の下での露出を減らします。

• 監査証跡：各Passkeyの作成と認証イベントをログに記録して、異常を検出し、コンプライアンス監査を満たします。

Passkeysはまだ進化しているため、継続的なチェックが必要です。

• クロスブラウザ＆クロスOSテスト：Safari、Chrome、Edge、Firefox、および主要なモバイルOSバージョンでのテストを自動化します。

• 頻繁な更新：W3C WebAuthn仕様、FIDO Allianceガイドライン、またはSPC提案の変更を追跡します。

• ユーザーフィードバックとエラー率：Passkeyのエラー（作成またはログイン）をログに記録して、特にAppleベースのユーザーの問題を迅速に修正します。

堅牢なKPIフレームワークは、サードパーティのPasskey統合が本当にセキュリティとユーザーエクスペリエンスを向上させているかを追跡するのに役立ちます。この記事はSDKの実装に関するものですが、このユースケースでもPasskeyの採用が重要であることを心に留めておくことが重要です。Passkeysの作成率と使用率は、慎重な分析と最適化が必要です。

• 定義：プロンプトが表示されたときに（例：チェックアウト時やアカウント設定時）、正常にPasskeyを作成したユーザーの割合。

• 重要性：高い作成率は、Passkeysのオンボーディング/ナッジフローが魅力的で摩擦がないことを意味します。

• 目標：50〜80%の率を目指すべきです。

• 定義：作成セレモニーを開始したユーザー（「Passkeyを作成」をクリック）のうち、中断やエラーなしで完了したユーザーの数。

• 重要性：クロスオリジンまたはリダイレクトフローがどれだけうまく機能しているかを示します。

• 目標：理想的には、ユーザーがオプトインしたら約95〜100%の数値を持つべきです。

• 定義：フォールバック方法とは対照的に、Passkeysを介して行われた総決済承認（またはログイン）の割合。

• 重要性：ユーザーが古い方法にデフォルトで戻ってしまう場合、作成は無意味です。

• 目標：50〜80%の率は、強力なPasskey採用を示します。

• 定義：エラーやフォールバックなしで成功したPasskeyログイン試行の割合。

• 重要性：実際のユーザビリティの反映。

• 目標：通常、Passkeysを「摩擦なし」と見なすには90〜95%を超えるべきです。

• 定義：ユーザーがセレモニーの途中でPasskeysに失敗し、パスワードやOTPに切り替える頻度。

• 重要性：高いフォールバック使用率は、技術的またはUX上のハードルがPasskeysがレガシーメソッドを置き換えるのを妨げていることを示唆しています。

• 目標：理想的には、フォールバック使用率は1〜5%未満です。

決済プロバイダーにとって、Passkeysが不正を減らし、チェックアウトを加速させ、カート放棄を減らすかどうかを測定します。Passkeyの使用状況データを決済コンバージョンや3-D Secureの成功メトリクスと組み合わせて、全体的なビューを得ます。

これらのKPIを監視することで、どの環境やユーザージャーニーが改善を必要としているかを特定できます。たとえば、Safari iOSがクロスオリジンのブロックのために放棄率が高い場合、それらのユーザーを体系的にリダイレクトフローに誘導できます。

サードパーティのPasskeys SDKを構築する上で最も重要な課題の1つは、ユーザーが実際にPasskeysを登録する、スムーズで一貫した作成フローを編成することです。これが銀行のポータル、決済プロバイダー自身のアカウント設定、またはマーチャントのチェックアウトページで発生するかにかかわらず、中心的なPasskey登録手順は非常に似ています。したがって、Passkey作成へのアプローチは、フローをiframeに埋め込むか、ユーザーをファーストパーティページにリダイレクトするかに基づいて根本的に変わるわけではありません。最も重要なのは、明確でユーザーフレンドリーな画面を提供し、クロスオリジンの制約を管理し、ユーザーがPasskeysをどれだけ効果的に採用しているかを示す不可欠なメトリクスを追跡することです。以下は、ベストプラクティスのPasskey作成フローの主要な側面と、Corbadoがそれらをどのようにサポートするかです。

ユーザーがPasskeyを作成するよう促される場所が、銀行のオンラインバンキング環境、決済プロバイダー自身のウェブサイト/アプリ、またはマーチャントのチェックアウトであっても、Corbadoはユーザープロンプト、成功確認、エラー処理のための事前に構築されたカスタマイズ可能なコンポーネントを提供します。

これらのコンポーネントは一貫したルックアンドフィールを保証し、ホワイトラベルのブランディングを可能にするため、各銀行やマーチャントが必要に応じて独自の設計要素を保持できます。

VicRoadsデザインでブランド化されたPasskey作成画面の次のUIコンポーネントをご覧ください。

Corbadoは、すべての作成エンドポイントからデータを収集し、統合します。

• Passkeysが最初に提供される銀行のウェブサイトやアプリ。

• ユーザーが認証情報を管理できる決済プロバイダーの個人アカウント設定。

• オプションで「その場で」Passkey作成を許可するマーチャントのチェックアウトページ。

この統一されたアプローチにより、どのチャネルがPasskey登録を開始したかに関係なく、Passkey作成率、作成成功率、ユーザーの離脱ポイント、および技術的なエラーを簡単に測定できます。

Corbadoは、画面上の指示、ボタンのテキスト、プロンプトのタイミングを微調整するためのA/Bテスト機能を提供します。文言の微妙な変更（例：「今すぐPasskeyを作成 - パスワードはもう不要！」対「次の支払いをPasskeyで保護しましょう！」）は、しばしばユーザーの受け入れに大きな違いをもたらします。

A/Bテストの結果に基づいて、次のKPIを最適化できます。

• 作成率：プロンプトが表示された後、正常にPasskeyを設定したユーザーの割合。

• 作成成功率：セレモニーを中断またはエラーなしで完了したユーザーの割合。

• フォールバック使用率：ユーザーが古いログイン方法を優先してPasskey作成をスキップする率。

• コンバージョンへの影響：マーチャントにとって、チェックアウト時のPasskey作成がカート放棄を減らすかどうかを測定します。

ユーザーは次のコンテキストでPasskeysを作成できます。

• 銀行コンテキスト：ユーザーが銀行にログインした後にトリガーされる作成フローで、バンキング環境の信頼性と親しみやすさを活用します。

• 決済プロバイダーのアカウント設定：ユーザーは決済プロバイダーのドメインの「マイプロフィール」または「セキュリティ」設定で直接Passkeysを設定します。

• マーチャントチェックアウト：最終的な支払いステップでプロンプトを表示します。特にユーザーが以前にPasskeyを作成していない場合に有効です。これは埋め込み（iframe）またはリダイレクトを介して行うことができます。

各シナリオで、基礎となるPasskeyセレモニーは同じ手順（ユーザー確認、生体認証/PINプロンプト、認証情報登録）に従います。CorbadoのSDKは、クロスオリジンの制約（埋め込みの場合）またはファーストパーティのドメインコンテキスト（リダイレクトの場合）がバックグラウンドでシームレスに処理されることを保証します。

Corbadoは、各新しいPasskeyを適切なユーザー識別子（「bankPrefix_userId」や決済プロバイダーのシステム内の内部ユーザー参照など）に添付するため、その後のすべての使用が正しいユーザーアカウントに追跡可能です。

このメタデータは、高度な分析にも不可欠です。たとえば、RBCのPasskey作成キャンペーンがTDのキャンペーンと比較してどのように機能しているか、またはマーチャントのチェックアウトと直接の「アカウント設定」フローで作成率がどのように異なるかを確認できます。

同じCorbado SDKロジックは、クロスオリジンPasskey作成が許可されているか（最新のChromeやEdge）、またはSafariのためにリダイレクトに優雅に切り替える必要があるかに適応できます。

組み込みのエラー報告は、ユーザーのサブセットが一貫してPasskey作成に失敗している場合（例：古いiOSバージョン、企業のWindowsデバイス）を特定するのに役立ち、製品チームが指示やフォールバック戦略を洗練させることができます。

私たちのチームは、エンタープライズクライアントと広範なPasskey作成実験を行い、どのフレーズ、ボタンの配置、タイミングが最高の採用率をもたらすかを学びました。

私たちはこれらのベストプラクティスをすべての作成画面に組み込みながら、ブランディングとコンプライアンスのニーズに合わせて完全なカスタマイズを可能にしています。

全体として、Passkey作成は高い採用を保証するための最も重要なフェーズです。最もエレガントなPasskeyログインフローでさえ、ユーザーが最初に認証情報を登録しなければ意味がありません。Corbadoは、銀行、決済プロバイダードメイン、マーチャントチェックアウトなど、すべての可能なチャネルで統一された追跡可能な作成画面を提供し、それらをKPI分析とA/Bテストで計測することで、決済プロバイダーがApple Payのようなネイティブソリューションのユーザーエクスペリエンスを模倣し、真にスケーラブルなPasskey採用を推進するのを支援します。

ユーザーがPasskeyを作成したら、次のステップは、彼らが実際にそのPasskeyを使用して、Apple Payが提示するApple Pay決済フローのような、迅速で摩擦のない支払いを行うことを保証することです。

Corbadoでは、ユーザーの環境が有効なPasskeyを含んでいる可能性が高いことを自動的に検出する「Passkey Intelligence」メカニズムを開発しました。これにより、真のワンタップ決済体験が可能になります。以下は、これを可能にする中心的な要素です。

再訪ユーザーが認識されると、Corbadoのフロントエンドは、フォールバック認証情報の入力を強制するのではなく、専用のボタン（例：「Passkeyで支払う」）を表示します。

このボタンをワンタップすると、WebAuthn get() フロー（またはネイティブのPasskeyプロンプト）がトリガーされ、ユーザーは生体認証/PINを介して即座に認証できます。追加のステップやフォーム入力は不要です。

CorbadoのSDKは、現在のデバイス+ブラウザがこのユーザーに対して有効なPasskeyを持っている可能性が高いかどうかを予測するために、シグナル（例：ローカルストレージのCookie、以前の成功したPasskey使用、環境検出）を収集します。

Cookieが削除されたり利用できない場合、Corbadoは追加のヒューリスティクス（例：ユーザーの既知の環境、マーチャントから提供されたユーザーヒント）にフォールバックして、Passkeyフローを自動開始するのが安全かどうかを判断します。

Passkeyが存在することを示唆する十分な証拠がない場合、UIは優雅にフォールバックフローを提供するか、ユーザーにPasskeyを持っていることを確認するよう促します。

Corbadoは、完全なメールアドレスや名前のような個人を特定できる情報（PII）を保存しません。

代わりに、マーチャントはハッシュ化またはマスクされた識別子（例：メールハッシュや内部ユーザーID）を渡すことができます。Corbadoはそれを使用して潜在的なPasskey登録を検索し、Passkey認証を開始するか、より一般的なアプローチに戻るかを決定します。決済プロバイダーがサポートしている場合、マーチャントから提供された情報を使用して内部ユーザーIDを検索できます。

これにより、ユーザーのプライバシーを確保しつつ、高精度の環境マッチングが可能になります。

ユーザーのPasskeyが存在していたかもしれないが検出できないシナリオ（例：Cookieが消去された、新しいデバイス）では、CorbadoのPasskey Intelligenceは、Passkeyプロンプトを自動開始することが理にかなっているかどうかを慎重に分析します。

代わりに、ユーザーは代替のフォールバックフローや「別のデバイスからPasskeyをスキャン」オプションを見ることになりますが、ユーザーが手動で持っていることを確認できれば、Passkey使用への迅速なパスは維持されます。

CorbadoがワンタップPasskeyプロンプトを開始またはスキップすることを決定するたびに、その決定はログに記録されます。時間が経つにつれて、どのブラウザやデバイスタイプが最高のPasskeyカバレッジをもたらすか、またどのタイプが頻繁にフォールバックに戻るかを正確に確認できます。

この分析フィードバックループにより、パフォーマンスが低い環境（例：特定のiOSまたはAndroidバージョン）やPasskey使用率が低いユーザーセグメントを特定し、オンボーディングや教育戦略を洗練させることができます。

ユーザーが銀行のPasskey作成キャンペーンから来たか、マーチャントのチェックアウトで直接来たかに関わらず、ワンタップロジックは一貫しています。

Corbadoは、Passkeyが見つかった場合（ドメインCookie、ローカルストレージトークン、またはPasskey Intelligenceシグナルに基づく）、ユーザーに即座に最も摩擦のないログイン/決済フローが提示されることを保証します。

まとめ

要するに、ワンタップのPasskey使用は、そもそもPasskeyを作成する究極の報酬です。Passkey Intelligence（環境検出、最小限のPII使用、フォールバックロジックのブレンド）を活用することで、Corbadoはユーザーが本当に成功する可能性が高い場合にのみPasskey認証を提示されることを保証します。これにより、失敗した試行が劇的に減少し、ユーザーの不満を避け、習慣形成的なPasskey使用を促進し、最終的にはApple Payや他のネイティブ決済体験に匹敵するワンタップ決済フローが実現します。

単にPasskeysを有効にするだけでなく、それらが異なるデバイス、ブラウザ、ユーザージャーニーでどれだけ効果的に採用され、使用されているかを理解することが重要です。決済プロバイダーは、Passkeysが本当に摩擦を減らし、不正を削減し、コンバージョンを向上させるかについての確かなデータを必要としています。Passkeyの購入 vs. 構築ガイドのベストプラクティスを基に、CorbadoはPasskeyのパフォーマンスをリアルタイムで追跡、セグメント化、最適化できる豊富な分析レイヤーを提供します。

以下が主なハイライトです。

Corbadoは、すべてのPasskeyイベントをファネルに整理します。ユーザーがPasskeyを作成するよう促された瞬間から、成功した登録、その後のログイン/支払い（Passkey使用）までです。

このファネルの視覚化により、ユーザーがどこで離脱するかを確認できます。たとえば、作成を開始しないユーザーの数、セレモニーの途中で放棄するユーザーの数、ログイン時にフォールバック方法に戻るユーザーの数などです。

エンタープライズがPasskeysを実装するのを支援してきた豊富な経験に基づき、私たちはROIとユーザー満足度に直接影響を与えるメトリクスに焦点を当てています。

• Passkey承認率：作成プロンプトを見たユーザーのうち、実際にPasskey登録を完了した数は？

• Passkey作成成功率：セレモニーを開始した（「Passkeyを作成」をクリック）ユーザーのうち、エラーや放棄なしで完了した割合は？

• Passkey使用率：再訪ユーザーが日常の認証や支払いに、パスワードやOTPではなく、実際にPasskeysを選択する頻度は？

• Passkeyログイン成功率：フォールバックやユーザーの不満なしで成功したPasskey試行の割合。

• フォールバック使用率：Passkeyフローを開始したが、古い方法に戻ったユーザーの数は？これは潜在的なUXまたは技術的な障壁を示唆しています。

Corbadoは、各イベントにオペレーティングシステム（Windows、macOS、iOS、Android）とブラウザ（Chrome、Safari、Edge、Firefoxなど）を自動的にタグ付けします。

このセグメンテーションにより、たとえばiOS SafariのPasskey放棄率が高いか、またはWindows Chromeがより良いPasskey採用をもたらすかを確認できます。

このデータは、特にAppleのクロスオリジン制限がユーザーベースに予想以上に影響を与えている場合に、フォールバック戦略を微調整するのにも役立ちます。

私たちは、Passkeyファネルの各段階（作成プロンプト、成功した登録、ユーザーログイン、フォールバック使用）のダッシュボードビューを提供します。

リアルタイムのチャートにより、プロダクトマネージャーはトレンドを迅速に把握できます（例：新しいOSアップデートがPasskeyフローを壊した場合）。

自動アラートは、Passkeyの成功率が大幅に低下した場合にチームに通知できるため、新しいブラウザのバグや設定の問題を迅速に調査できます。

すべてのPasskeyフロー（作成からログインまで）は、タイムスタンプ付きのステップバイステップのイベントでログに記録され、詳細なフォレンジック分析が可能です。

ユーザーハッシュ、セッションID、またはデバイスシグネチャで迅速に検索して、ユーザーがどこで苦労したか、またはどのエラーコードが返されたかを正確に確認できます。

これは、大規模な展開にとって重要です。ここでは、逸話的なサポートチケットに頼るのではなく、ユーザーの問題を解決するために正確なデータが必要です。

Corbadoの分析プラットフォームは、Passkeyファネルに統合されたA/Bテストをサポートしています。異なるCTAテキスト、作成プロンプト、フォールバックメッセージ、またはチェックアウトフローでの「Passkeyを作成」ボタンの配置をテストします。

「Passkey承認率」や「フォールバック率」などのメトリクスは、各バリアントで並べて測定できます。

このアプローチは、主要なPasskey採用者が時間とともにフローを洗練させる成功を模倣し、継続的な改善を保証します。

Corbadoのダッシュボードはすぐに使える視覚的なインターフェースを提供しますが、主要なデータポイント（例：Passkey作成の成功、ログイン）をBIまたはSIEMツールにエクスポートまたはWebhookすることもできます。

これにより、決済プロバイダーはPasskey KPIをより広範な分析スイートに組み込み、他のセキュリティ、マーケティング、または運用メトリクスと並行してPasskeysからのROIを追跡できます。

まとめ

OS/ブラウザの組み合わせ、作成フロー、ログインシナリオにわたるPasskeyジャーニーのすべてのステップを測定し、視覚化することで、CorbadoはPasskey提供を継続的に洗練させるために必要な洞察を提供します。これらの分析は、Passkeysが有効になっていることを確認するだけでなく、ユーザーが実際に大規模に採用しているかどうかを証明し、摩擦点を特定し、Passkeysが安全で摩擦のない支払いのために本当にパスワードを置き換える点まで使用率を押し上げるのに役立ちます。

決済プロバイダーにとって、ユーザーごとに1つのPasskeyを作成するだけでは、真にシームレスな認証体験を提供するには不十分なことがよくあります。実際には、ユーザーは頻繁にデバイスを切り替えます。職場のラップトップから個人のスマートフォン、タブレット、さらには共有の家族用コンピュータまで。同じアカウントに対してすべてのデバイスが有効なPasskeyを持っていることを保証することは、摩擦を減らし、パスワードへのフォールバックを防ぐために重要です。Apple Payは、iCloudに接続されたすべてのデバイスでiCloudアカウントを活用できることでこれを実現しています。

以下は、Corbadoがユーザーライフサイクル全体でマルチデバイスカバレッジを維持するのにどのように役立つかです。

• プライマリPasskey作成画面：Corbadoは最初に、各ユーザーに少なくとも1つのPasskey（「プライマリ」Passkey）を登録させることに焦点を当てます。これは、ユーザーが最初に決済フローに遭遇する場所（例：チェックアウト時、銀行のオンラインポータル、またはアカウント設定内）で行われます。

• セカンダリPasskey作成画面：ユーザーが最初のPasskeyを正常に登録した後、他のデバイスでの後続のログイン時に、短い「このデバイスを追加」フローを自動的に促すことができます。これにより、ユーザーはパスワードを再入力したり、フォールバック方法に切り替えたりすることなく、関連するすべてのデバイスで迅速に摩擦のないPasskeyアクセスを得ることができます。

ユーザーがあるデバイスにPasskeyを持っていても、2台目のデバイスではローカルPasskeyがないように見えることがあります（OSの新規インストール、Cookieの削除、または単にそのデバイスでPasskeyを作成したことがないため）。

Corbadoのアプローチは、しばしばハイブリッドステップを使用します。ユーザーは携帯電話の既存のPasskeyまたはフォールバック方法でログインし、その後、現在のデバイスでPasskeyを作成することで即座にギャップを「ヒーリング」できます。

この自己修復プロセスは、カバレッジを高く保ち、将来の繰り返しのフォールバック使用を排除するのに役立ちます。

クロスデバイスシグナルとCorbadoの「Passkey Intelligence」を通じて、システムは既存のPasskeyを持つユーザーが未登録のデバイスに切り替えたことを検出できます。

UX戦略が最大限のカバレッジを目指している場合、Corbadoは自動的に「次回フォールバックしなくて済むように、このデバイスにPasskeyを追加しますか？」と促すことができます。

ユーザーは一度きりのデバイスであればこれをスキップできますが、通常は一度説明されればPasskeyベースの生体認証ログインの利便性を高く評価します。

CorbadoのSDKは、「最初のPasskey作成」（つまり、ユーザーが初めて認証情報を登録するとき）と「セカンダリデバイス」作成のための異なる画面フローを提供します。

メッセージングは異なる場合があります。たとえば、「この新しいデバイスをPasskeyで保護する」対「最初のPasskeyを設定する」などです。

これにより、エンドユーザーにとって明確さが保証され、最初の登録と追加デバイスへのカバレッジ拡大の違いを理解できます。

時々、Passkey作成がセレモニーの途中で失敗したり、ユーザーのOSが古かったりすることがあります。そのようなシナリオでは、Corbadoは部分的な試みを記録し、可能な解決策（リダイレクト、手動フォールバック、またはクロスデバイスQRフロー）を優雅に提案します。

ユーザーはいつでも次のログイン試行時にそのデバイスでPasskeyの追加を再試行するか、別のデバイスの既存のPasskeyに頼ることができます。

Corbadoの分析は、最初にPasskeyを作成したユーザーの数だけでなく、複数のデバイスにPasskeysを拡大したユーザーの数も示します。

デバイスカバレッジ率（例：1デバイス vs. 2デバイス以上）を追跡し、それがフォールバック使用の減少や支払い成功の向上とどのように相関するかを確認できます。

これにより、チームはユーザー教育、アプリのプロンプト、または銀行ベースの登録フローを優先して、マルチデバイスのPasskey普及率を高めることができます。

まとめ：なぜマルチデバイスカバレッジが重要なのか

すべてのユーザーデバイスで一貫したカバレッジがなければ、「Passkey非対応」のデバイスを使用するたびに、ユーザーはフォールバック認証手段に戻らざるを得なくなるリスクがあります。これは摩擦のない体験を壊し、運用コストを高く保ちます（例：SMS料金、サポートのオーバーヘッド）。セカンダリPasskey作成画面、ハイブリッドフォールバックヒーリング、環境駆動型のプロンプトを提供することで、Corbadoはすべてのユーザーが最終的に使用するすべてのデバイスでPasskeysを維持できるようにし、全体的な採用率を高め、それらのイライラするフォールバックの瞬間を最小限に抑えます。

サードパーティのPasskeys SDKを構築する際の最大の誤解の1つは、最も難しい部分がWebAuthn呼び出し（例：navigator.credentials.create()やnavigator.credentials.get()）の実装であるということです。

実際には、これは「簡単な」部分です。基本的なセレモニーをトリガーするための1つか2つのAPI呼び出しです。真の複雑さと成功の真の決定要因は、大規模な採用を保証し、それらのAPI呼び出しの周りに完全なエコシステムを構築することにあります。

以下は、Passkeyの購入 vs. 構築ガイドによって補強された、最小限のセレモニーのみの実装がしばしば現実世界の結果をもたらさない理由を強調するキーポイントです。

• セレモニーの実装：Passkeyの作成または認証は、通常、navigator.credentials.create()またはnavigator.credentials.get()を呼び出すための数行のJavaScriptのみを伴います。

• 真の複雑さ：Passkeyフローが多くのブラウザで機能し、失敗を優雅に処理し、古いシステムのためのフォールバックを提供することを保証すること。また、堅牢なセッション管理、エラーロギング、分析、デバイスカバレッジ戦略なども必要になります。

• 予期せぬ落とし穴：Passkeysの「技術デモ」を超えると、クロスオリジンのブロック、埋め込みWebViewの制限、マルチデバイス同期の複雑さなどのエッジケースを発見します。これらは、素朴な自社製ビルドを頓挫させる未知の未知です。

• セレモニー vs. 採用：完璧なWebAuthnセレモニーを持っていても、低いユーザー採用率（例：5%未満のPasskey使用率）では、セキュリティやUXのメリットは最小限になります。

• 包括的アプローチ：成功したPasskeyの展開には、魅力的なユーザープロンプトやA/Bテストされたコピーライティングから、マルチデバイスカバレッジフロー、フォールバック処理、継続的な分析まで、基本的なセレモニー呼び出しをはるかに超えるすべてが必要です。

• 購入 vs. 構築ガイドからの洞察：このガイドは、Passkeysを有効にするだけでなく、Passkeyの採用を促進することが最終的にROIを決定することを強調しています。ユーザーが登録して積極的にPasskeysを使用しない場合、プロジェクトはコンバージョン率の改善なしに「MFA 2.0」で事実上停滞します。

• 不完全なフォールバックとエラー処理：高度なフォールバックロジックやリアルタイムのデバッグが欠けていると、ユーザーのロックアウトや高いサポートコストにつながる可能性があります。

• 断片化されたマルチデバイスカバレッジ：追加のデバイスを同期したり、Passkeyのギャップを「ヒーリング」したりする計画がなければ、ユーザーはプラットフォームを切り替えるたびにパスワードに戻ります。

• 限定的な分析とA/Bテスト：Passkey作成ファネルや環境使用に関するデータが不足していると、採用を体系的に改善したり、新しいブラウザの癖を迅速にトラブルシューティングしたりできません。

• 事前に構築されたUIとベストプラクティス：単にセレモニーのエンドポイントを公開するのではなく、適切なソリューション（Corbadoなど）は、ホワイトラベルの画面、フォールバックフロー、エラー処理、クロスデバイスカバレッジをバンドルします。

• 適応型インテリジェンスとロギング：Passkeyの存在の可能性を自動検出し、ユーザーに不足しているPasskeyの作成や修正を案内し、詳細なイベントログをキャプチャします。

• 採用に焦点を当てた「未知の未知」：メールベースのフォールバックや企業デバイスの扱い方など、多くの詳細は、ユーザーが実際の展開で遭遇し始めるまで明らかになりません。

• 採用戦略へのより深いダイブ：Passkeyの購入 vs. 構築ガイドは、コスト、市場投入までの時間、堅牢なPasskeyソリューションの隠れた複雑さのバランスを取る方法を強調しています。

• 現実世界のベンチマーク：主要な銀行やeコマースプロバイダーからの大規模な展開が、「簡単な」セレモニーロジックをコーディングした後に発生する未知の未知をどのように克服したかを学びます。

• 持続的な成功：実績のある採用パターンを持つ確立されたプラットフォームに投資することで、車輪の再発明に固執せず、途中でコストのかかる驚きを発見することがなくなります。

要約

単にWebAuthnセレモニーを接続するだけでは、意味のあるPasskey採用を達成するには不十分です。真の成功は、フォールバック、分析、マルチデバイス拡張、A/Bテストされたユーザージャーニーのようなエンドツーエンドのフローを編成することにかかっています。「単なるセレモニー」を超えた微妙な複雑さに対処することで、Passkeyプロジェクトを技術的な好奇心から、真に摩擦がなく、広く使用され、コストを節約する認証ソリューションに変えることができます。

クロスオリジンフロー、ユーザー採用、Passkeyライフサイクル管理に関する複雑さに加えて、ホスティングとデプロイメントの考慮事項は、あらゆる大規模なPasskeyソリューションにとって重要です。決済プロバイダーは、しばしば厳格なコンプライアンス、データレジデンシーの要求、および地域によって大きく異なる可能性のある回復力の要件に対処します。以下は、Corbado（または同様に堅牢なソリューション）がこれらの懸念にどのように対処するかです。

データ主権や規制フレームワーク（例：ヨーロッパのGDPR、カナダのPIPEDA、米国のNIST/HIPAA）に準拠するために、一部のプロバイダーはデータを特定の地理的境界内に保持する必要があります。

リージョン非依存のアーキテクチャは、Passkeyサービスを任意の希望するAWSリージョンにデプロイでき、パフォーマンスやスケーラビリティを犠牲にすることなく、地域のコンプライアンス要件を満たすことを保証します。

この柔軟性は、ユーザーベースが複数の国にまたがり、それぞれが異なるデータ処理ルールを施行している場合に特に重要です。

重要な決済認証フローにとって、ダウンタイムは許されません。CorbadoはマルチAZデプロイメントを採用し、主要なコンポーネントを複数のアベイラビリティゾーンに分散させます。

この設定は、1つのAZが停止または接続の問題を経験した場合でも、他のゾーンのPasskeyインフラがオンラインのままであり、ユーザーが認証を継続できることを保証するのに役立ちます。

その結果、金融サービスやeコマースサイトの厳しいSLAを満たす、より回復力のあるシステムが実現します。これらのサイトでは、わずかなダウンタイムでも重大な収益への影響につながる可能性があります。

一部の決済プロバイダーは、より厳格なデータ分離、カスタムコンプライアンスチェック、またはパッチやアップデートに対するより深い制御のために、プライベートな専用クラスターを好みます。

柔軟なソリューションは、両方の極端なケースをサポートできます。

• SaaS / マルチテナント：実装が迅速で、コストが低く、多くの中規模デプロイメントに適しています。

• 専用クラウドインスタンス：追加の分離やコンプライアンスが必要な方向けに、選択したリージョンに別のアカウントとデータベースインスタンスを用意します。

Passkeysは、急増するワークロードを処理する必要があります。大規模なトラフィックの急増（例：ホリデーシーズンのショッピングピークやイベントチケットの販売）は、固定容量のシステムを圧倒する可能性があります。

最新のPasskeyバックエンドは、使用パターンに基づいてコンピューティングインスタンスを追加または削除することで、リアルタイムで水平にスケーリングします。この自動スケーリングは、手動介入なしで一貫したパフォーマンスを保証します。

PCI-DSS、PSD2 SCA、またはISO 27001などの業界標準は、しばしば決済プロバイダーに適用されます。堅牢なPasskeyプロバイダーは、通常、既知のコンプライアンスフレームワークとすぐに統合できます。

• 保存時および転送中の暗号化：強力なTLSと、保存された認証情報に対するサーバーサイドまたはクライアントサイドの暗号化でデータを保護します。

• ロギングと監査証跡：各Passkey操作の詳細なログで、規制当局やインシデント調査に適しています。

• 定期的なセキュリティパッチ適用：特に流動的なマルチAZ環境で関連する脆弱性を防ぐための、自動的なOSおよびコンテナのパッチ適用。

真の回復力は、単一のリージョンを超えて広がります。一部のプロバイダーは、大規模な災害時に事業継続性を維持するために、クロスリージョンレプリケーションを義務付けています。

地理的冗長性は、Passkeyデータを別のリージョンまたは大陸に複製でき、リージョン全体のダウンタイムが認証フローを停止させないことを保証します。

まとめ：マルチAZとリージョン非依存

簡単にスケーリングし、地理的に適応し、ローカルの停止と大規模な災害の両方に耐えるPasskeyソリューションを選択することは、現代の決済プロバイダーにとって不可欠です。特に、複数の国で事業を展開しているか、厳格なコンプライアンスの下で運営している場合はなおさらです。マルチAZデプロイメントとリージョン非依存の構成をサポートすることで、Corbado（または同等のソリューション）は、ユーザーやデータがどこにあっても、決済Passkeyサービスが利用可能でコンプライアンスに準拠していることを保証します。

Passkeysは確かに、安全でユーザーフレンドリーな認証の次世代を代表するものです。しかし、決済プロバイダーは、従来のWebAuthn設計が直接対処していない特有の課題に直面しています。これらの制限は、特に以下の点で顕著です。

1. SafariがクロスオリジンPasskey作成（特にiframes内）を許可しないため、リダイレクトベースのアプローチか、以前に作成されたPasskeysへの依存を余儀なくされること。

2. AppleがSecure Payment Confirmation（SPC）をサポートしていないため、ブラウザやプラットフォーム間で摩擦のない、標準化された決済フローが妨げられること。

それにもかかわらず、Passkeysは、Apple Payのようなチェックアウト体験を提供しようとする決済プロバイダーにとって不可欠であり続けます。それは、エンドユーザーにとって合理化され、安全で、 delightfully simpleなものです。以下は、これらの課題にどのように対処できるか、そしてCorbadoがどのように役立つかです。

1. 決済プロバイダーがサードパーティのコンテキストでPasskeysを使用する際の現在の制限は何ですか？

• クロスオリジンの制限：Safari（および一部の古いブラウザ）は、iframeを介して埋め込まれた場合にnavigator.credentials.create()をブロックします。これは、それらのブラウザのマーチャント埋め込みフローでシームレスに新しいPasskeysを作成できないことを意味します。

• SPCサポートの欠如：AppleがSPCの採用を拒否することは、クロスオリジン決済確認を標準化する能力を制限し、プロバイダーにSafari対Chrome/Edgeで別々のアプローチを維持させることを余儀なくさせます。

• WebViewとネイティブアプリの制約：埋め込みWebViewはしばしばPasskeyフローを壊し、ドメインオリジンの整合性を管理するためにシステムブラウザセッションや他の専門的なアプローチを必要とします。

• 断片化されたデバイスカバレッジ：ユーザーがあるデバイスやブラウザでPasskeyを作成しても、他のデバイスではカバレッジが不足している可能性があり、フォールバックの使用を引き起こします。

2. 決済プロバイダーはこれらの制限をどのように克服し、サードパーティのPasskey統合を成功させることができますか？

• ハイブリッド（Iframe + リダイレクト）戦略を活用する：

  • クロスオリジンPasskeysを完全にサポートするブラウザにはIframeを使用し、シームレスな埋め込みUIを提供します。

  • Safariや互換性のないセットアップのフォールバックとしてリダイレクトを使用し、堅牢なPasskey作成が常に可能であることを保証します。

• ネイティブアプリでのシステムWebViewまたはブラウザリダイレクト：

  • マーチャントアプリにiframesを埋め込むのではなく、ASWebAuthenticationSession（iOS）またはChrome Custom Tabs（Android）に移行して、ドメインの継続性を維持します。

  • 採用に焦点を当てたツールキット：魅力的なPasskey作成プロンプト、マルチデバイスカバレッジフロー、および使用率を高く保つためのフォールバック「ヒーリング」ステップを提供します。

  • 高度な分析とA/Bテスト：

    • Passkeyの成功/フォールバック率、環境カバレッジ、およびユーザーフィードバックを継続的に測定して、フローを洗練させます。

    • Passkeyインテリジェンスを使用して、成功の可能性が高い場合にのみPasskeysを自動的に提示します。

このガイド全体を通して、私たちは単にnavigator.credentials.create()を接続するだけでは不十分であることを強調してきました。真の成功は、高いPasskey採用、一貫したユーザーエクスペリエンス、および回復力のあるマルチデバイスカバレッジにかかっています。それがCorbadoが優れている点です。

• Iframeとリダイレクトの統一サポート：CorbadoのSDKは、埋め込みPasskeyフローが実現可能か（例：ChromeやEdge）、またはリダイレクトが必要か（例：Safari）を自動的に検出します。これにより、マーチャントが複数のコードパスを維持する必要なく、互換性が最大化されます。

  • ワンタップ決済体験：Passkey Intelligenceにより、Corbadoはユーザーの環境が有効なPasskeyを持っている可能性が高いかどうかを即座に検出し、摩擦のない「Passkeyで支払う」フローをトリガーします。このアプローチは、Apple Payのワンタップチェックアウトと並行し、めったに使用されないMFAステップに追いやるのではなく、日常のPasskey使用を促進します。

  • 堅牢なマルチデバイスカバレッジ：Corbadoは、最初のPasskey作成とセカンダリPasskey拡張のための特別なフローを提供するため、各ユーザーはフォールバックまたはクロスデバイスQRを介してログインした後、新しいデバイスのカバレッジを迅速に追加できます。

  • フルスタックの採用フォーカス：統合された分析、A/Bテスト、およびエラー処理を通じて、Corbadoはプロバイダーが摩擦点を特定し、Passkeyの受け入れを体系的に最適化するのを支援します。これは、銀行の最初のPasskeyプロンプトからマーチャントのチェックアウト体験まで及びます。

  • 柔軟でコンプライアンスに準拠したホスティング：CorbadoのマルチAZ、リージョン非依存のデプロイメントは、厳格な決済業界のコンプライアンス（PCI DSS、PSD2 SCAなど）に準拠し、世界中のデータレジデンシールールへの準拠と稼働時間を保証します。

Appleの制限的なポリシーが避けられない摩擦を生み出す一方で、決済プロバイダーは以下の方法でサードパーティのPasskeysを成功裏に実装できます。

1. 埋め込みアプローチ（iframe）とリダイレクトフォールバックを組み合わせる。

2. ネイティブアプリ用に専門のシステムWebViewまたは外部ブラウザフローを採用する。

3. 堅牢な採用戦略に焦点を当てる：マルチデバイスカバレッジ、フォールバック「ヒーリング」、高度な分析、およびA/Bテスト。

Corbadoはこれらすべての要素をまとめ、Passkey登録、ワンタップ使用、分析主導の最適化、およびグローバル規模のホスティングをカバーするエンタープライズPasskeyプラットフォームを提供します。その結果、自社の決済サービスでApple Payのような真に摩擦のない体験が実現し、セキュリティの向上と優れたユーザージャーニーの両方を提供します。