Chrome DevTools の [WebAuthn] タブの作成方法

Fawaz Mohammad 氏
Fawaz Mohammad
GitHub
Nina Satragno 氏
Nina Satragno
Twitter

Web Authentication API（WebAuthnWebAuthn とも呼ばれます）を使用すると、サーバーはパスワードではなく公開鍵暗号を使用して、ユーザーの登録と認証を行うことができます。これは、これらのサーバーと強力な認証システムを統合することで実現されています。これらの認証システムは、専用の物理デバイス（セキュリティ キーなど）の場合もあれば、プラットフォーム（指紋認証リーダーなど）と統合されている場合もあります。WebAuthn の詳細については、webauthn.guide をご覧ください。

デベロッパーの課題

このプロジェクト以前は、WebAuthn には Chrome でのネイティブなデバッグ サポートがありませんでした。WebAuth を使用するアプリを構築しているデベロッパーは、物理的な認証システムへのアクセスを必要としていました。これは、次の 2 つの理由で特に困難でした。

  1. 認証システムにはさまざまな種類があります。幅広い構成と機能をデバッグするには、開発者がさまざまな、ときには高価な、さまざまな認証システムを利用する必要がありました。

  2. 物理的な認証システムは、設計上安全です。そのため、通常、状態を検査することはできません。

そのため、Chrome DevTools にデバッグのサポートを直接追加することで、これを容易にしたいと考えました。

解決策: 新しい [WebAuthn] タブ

[WebAuthn DevTools] タブでは、デベロッパーが認証システムのエミュレート、機能のカスタマイズ、状態の確認を行えるため、WebAuthn のデバッグがはるかに簡単になります。

新しい [WebAuthn] タブ

実装

WebAuthn にデバッグ サポートを追加するプロセスは、2 つの部分で構成されるプロセスでした。

2 パートのプロセス

パート 1: Chrome DevTools プロトコルに WebAuthn ドメインを追加する

まず、Chrome DevTools プロトコル（CDP）に新しいドメインを実装しました。これは、WebAuthn バックエンドと通信するハンドラにフックします。

CDP は、DevTools のフロントエンドを Chromium に接続します。今回は、WebAuthn ドメイン機能を利用して [WebAuthn DevTools] タブと Chromium の WebAuthn 実装を橋渡ししました。

WebAuthn ドメインを使用すると、仮想認証システム環境を有効または無効にできます。この環境では、ブラウザと実際の認証システムの検出が切断され、代わりに仮想検出がプラグインされます。

また、ドメイン内では、Chromium の WebAuthn 実装の一部である既存の Virtual Authenticator および Virtual Discovery インターフェースのシンレイヤとして機能するメソッドを公開しています。これらのメソッドには、認証システムの追加と削除、登録済みの認証情報の作成、取得、消去が含まれます。

（コードを読みます）。

パート 2: ユーザー向けのタブを作成する

次に、DevTools フロントエンドにユーザー向けのタブを作成しました。タブは、ビューとモデルで構成されています。自動生成されたエージェントがタブとドメインを接続します。

必要なコンポーネントが 3 つありますが、そのうちの 2 つ（modelとmodel）だけを考慮すればよいのです。3 つ目のコンポーネントであるエージェントは、ドメインを追加した後に自動生成されます。簡単に言うと、エージェントはフロントエンドと CDP の間で通話を伝送するレイヤです。

モデル

このモデルは、エージェントとビューを接続する JavaScript レイヤです。このモデルのモデルは非常にシンプルです。ビューからコマンドを取得し、CDP で使用できるようにリクエストを作成して、エージェント経由で送信します。通常、これらのリクエストは一方向であり、ビューに情報は返送されません。

ただし、新しく作成された認証システムの ID を提供する、または既存の認証システムに保存されている認証情報を返すために、モデルからのレスポンスを返すことがあります。

（コードを読みます）。

ビュー

新しい [WebAuthn] タブ

このビューは、デベロッパーが DevTools にアクセスする際に表示されるユーザー インターフェースを提供するために使用します。これには以下のものが含まれます。

  1. 仮想認証システム環境を有効にするツールバー。
  2. 認証システムを追加するセクション。
  3. 作成された認証システムのセクション。

