ネイティブアプリパスキー向けのパスワードマネージャーテスト

エンタープライズPasskeyホワイトペーパー. パスキープログラム向けの実践ガイド、展開パターン、KPI。

重要なポイント

iOS 17とAndroid 14によって、サードパーティ製パスワードマネージャーがネイティブアプリでパスキープロバイダーとして機能するようになり、プロバイダーをまたいだ体系的なテストが必要になりました。
サードパーティ製パスワードマネージャーを利用するユーザーは全体の5〜10%に過ぎませんが、大規模な展開においては不釣り合いなほど多くのサポートチケットを発生させます。
5つの主要なターゲット（1Password、Bitwarden、Dashlane、Proton Pass、NordPass）は、EU、米国、英国、オーストラリア、ニュージーランドにおけるサードパーティ製パスワードマネージャーユーザーの85%をカバーしています。
一部のサードパーティ製パスワードマネージャーによる不適切なBE/BSフラグの設定は、本番環境におけるパスキーの同期失敗の大きな要因となっています。
AndroidのlaunchMode singleInstanceは、Credential Managerを別のタスクとして開く原因となります。singleTaskに切り替えることで、各OEM全体でのライフサイクルに関するバグを防ぐことができます。

1. はじめに：ネイティブアプリのパスキーとサードパーティ製パスワードマネージャーの出会い#

iOS 17とAndroid 14のリリースにより、ネイティブモバイルアプリにおけるパスキーの状況は根本的に変化しました。初めてサードパーティ製パスワードマネージャーがパスキープロバイダーとして機能できるようになり、iCloudキーチェーンとGoogleパスワードマネージャーによる独占状態が崩れました。これにより、ユーザーは1Password、Bitwarden、Dashlaneなどの信頼できる独自のソリューションをネイティブアプリの認証フローに持ち込むことができます。これはユーザーの選択肢という点で大きな勝利ですが、開発者には大きな複雑さをもたらします。パスキーの実装は、ネイティブモバイルアプリケーション内の異なるパスワードマネージャー間で異なる動作をする可能性があります。そのため、どのチームにとってもネイティブアプリのパスキーとサードパーティ製パスワードマネージャーを適切にテストすることが重要です。

この包括的なガイドでは、サードパーティ製パスワードマネージャーを用いたネイティブアプリのパスキーテストに対する、私たちの実戦的なアプローチを共有します。パスキーのエコシステムは2025年に大きく成熟しましたが、実際の導入にあたっては、多様なパスワードマネージャーの実装にわたる慎重な検証が依然として必要です。私たちはこれまでの経験を実用的なテスト計画としてまとめ、ネイティブアプリがユーザーの好むパスワードマネージャーとシームレスに連携できるようにしました。

Passkeysチートシート. パスキープログラム向けの実践ガイド、展開パターン、KPI。

チートシートを入手

2. 本番環境でパスキーテストが重要な理由#

2.1 ユーザーが独自のパスワードマネージャーを持ち込む#

パスワードマネージャーのエコシステムは、プラットフォームネイティブなソリューションを超えて進化しています。ユーザーは、クロスプラットフォームの同期、エンタープライズ機能、プライバシーの好みなど、特定のニーズに基づいて1Password、Bitwarden、Dashlane、Proton Pass、NordPassなどのサードパーティ製パスワードマネージャーを積極的に選択しています。ネイティブiOS / Androidアプリは、ユーザーに信頼するパスワード管理ソリューションの変更を強制することなく、この多様性に対応する必要があります。

Corbadoのページ全体で測定したデータに基づくと、一般ユーザーの5〜10%のみがサードパーティ製パスワードマネージャーに依存していることがわかります。この数字は低く聞こえるかもしれませんが、大規模な環境で作業している場合、パスキー実装の認識とサポートチケットの数に大きな影響を与えます。一部のパスワードマネージャーはWebAuthn仕様をわずかに異なる方法で実装しており、ユーザーエクスペリエンスの微妙な変化やバグさえも引き起こすことがわかっています。

2.2 ネイティブアプリにおける異なるUXパターン#

