Chrome 開發人員工具「WebAuthn」分頁的方式

Fawaz Mohammad
Fawaz Mohammad
GitHub
Nina Satragno
Nina Satragno
X

Web Authentication API (也稱為 WebAuthn) 可讓伺服器使用公開金鑰密碼編譯機制 (而非密碼) 註冊及驗證使用者。方法是啟用這些伺服器與強式驗證工具的整合功能。這些驗證工具可能是專用實體裝置 (例如安全金鑰)，或是與平台整合的工具 (例如指紋讀取器)。如要進一步瞭解 WebAuthn，請前往 webauthn.guide。

開發人員問題點

在這個專案之前，WebAuthn 缺乏 Chrome 上的原生偵錯支援。開發人員建構的應用程式使用 WebAuth，因此需要存取實體驗證工具。這項工作特別困難，原因有二：

  1. 驗證器有許多不同類型。開發人員必須使用許多不同的驗證器 (有時價格昂貴)，才能對多種設定和功能進行偵錯。

  2. 實體驗證工具在設計上具有安全性。因此，通常無法檢查其狀態。

因此，我們在 Chrome 開發人員工具中新增了偵錯支援功能，讓您更輕鬆地進行偵錯。

解決方案：新的 WebAuthn 分頁

WebAuthn 開發人員工具分頁可讓開發人員模擬這些驗證工具、自訂其功能，以及檢查其狀態，因此可大幅簡化 WebAuthn 的偵錯作業。

新的 WebAuthn 分頁

實作

為 WebAuthn 新增偵錯支援功能的程序分為兩個部分。

兩個部分的程序

第 1 部分：將 WebAuthn 網域新增至 Chrome 開發人員工具通訊協定

首先，我們在 Chrome 開發人員工具通訊協定 (CDP) 中實作了新的網域，並將其連結至與 WebAuthn 後端通訊的處理常式。

CDP 會將開發人員工具前端與 Chromium 連結。在我們的案例中，我們利用 WebAuthn 網域動作，在 WebAuthn 開發人員工具分頁和 Chromium 的 WebAuthn 實作項目之間建立橋接。

WebAuthn 網域可用於啟用和停用虛擬驗證器環境，這會將瀏覽器與實際的驗證器探索功能解除連結，並插入虛擬探索功能。

我們也會在該網域中公開方法，做為現有虛擬驗證器和虛擬探索介面的薄層，這些介面是 Chromium 的 WebAuthn 實作內容。這些方法包括新增及移除驗證器，以及建立、取得及清除註冊的憑證。

(請參閱程式碼)

第 2 部分：建構面向使用者的分頁

第二，我們在 DevTools 前端中建立了使用者專用分頁。這個分頁由檢視畫面和模型組成。自動產生的代理程式會將網域連結至分頁。

雖然需要 3 個必要元件，但我們只需要關注其中的兩個：模型和檢視畫面。第三個元件 (agent) 會在新增網域後自動產生。簡單來說，代理程式是前端和 CDP 之間的通訊層。

模型

模型是連結代理程式和檢視畫面的 JavaScript 層。在本案例中，模型相當簡單。它會從檢視畫面取得指令，建構可供 CDP 使用的請求，然後透過代理程式傳送。這類要求通常是單向的，不會將任何資訊傳回檢視畫面。

不過，我們有時會傳回模型的回應，為新建立的驗證工具提供 ID，或傳回儲存在現有驗證工具中的憑證。

(請參閱程式碼)

檢視畫面

新的 WebAuthn 分頁

我們使用檢視畫面提供使用者介面，讓開發人員在存取 DevTools 時找到該介面。其中包含：

  1. 用於啟用虛擬驗證器環境的工具列。
  2. 新增驗證器的專區。
  3. 用於顯示已建立的驗證器。

(請參閱程式碼)

啟用虛擬驗證器環境的工具列

工具列

由於大多數使用者互動都是與單一驗證器互動，而不是整個分頁，因此我們在工具列中提供的唯一功能，就是切換虛擬環境的開關。

為什麼需要這麼做？使用者必須明確切換環境，這點非常重要，因為這樣做會讓瀏覽器與實際的 Authenticator Discovery 斷開連線。因此，在開啟時，系統不會辨識已連結的實體驗證工具，例如指紋辨識器。

我們認為明確的切換鈕可提供更好的使用者體驗，特別是對於不預期實際停用探索功能的使用者。

新增「驗證器」專區

新增「驗證器」專區

啟用虛擬驗證器環境後，我們會向開發人員顯示內嵌表單，讓他們新增虛擬驗證器。在這個表單中，我們提供自訂選項，讓使用者決定驗證工具的通訊協定和傳輸方法，以及驗證工具是否支援本機金鑰和使用者驗證。