（コードを読みます）。

仮想認証システム環境を有効にするツールバー

toolbar

ユーザーとのやり取りのほとんどは、タブ全体ではなく一度に 1 つの認証システムを使用するため、ツールバーで提供される機能は仮想環境のオンとオフの切り替えのみです。

この操作が必要な理由ユーザーが環境を明示的に切り替える必要があることが重要です。切り替えると、ブラウザと実際の認証システムの検出との接続が解除されます。そのため、この機能がオンになっている間は、指紋リーダーなどの物理的な認証システムが接続されていても認識されません。

Google は、明示的な切り替えによりユーザー エクスペリエンスが向上すると判断し、特に、実際の検出が無効になると予想せずに [WebAuthn] タブに移動するユーザーにとっては便利であると判断しました。

[認証システム] セクションの追加

[認証システム] セクションの追加

仮想認証システム環境を有効にすると、仮想認証システムを追加できるインライン フォームがデベロッパーに表示されます。このフォームではカスタマイズ オプションを使用して、認証システムのプロトコルと転送方法、および認証システムが常駐鍵とユーザー確認をサポートしているかどうかをユーザーが決定できます。

ユーザーが [追加] をクリックすると、これらのオプションがバンドルされ、認証システムの作成を呼び出すモデルに送信されます。この処理が完了すると、フロントエンドはレスポンスを受信し、新しく作成された認証システムが含まれるように UI を変更します。

認証システム ビュー

認証システム ビュー

認証システムがエミュレートされるたびに、それを表すセクションが認証システムビューに追加されます。各認証システムのセクションには、名前、ID、構成オプション、認証システムを削除またはアクティブに設定するためのボタン、認証情報テーブルがあります。

認証システムの名前

認証システムの名前はカスタマイズ可能で、デフォルトでは「認証システム」がその ID の末尾 5 文字に連結されます。当初、認証システムの名前は完全な ID であり、変更できません。カスタマイズ可能な名前を実装し、ユーザーがその機能に基づいて認証システム、またはエミュレートする物理的な認証システム、または 36 文字の ID よりも少し理解しやすいニックネームにラベルを付けられるようにしました。

認証情報テーブル

各認証システムのセクションに、認証システムによって登録されたすべての認証情報を示すテーブルを追加しました。各行には、クルデンシャルに関する情報と、クルデンシャルを削除またはエクスポートするためのボタンが表示されます。

現在、Google は CDP をポーリングして各認証システムに登録されている認証情報を取得することで、これらのテーブルを埋めるための情報を収集しています。将来的には、認証情報を作成するためのイベントを追加する予定です。

[アクティブ] ボタン

また、各認証システムのセクションに [有効] ラジオボタンも追加しました。現在アクティブに設定されている認証システムのみが、認証情報をリッスンして登録します。これがないと、複数の認証システムが与えられた認証情報の登録は非決定性となり、それらを使用して WebAuthn をテストしようとすると致命的な欠陥になります。

アクティブ ステータスの実装は、SetUserPresence メソッドを使って仮想認証システムに実装しています。SetUserPresence メソッドは、特定の認証システムに対してユーザー プレゼンスのテストが成功するかどうかを設定します。無効にすると、認証システムは認証情報をリッスンできなくなります。そのため、少なくとも 1 つの認証システム（アクティブとして設定されている認証システム）を有効にし、他のすべての認証システムでユーザー プレゼンスを無効にすることで、確定的な動作を強制できます。

アクティブ ボタンを追加する際に直面した興味深い課題は、競合状態の回避でした。次のシナリオを考えてみます。

  1. ユーザーが認証システム X の [アクティブ] ラジオボタンをクリックし、X を有効にするリクエストを CDP に送信します。X の [Active] ラジオボタンが選択され、他のボタンはすべて選択されていません。

  2. その直後に、ユーザーが認証システム Y の [アクティブ] ラジオボタンをクリックし、Y を有効にするリクエストを CDP に送信します。Y の [Active] ラジオボタンが選択され、X のその他のラジオボタンはすべて選択されていません。

  3. バックエンドで、Y をアクティブに設定する呼び出しが完了し、解決されました。Y は有効になり、他のすべての認証システムは無効になります。

  4. バックエンドで、X をアクティブに設定するための呼び出しが完了し、解決されました。X は有効になり、Y を含む他のすべての認証システムは有効になりません。