ネイティブiOSおよびAndroidアプリは、パスキーを利用するための異なる方法を提供します。Androidでは、パスキーのオーバーレイや、パスキーセレモニーをトリガーする手動のテキストフィールド入力に遭遇します（Webアプリの場合、AndroidはConditional UIもサポートしています）。iOSは、Conditional UIや手動のテキストフィールド入力とともに、独自のパスキーオーバーレイのセットを提示します。さらに、確認すべき他のエッジケースもあります。全体として、ネイティブアプリケーションは以下を適切に処理する必要があります。

ページ読み込み時にすぐに表示されるパスキーオーバーレイログイン
利用可能なパスキーを自動提案するConditional UIログイン（iOSのみ）
ユーザーがボタンをクリックする前にユーザー名を提供するテキストフィールドログイン
別のデバイスでパスキーを使用するためのクロスデバイス認証 (CDA)
パスキーが利用できない場合のフォールバックメカニズム

2.3 WebAuthnフラグには正確さが求められる#

正しいフラグ設定により、パスキーがデバイスやプラットフォーム間で期待通りに機能するかどうかが決まります。重要な値には以下が含まれます。

Relying Party ID (rpID): Webとネイティブの実装間で正確に一致する必要があり、パスキーがバインドされるドメインです。
ユーザー検証: ユーザーがローカル認証を提供する必要があることを決定します。
レジデントキー/発見可能な認証情報: ユーザー名なしの認証を有効にします（Conditional UIを可能にします）。
バックアップ適格性とバックアップ状態 (Backup eligibility (BE) and backup state (BS)): パスキーのクロスデバイス同期を許可します。

設定を誤ったフラグが常に即座の障害を引き起こすとは限りません。ただし、パスキーが1つのデバイスで利用可能であっても、デバイス間で同期されない（同じサードパーティ製パスワードマネージャーが両方のデバイスで利用可能であっても）といった微妙な問題や不整合を引き起こす可能性があります。テストでの発見の1つは、一部のサードパーティ製パスワードマネージャーがBE/BSフラグを不適切に設定しており、パスキーの問題の大きな割合を占めていることでした。

2.4 シングルインスタンスアプリにおけるライフサイクル管理#

シングルアクティビティ (Android) およびシングルシーン (iOS) アーキテクチャでは、細心の注意を払ったライフサイクル管理が必要です。パスワードマネージャーのシートが表示されて閉じられたとき、アプリは状態を保存し、コールバックを処理し、正しく再開する必要があります。これは、launchModeの設定が予期しない動作を引き起こす可能性があるAndroidでは特に重要です。

たとえば、MainActivityをlaunchMode="singleInstance"に設定すると問題が発生することがわかりました。一部のAndroidバージョンとOEMのカスタマイズでは、このモードによりPasskey Credential ManagerのUIが別のタスクとして開かれます。これにより、「最近（Recents）」画面に混乱を招く追加のアプリエントリが追加されるだけでなく、パスキーダイアログが開いている間にアプリがバックグラウンドに移行した場合、アプリがハングアップする可能性もあります。

推奨される修正方法は、設定をlaunchMode="singleTask"に変更することです。これにより、Credential Managerが別のタスクを生成するのを防ぎ、異なるOEM（Samsung、Google、Vivoなど）間でより予測可能なライフサイクルを確保し、ベンダー固有のバグのリスクを軽減します。これは、ナビゲーション、オーバーレイ、ディープリンクをテストするためのより安定した基盤を提供します。

このようなライフサイクルの問題は、実際にはアプリケーションレベルの問題であるにもかかわらず、「パスワードマネージャーのバグ」を装うことがよくあります。適切なインストルメンテーションと異なるプロバイダー間でのテストは、これらのパターンを早期に特定するのに役立ちます。

3. テスト環境のセットアップ#

3.1 ターゲットとするパスワードマネージャー#

ネイティブアプリのパスキーテストは、最も広く採用されているサードパーティ製パスワードマネージャーに焦点を当ててください。

主要なターゲット（必須のカバレッジ）：

1Password
Bitwarden
Dashlane
Proton Pass
NordPass

副次的なターゲット（ユーザーベースに基づく）：