使用者按一下「Add」後，系統會將這些選項組合起來，並傳送至呼叫建立驗證工具的模型。完成後，前端會收到回應，然後修改 UI 以納入新建立的驗證器。

Authenticator 檢視畫面

Authenticator 檢視畫面

每次模擬驗證器時，我們都會在驗證器檢視畫面中新增一個部分來代表驗證器。每個驗證器區段都包含名稱、ID、設定選項、移除驗證器或將其設為啟用的按鈕，以及憑證表格。

Authenticator 名稱

您可以自訂驗證工具名稱，預設值為「Authenticator」，並與 ID 的最後 5 個字元串連在一起。原本的驗證器名稱是完整 ID，且無法變更。我們實作了可自訂的名稱，讓使用者可以根據驗證工具的功能、要模擬的實體驗證工具，或任何比 36 個半形字元的 ID 更容易理解的暱稱，為驗證工具命名。

憑證表

我們在每個 authenticator 區段中新增了表格，顯示 authenticator 註冊的所有憑證。每個資料列都會提供憑證資訊，以及移除或匯出憑證的按鈕。

目前，我們會透過輪詢 CDP 來取得每個驗證工具的註冊憑證，藉此收集填入這些資料表的資訊。我們預計日後會新增建立憑證的事件。

「Active」按鈕

我們也為每個驗證器部分新增了「啟用」圓形按鈕。目前設定為有效的驗證工具，將是唯一會監聽及註冊憑證的驗證工具。如果沒有這個功能，在有多個驗證工具的情況下註冊憑證就會變得不確定，這會導致在嘗試使用 WebAuthn 進行測試時發生致命缺陷。

我們在虛擬驗證器上使用 SetUserPresence 方法實作了活動狀態。SetUserPresence 方法會設定使用者是否已通過特定驗證工具的使用者狀態測試。如果我們關閉這項功能，驗證工具就無法監聽憑證。因此，只要確保最多只有一個驗證器 (設為有效的驗證器) 開啟，並停用所有其他驗證器的使用者狀態，我們就能強制確定行為。

在新增啟用按鈕時，我們面臨了一個有趣的挑戰，那就是避免競爭狀態。請參考下列情境：

  1. 使用者按一下 Authenticator X 的「Active」圓形按鈕，向 CDP 傳送要求，將 X 設為活動狀態。選取 X 的「Active」圓形按鈕，並取消選取其他所有項目。

  2. 隨後，使用者立即點選 Authenticator Y 的「Active」圓形按鈕，向 CDP 傳送要求，將 Y 設為有效。選取 Y 的「Active」圓形按鈕，並取消選取 X 的所有其他選項。

  3. 在後端，將 Y 設為有效的呼叫已完成並解析。Y 目前已啟用，所有其他驗證工具則未啟用。

  4. 在後端，將 X 設為有效的呼叫已完成並解析。X 目前處於啟用狀態，而其他所有驗證工具 (包括 Y) 皆未啟用。

目前的情況如下：X 是有效的驗證器。不過，X 的「Active」圓形按鈕未選取。Y 不是有效的驗證器。不過，系統會選取 Y 的「Active」圓形按鈕。前端與驗證工具的實際狀態不一致。這顯然是個問題。

解決方案：在單選按鈕和有效驗證器之間建立偽雙向通訊。首先，我們會在檢視畫面中維護變數 activeId，以便追蹤目前有效驗證工具的 ID。接著，我們會等待呼叫設定的驗證器啟用狀態傳回，然後將 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;
 }

用量指標

我們想追蹤這項功能的使用情形。一開始，我們提出了兩個選項。

  1. 計算開發人員工具中 WebAuthn 分頁開啟的次數。由於使用者可能會開啟分頁，但未實際使用，因此這個選項可能會導致計數過多。

  2. 追蹤工具列中「Enable virtual authenticator environment」核取方塊的切換次數。這個選項也可能會出現過度計算的問題，因為有些人可能會在同一個工作階段內多次開啟和關閉環境。

最終，我們決定採用後者，但透過檢查工作階段中是否已啟用環境，限制計數。因此，無論開發人員切換環境的次數為何，計數器只會增加 1。這是因為每次重新開啟分頁時，系統都會建立新的工作階段，因此會重設檢查，並允許再次遞增指標。

摘要

感謝您閱讀本郵件！如有任何改善 WebAuthn 分頁的建議，歡迎提出錯誤。

如要進一步瞭解 WebAuthn，請參考以下資源：

下載預覽管道

建議您將 Chrome Canary、開發人員版或Beta 版設為預設開發人員版瀏覽器。這些預覽管道可讓您存取最新的 DevTools 功能，測試最新的網路平台 API，並在使用者發現問題前，協助您找出網站的問題！

與 Chrome 開發人員工具團隊聯絡

請使用下列選項討論新功能、更新或任何與開發人員工具相關的內容。