ネイティブアプリのパスキー：サードパーティ製パスワードマネージャーのテスト

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

この包括的なガイドでは、サードパーティ製パスワードマネージャーを使ったネイティブアプリのパスキーテストに関する、私たちが実戦で検証済みのアプローチを紹介します。2025年になり、パスキーのエコシステムは大幅に成熟しましたが、実際の現場での実装には、多様なパスワードマネージャーの実装にわたる慎重な検証が依然として必要です。私たちは、ネイティブアプリがユーザーの好むパスワードマネージャーとシームレスに連携することを確認するための、実践的なテストプランに私たちの経験を凝縮しました。

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

Corbadoのページ全体で測定したデータによると、一般的なユーザーのうちサードパーティ製パスワードマネージャーに依存しているのはわずか5〜10%です。この数字は低く聞こえるかもしれませんが、大規模な環境で作業している場合、パスキー実装の評価やサポートチケットの数に大きな影響を与えます。一部のパスワードマネージャーはWebAuthn仕様の実装が微妙に異なり、ユーザー体験の微妙な違いや、ときにはバグにつながることさえあるのを私たちは見てきました。

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

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

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

• Relying Party ID (rpID)：Web実装とネイティブ実装で完全に一致する必要があり、パスキーが紐づけられるドメインです
• ユーザー検証：ユーザーがローカル認証を提供する必要があることを決定します
• レジデントキー/発見可能なクレデンシャル：ユーザー名なしの認証を可能にします（Conditional UIを許可します）
• バックアップ適格性（BE）とバックアップ状態（BS）：パスキーのクロスデバイス同期を可能にします

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

シングルアクティビティ（Android）およびシングルシーン（iOS）のアーキテクチャでは、綿密なライフサイクル管理が必要です。パスワードマネージャーのシートが表示されて閉じられたとき、アプリは状態を維持し、コールバックを処理し、正しく再開しなければなりません。これは特にAndroidで重要で、launchModeの設定が予期せぬ挙動を引き起こすことがあります。

例えば、MainActivityをlaunchMode="singleInstance"に設定すると問題が発生することがわかりました。一部のAndroidバージョンやOEMのカスタマイズでは、このモードによってパスキーのCredential Manager UIが別のタスクとして開かれてしまいます。これは、「最近使ったアプリ」画面に紛らわしい追加のアプリアイコンが増えるだけでなく、パスキーダイアログが開いている間にアプリがバックグラウンドに回るとハングアップする原因にもなり得ます。

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

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

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

主要な対象（必須のカバレッジ）：

• 1Password
• Bitwarden
• Dashlane
• Proton Pass
• NordPass

二次的な対象（ユーザーベースに応じて）：

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

利用可能なすべてのパスワードマネージャーをテストしたいという誘惑に駆られないようにしましょう。ユーザーベースの90%を代表するプロバイダーに集中します。私たちの分析では、EU/USA/UK/AUS/NZにおけるサードパーティ製パスワードマネージャーユーザーの85%を、上記の5つの主要な対象がカバーしていました。

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

1. 認証情報（クレデンシャル）のクリーンな状態：

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

2. テスト環境の安定化：

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

各テストはパスキー機能の特定の側面を検証します。結果は合格/不合格のステータスと、異常があった場合は詳細なメモを用いて体系的に記録します。

正常なキャンセル処理を検証する

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

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

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

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

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

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

✓ 正しいRP ID、発見可能性、BE/BSフラグ ✓ 作成後もアプリが認証済み状態を維持する ✓ パスワードマネージャーが正しいラベルですぐに更新される

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

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

アプリからWebへのポータビリティを検証する

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

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

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

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

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

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

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

電話をセキュリティキーとして使用するシナリオを検証する

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

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

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

解決策： 指数バックオフを用いた再試行ロジックを実装します。同期遅延を経験しているユーザーのために、手動での更新オプションを提供します。

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

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

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

本番環境へのデプロイにおける重要なポイント：

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

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

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