地域プロバイダー（例：Samsungデバイス用のSamsung Pass）
ビジネスユーザーをターゲットとする場合のエンタープライズソリューション
ベースラインとしてのプラットフォームのデフォルト（Googleパスワードマネージャー、iCloudキーチェーン）

利用可能なすべてのパスワードマネージャーをテストしようとする誘惑は避けてください。ユーザーベースの90%を占めるプロバイダーに焦点を当てます。私たちの分析によると、5つの主要なターゲットがEU/米国/英国/オーストラリア/ニュージーランドにおけるサードパーティ製パスワードマネージャーユーザーの85%をカバーしていました。

3.2 飛行前チェックリスト#

各テストの実行を開始する前に、クリーンで再現可能な環境を確保してください。

1. 認証情報の状態をクリーンにする：

対象のRP IDの既存の認証情報をすべて削除する
ブラウザとアプリのキャッシュをクリアする
パスワードマネージャーから完全にサインアウトし、再度サインインする
ターゲットアプリを強制終了して再起動する

2. テスト環境を安定させる：

安定したネットワーク接続を確保する（テスト中はVPNを使用しない）
テストを自動化する場合はUIアニメーションを無効にする
一貫したデバイスの向きを使用する
OSバージョン、アプリバージョン、パスワードマネージャーバージョンを文書化する

4. 包括的なテスト計画#

各テストでは、パスキー機能の特定の側面を検証します。合格/不合格のステータスと、異常に関する詳細なメモを使用して、結果を体系的に文書化します。

4.1 コア認証フローテスト#

テスト 1: パスキー作成の中止 (従来のログイン成功後)#

グレースフルなキャンセル処理を検証する

✓ パスワードマネージャーのシートが正しく開く
✓ ユーザーがパスキーを作成せずにキャンセルする
✓ アプリがログイン画面に戻る ✓ パスワードマネージャーに孤立した認証情報がない
✓ UIに適切な再試行オプションが表示される

テスト 2: パスキーの作成 (従来のログイン成功後)#

認証フロー後のパスキー作成を検証する

✓ ローカル認証が確実に起動する
✓ 生体認証が正常に完了する
✓ 正しいRP IDで認証情報が作成される
✓ アプリがループすることなく認証済み状態に移行する

テスト 3: 既存のパスキーによる認証#

標準的な認証シナリオをテストする

✓ パスキーのオーバーレイUIが表示されるか、テキストフィールドのシナリオでユーザーがユーザー名を提供する ✓ 生体認証のスキャンと単一の生体認証プロンプトが認証の成功につながる
✓ 選択ループやシートの再表示がない
✓ 認証後もセッションが安定している

テスト 4: 設定からのパスキー作成#

アプリ内パスキー管理を検証する

✓ 正しいRP ID、発見可能性、およびBE/BSフラグ
✓ 作成後もアプリが認証されたままである
✓ パスワードマネージャーが正しいラベルで即座に更新される

テスト 5: パスキーの削除と再ログインの試行#

認証情報のライフサイクル管理をテストする

✓ 設定でパスキーを削除する ✓ パスキーによるログインが不可能になる
✓ 適切なフォールバックオプションが提供される

4.2 クロスプラットフォーム互換性テスト#

テスト 6: ネイティブで作成したパスキーをWebで使用する (同一デバイス)#

アプリからWebへの移植性を検証する

✓ ブラウザがアプリで作成されたパスキーを認識する
✓ 選択シートに正しいRPの関連付けが表示される
✓ QR/CDAの迂回なしに認証が完了する

テスト 7: Webで作成したパスキーをネイティブアプリで使用する#

Webからアプリへの認証情報共有をテストする

✓ アプリがWebで作成された認証情報を選択画面に表示する
✓ 初回の認証試行が成功する
✓ パスワードへの強制的なフォールバックがない

テスト 8: クロスデバイス同期 (モバイルからデスクトップ)#

ネイティブアプリからデスクトップブラウザへのパスキー同期を検証する

✓ アプリで作成されたパスキーがデスクトップのパスワードマネージャーに同期される ✓ 同期されたパスキーがデスクトップブラウザでシームレスに機能する ✓ QRコード / クロスデバイスフローがトリガーされない ✓ ループやエラーなしに認証が完了する

