パスキーはシークレットモードで機能しますか？

ますます多くの企業が、自社のウェブサイトやアプリにパスキーを導入しています。その際、多くのソフトウェア開発者やプロダクトマネージャーは、パスキーがシークレットモードやプライベートブラウジングモードで機能するのかという疑問に直面します。これは、全体的なユーザー体験に大きな影響を与えるためです。

この記事では、以下の疑問にお答えします。

1. パスキーはシークレットモード/プライベートブラウジングモードで機能しますか？
2. Chrome、Safari、Edge、Firefoxのシークレットモード/プライベートモードにおけるパスキー認証の動作はどのようになりますか？

この知識があれば、さまざまなブラウザやOSでスムーズなユーザー体験を保証でき、アプリケーションをセキュリティと利便性の最前線に位置づけることができます。

パスキーは、従来のパスワードを必要とせずにユーザーを認証するための暗号鍵です。パスワード盗難やフィッシング攻撃に関連するリスクを排除することで、セキュリティを強化します。

通常、パスキーはデバイス内に安全に保存され、その機能はほとんどのOSでシークレットモードやプライベートモードでも一貫して維持されます。ただし、Windows 10には例外があります（下記参照）。デバイスがパスキーに対応していることが前提です。

シークレットモードやプライベートモードは、痕跡を残さずにインターネットを閲覧するためによく使われます。この機能はプライバシーを重視するユーザーにとって価値があり、パスキーのような認証方法がこれらのモードでシームレスに機能することが不可欠です。

しかし、WebAuthn開発の歴史を振り返ると、OSやブラウザによって動作が混乱しやすく、一貫性がないため、継続的な議論と改善が行われてきました（参考として、これらの古い議論やバグレポートをこちら、こちら、こちらでご覧ください）。

さまざまなブラウザやOSにおけるパスキーの動作を理解することは、互換性とスムーズなユーザー体験を確保する上で役立ちます。

パスキーはシークレットモード/プライベートブラウジングモードで機能しますか？

Windows 10 (22H2)では、パスキーが確実に機能しない唯一の例外を発見しました。プラットフォーム認証器（Windows Hello）を使用しようとしたところ、以下の2つのスクリーンショットのような表示が出ました。

Windows 10のChromeシークレットモードでのパスキーエラーメッセージ

Windows 10のEdge InPrivateモードでのパスキーエラーメッセージ

通常のブラウジングモードに切り替えると、すべてが期待どおりに機能したため、ポップアップのエラーメッセージは誤解を招くものです。

さらに、クロスプラットフォーム認証器（例：ハードウェアセキュリティキーであるYubiKeyや、QRコード/Bluetooth経由のクロスデバイス認証）を使用してみたところ、これは機能しました。

この問題をさらに掘り下げ、ブラウザのコンソールで以下の2つのコマンドを実行して、プラットフォーム認証器（PublicKeyCredential.isUserVerifyingPlatformAuthenticatorAvailable()）と条件付きUI（PublicKeyCredential.isConditionalMediationAvailable()）が利用可能かどうかを判断したところ、興味深い発見がありました。最初のPromiseはfalseを返し、2番目のPromiseはtrueを返しました。プラットフォーム認証器は条件付きUIが機能するために必須であるため、これは理にかなっていません。

Chrome 129（および同様にChromiumベースのEdge）以降、PublicKeyCredential.isUserVerifyingPlatformAuthenticatorAvailable()は、Windows 10のシークレット/InPrivateモードでもtrueを返すようになりました。以前は、シークレットモードではfalseでした。trueを返すようになったにもかかわらず、プラットフォーム認証器は新しいパスキーの作成には利用できず、ユーザーフローが壊れる原因となっています。

以下は、Windows 10の異なるChrome/EdgeバージョンとモードにおけるPublicKeyCredential.isUserVerifyingPlatformAuthenticatorAvailable()の戻り値を示す表です。

確認された動作：

• Windows 10のChrome/Edgeシークレットモードでは、Promiseがtrueを返すにもかかわらず、パスキー作成時にプラットフォーム認証器が表示されません。
• 代わりに、ユーザーはセキュリティキー（例：YubiKey）を追加するよう求められます。
• ハードウェアセキュリティキーはパスキー作成に引き続き使用できますが、これはWindows Helloのようなプラットフォーム認証器を使用する際の期待されるフローではありません。

変更の影響： これにより、シークレット/InPrivateモードでプラットフォーム認証器にパスキーを追加するフローが事実上壊れてしまいます。Chrome 129以降の調整は、主にシークレットモードでのパスキーによるログイン機能を有効にするために行われました。ログインフローは、パスキーのサポートを確認するために同じ検出メカニズム（PublicKeyCredential.isUserVerifyingPlatformAuthenticatorAvailable()）を使用しており、この変更によってログインがスムーズに進むようになります。しかし、意図しない結果として、プライベートブラウジングモードでプラットフォーム認証器を使用してパスキーを作成する際の体験が損なわれることになりました。

この変更に関する詳細は、Chromium Source Code Reviewおよび関連するissue tracker discussionで確認できます。パスキーの最適なサポートを提供したいウェブサイトにとって、現在この問題を軽減する唯一の方法は、シークレットモードを検出することです。Windows 10のChrome/Edgeでユーザーがシークレット/InPrivateモードを使用していることを特定することで、ウェブサイトはパスキー作成のためにプラットフォーム認証器のオプションを提供することを事前に回避できます。

プラットフォーム認証器としてWindows Helloを使用する場合、シークレットモード（Chrome）/InPrivateモード（Edge）でパスキーを作成する際にセキュリティポップアップが表示されます。これは、パスキーが保存され、後で非シークレットモードでも使用可能になることをユーザーに警告するものです（この動作はWindows 11 22H2でテストされました）。シークレットモードのユースケースの1つとして、ユーザーが情報の痕跡を残さずにアカウントを作成したい場合を考えると、この警告は理にかなっています。

Androidでシークレットモード（Chrome）/InPrivateモード（Edge）を使用する場合の動作はWindows 11と似ており、パスキーがパスワードマネージャーに保存され、パスワードマネージャーにアクセスできる人なら誰でもそのパスキーにアクセスできることをユーザーに伝える情報ポップアップが表示されます。

要約すると、パスキーは主要なブラウザやOSのシークレットモードおよびプライベートモードで、Windows 10でのパスキー作成に関する一部の特定の例外を除き、確実に機能します。Corbadoのソリューションを活用することで、開発者はパスキーを効率的に実装でき、プロダクトマネージャーはセキュリティを損なうことなくユーザー体験を向上させることができます。