その結果、X はアクティブな認証システムであるようになります。ただし、X の [Active] ラジオボタンは選択されていません。Y はアクティブな認証システムではありません。ただし、Y では [Active] ラジオボタンが選択されています。フロントエンドと認証システムの実際のステータスの間に不一致があります。明らかにこれは問題です。

Google の解決策: ラジオボタンとアクティブな認証システムとの間に疑似双方向通信を確立します。まず、現在アクティブな認証システムの ID を追跡するために、ビュー内に変数 activeId を保持します。次に、呼び出しによって認証システムがアクティブに設定されるのを待ってから、activeId をその認証システムの ID に設定します。最後に、各認証システムのセクションをループ処理します。そのセクションの ID が activeId と等しい場合は、ボタンを「選択済み」に設定します。それ以外の場合は、ボタンを未選択に設定します。

次のように表示されます。


 async _setActiveAuthenticator(authenticatorId) {
   await this._clearActiveAuthenticator();
   await this._model.setAutomaticPresenceSimulation(authenticatorId, true);
   this._activeId = authenticatorId;
   this._updateActiveButtons();
 }
 
 _updateActiveButtons() {
   const authenticators = this._authenticatorsView.getElementsByClassName('authenticator-section');
   Array.from(authenticators).forEach(authenticator => {
     authenticator.querySelector('input.dt-radio-button').checked =
         authenticator.getAttribute('data-authenticator-id') === this._activeId;
   });
 }
 
 async _clearActiveAuthenticator() {
   if (this._activeId) {
     await this._model.setAutomaticPresenceSimulation(this._activeId, false);
   }
   this._activeId = null;
 }

使用状況の指標

この機能の使用状況を追跡したいと考えていました。当初は 2 つの選択肢を思いつきましたが、

  1. DevTools の [WebAuthn] タブが開かれるたびにカウントします。この場合、誰かが実際にタブを使用せずにタブを開く可能性があるため、過剰カウントにつながる可能性があります。

  2. ツールバーの [Enable virtual validator environment] チェックボックスがオンになった回数を追跡します。このオプションには、同じセッションで環境のオンとオフが何度も切り替えられる可能性があるため、過剰カウントという問題も発生していました。

最終的には後者を採用することにしましたが、セッション内で環境がすでに有効になっているかどうかを確認してカウントを制限しました。したがって、デベロッパーが環境を切り替えた回数に関係なく、カウントは 1 だけ増加します。タブが再度開くたびに新しいセッションが作成され、チェックがリセットされて指標が再び増分されるからです。

概要

ご精読ありがとうございました。WebAuthn タブの改善に関するご提案がありましたら、バグとしてお知らせください。

WebAuthn について詳しくは、以下のリソースをご覧ください。

プレビュー チャネルをダウンロードする

デフォルトの開発ブラウザとして、Chrome Canary、Dev、Beta の使用を検討してください。これらのプレビュー チャネルでは、最新の DevTools 機能にアクセスしたり、最先端のウェブ プラットフォーム API をテストしたり、ユーザーが事前にサイトに関する問題を発見したりすることができます。

Chrome DevTools チームへのお問い合わせ

投稿内の新機能や変更点、または DevTools に関するその他の事項について議論するには、以下のオプションを使用します。

  • crbug.com からご提案やフィードバックをお寄せください。
  • DevTools の [その他のオプション] その他   > [ヘルプ] > [DevTools の問題を報告する] を使用して、DevTools の問題を報告する。
  • @ChromeDevTools でツイートします。
  • DevTools の新機能の YouTube 動画または DevTools のヒントの YouTube 動画で、コメントを記入してください。