テスト 9: クロスデバイス同期 (デスクトップからモバイル)#

デスクトップブラウザからネイティブアプリへのパスキー同期を検証する

✓ デスクトップで作成されたパスキーがモバイルのパスワードマネージャーに同期される ✓ ネイティブアプリが同期されたパスキーを正しく表示する ✓ パスワードへのフォールバックなしに認証が成功する ✓ ログがアサーションを正しいクレデンシャルIDに関連付けている

テスト 10: Web用のオーセンティケーターとしてのモバイル#

スマートフォンをセキュリティキーとして使用するシナリオを検証する

✓ スマートフォンがWeb CDA用にアプリで作成された認証情報を提供する
✓ 「利用可能なパスキーがありません」という誤ったエラーが出ない
✓ モバイルでの生体認証後にWebセッションが完了する

5. よくある問題と緩和戦略#

私たちの広範なテストにより、サードパーティ製パスワードマネージャーのパスキー統合に影響を与えるいくつかの繰り返し発生するパターンが明らかになりました。

クロスデバイス同期の遅延#

問題: あるデバイスで作成された認証情報が他のデバイスにすぐに表示されない場合があります。

解決策: エクスポネンシャルバックオフによる再試行ロジックを実装します。同期の遅延を経験しているユーザーに手動の更新オプションを提供します。

バージョン固有の動作#

問題: パスワードマネージャーの動作は、特にAndroid 14以降とiOS 17以降で、OSバージョン間で大きく異なります。

解決策: 互換性マトリックスを維持し、検出されたOSバージョンに基づいてフローを調整します。最適なエクスペリエンスのための最小バージョン要件を検討してください。

6. 結論: 本番環境対応のパスキーサポートの構築#

ネイティブアプリでのサードパーティ製パスワードマネージャーのパスキーサポートを成功裏に実装するには、体系的なテストと細部への注意が必要です。実際のテストを通じて洗練された私たちの包括的なテスト計画は、パスキー統合を検証するための強固な基盤を提供します。

本番環境への展開に向けた重要なポイント：

体系的にテストする: 私たちのテスト計画をベースラインとして使用し、特定のユースケースに合わせて調整します。
ユーザーの選択を尊重する: プラットフォームのデフォルトだけでなく、ユーザーが好むパスワードマネージャーをサポートします。
継続的に監視する: 本番環境でエッジケースをキャッチするために、包括的なログ記録を実装します。
徹底的に文書化する: プロバイダー固有の動作と回避策の明確な記録を維持します。

パスキーのエコシステムは急速に進化し続けています。パスワードマネージャーは実装を定期的に更新し、オペレーティングシステムは新機能を導入し、WebAuthn仕様自体も進歩しています。今すぐ堅牢なテストフレームワークを確立することで、技術が成熟するにつれて適応する準備が整います。

新しいパターンが現れるにつれて、私たちはSDKとテスト方法論を更新し続けます。包括的なサードパーティ製パスワードマネージャーのテストへの投資は、サポートの負担を軽減し、ユーザー満足度を向上させるという形で報われます。結局のところ、ユーザーがどのパスワードマネージャーを選択しても、認証は単に機能するべきなのです。

Corbadoについて

Corbadoは、大規模なconsumer認証を運用するCIAMチームのためのPasskey Intelligence Platformです。IDPのログや一般的なanalyticsツールでは見えないものを可視化します。どのデバイス、OSバージョン、ブラウザ、credential managerがpasskeyに対応しているか、なぜ登録がログインにつながらないのか、WebAuthnフローのどこで失敗するか、OSやブラウザのアップデートがいつ静かにログインを壊すか — Okta、Auth0、Ping、Cognito、あるいは自社IDPを置き換えることなく、すべてを把握できます。2つのプロダクト：Corbado Observeは passkeyとその他あらゆるログイン方式のobservabilityを提供します。Corbado Connectは analytics内蔵のmanaged passkeyを追加します（既存のIDPと併用）。VicRoadsはCorbadoで500万人超のユーザーにpasskeyを提供しています（passkey有効化率+80%）。 Passkeyエキスパートに相談する →