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

法瓦茲穆罕默德
Fwaz Mohammad
妮娜.薩特拉格諾 (Nina Satragno)
Nina Satragno

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

開發人員問題點

在在此專案中,WebAuthn 沒有 Chrome 原生偵錯支援,開發人員建構使用 WebAuth 的應用程式時,必須存取實體驗證器。這麼做特別困難,有兩個原因:

  1. 驗證器有多種不同的風格。開發人員必須對多種設定和功能進行偵錯,他們才能存取許多不同 (有時可能昂貴) 的驗證工具。

  2. 實體驗證器在設計上融入安全考量因此,通常無法檢查其狀態。

我們希望藉由在 Chrome 開發人員工具中直接新增偵錯支援功能,簡化這項作業。

解決方案:新的 WebAuthn 分頁

WebAuthn DevTools 標籤可讓開發人員模擬這些驗證器、自訂功能,並檢查其狀態,讓 WebAuthn 偵錯變得更加容易。

新的 WebAuthn 分頁

導入作業

為 WebAuthn 新增偵錯支援的過程分為兩個部分。

程序分成兩部分

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

首先,我們在 Chrome 開發人員工具通訊協定 (CDP) 中導入了新網域,後者會將新網域掛入與 WebAuthn 後端通訊的處理常式。

CDP 可將開發人員工具的前端與 Chromium 連結。在這個案例中,我們使用 WebAuthn 網域來連結 WebAuthn DevTools 分頁和 Chromium 實作 WebAuthn。

WebAuthn 網域可讓您啟用及停用虛擬 Authenticator 環境,藉此中斷瀏覽器與真實 Authenticator 探索之間的連線,以及改用虛擬探索的插頭。

此外,我們還會在網域中公開做為後層的方法,讓這些方法能做為 Chromium 的 WebAuthn 實作中的現有 Virtual Authenticator 和虛擬探索介面。這些方法包括新增及移除驗證器,以及建立、取得及清除已註冊的憑證。

(請參閱程式碼)。

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

其次,我們在開發人員工具前端中建立了面向使用者的分頁。分頁中是由檢視畫面和模型組成。自動產生的代理程式會將網域與分頁連結。

雖然還需要 3 個必要元件,但我們只需要考慮其中兩個:modelmodel。新增網域後,第 3 個元件是「代理程式」,簡單來說,代理程式是指在前端與 CDP 之間通話的層。

模型

模型是 JavaScript 層,用來連結代理程式和檢視畫面。在這個例子中,這個模型非常簡單。系統會從檢視畫面中接收指令、建構要求,讓 CDP 可以使用這些要求,然後透過代理程式傳送這些要求。這些要求通常為單向,且未傳回任何資訊。

不過,有時模型會傳回回應,藉此為新建立的驗證器提供 ID,或是傳回儲存在現有驗證器中的憑證。

(請參閱程式碼)。

檢視畫面

新的 WebAuthn 分頁

我們會使用檢視畫面來提供開發人員存取開發人員工具時可找到的使用者介面。內容如下:

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

(請參閱程式碼)。

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

工具列

由於大多數使用者互動一次是透過一個驗證器進行,而非整個分頁,因此我們在工具列中提供唯一開啟及關閉虛擬環境的功能。

為什麼需要這麼做?請務必讓使用者明確切換環境,因為這會中斷瀏覽器與真實 Authenticator 探索之間的連線。因此開啟這項功能時,無法辨識實體驗證器 (例如指紋讀取器) 的連結。

我們決定,明確切換可帶來更好的使用者體驗,尤其對於那些在沒有預期停用實際探索功能的使用者想要瀏覽 WebAuthn 標籤的使用者而言更是如此。

新增「Authentics」部分

新增「Authentics」部分

啟用虛擬驗證器環境後,我們會向開發人員提供內嵌表單,讓他們新增虛擬驗證器。這份表單提供自訂選項,方便使用者決定驗證器的通訊協定和傳輸方式,以及驗證器是否支援常駐金鑰和使用者驗證。

使用者按一下「Add」後,系統會整合這些選項並傳送至模型,讓模型發出呼叫以建立驗證器。完成後,前端會收到回應,然後修改 UI,加入新建立的驗證器。

Authenticator 檢視畫面

Authenticator 檢視畫面

每次模擬驗證器時,系統都會在驗證器檢視畫面中新增一個區段來表示驗證器。每個「驗證器」部分都包含名稱、ID、設定選項、用於移除驗證器或設為啟用器的按鈕,以及憑證表格。

Authenticator 名稱

驗證器的名稱可以自訂,並預設為「Authenticator」(驗證器 ID 的最後 5 個字元)。原先驗證者的名稱原本就是完整 ID,無法變更。我們實作可自訂的名稱,讓使用者根據其功能、用途模擬的實體驗證器,或是比 36 個字元 ID 更容易理解的任何暱稱,為驗證者加上標籤。

憑證資料表

我們在每個驗證器部分新增表格,顯示驗證器註冊的所有憑證。在每個列中,我們會提供憑證相關資訊,以及移除或匯出憑證的按鈕。

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

「啟用」按鈕

並在每個驗證器部分新增「啟用」圓形按鈕。只有目前設定的驗證器會監聽及註冊憑證。如果沒有這麼做,因為有多位驗證器才有憑證註冊作業無法確定,當您嘗試使用這類驗證器測試 WebAuthn 時便相當嚴重。

我們使用 SetUserPresence 方法在虛擬驗證器中實作有效狀態。SetUserPresence 方法可設定特定驗證器的使用者是否成功測試。如果關閉這項功能,驗證器就無法監聽憑證。因此,只要確保最多一個驗證器 (即啟用器) 都處於啟用狀態,並且針對所有其他驗證器停用使用者,就能強制實行確定性行為。

新增使用中的按鈕時,我們遇到了一項有趣的挑戰,那就是避免發生競爭狀況。請考量下列情境:

  1. 使用者按一下 Authenticator X 的「有效」圓形按鈕,傳送要求至 CDP,將 X 設為啟用。選取 X 的「Active」圓形按鈕,同時取消選取其他項目。

  2. 隨後使用者立即點選 Authenticator Y 的「啟用」圓形按鈕,傳送要求至 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. 追蹤工具列中的「啟用虛擬驗證器環境」核取方塊的切換次數。這個選項也可能導致超額計算問題,因為某些人可能會在同一工作階段中多次切換環境開關。

最後,我們決定採用後者,但藉由檢查環境是否已在工作階段中已啟用環境,限制計數方式。因此,無論開發人員切換環境多少次,我們都只會將計數增加 1。之所以有效,是因為系統會在您每次重新開啟分頁時建立新的工作階段,因而重設檢查,允許將指標再次遞增。

摘要

感謝您的閱讀!如有任何改善 WebAuthn 分頁的建議,歡迎提交錯誤告訴我們。

以下資源可協助您進一步瞭解 WebAuthn:

下載預覽頻道

建議您使用 Chrome Canary開發人員版Beta 版做為預設開發瀏覽器。這些預覽管道可讓您使用最新的開發人員工具、測試最先進的網路平台 API,以及在使用者操作之前在網站上找出問題!

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

使用下列選項,在文章中討論新功能和異動,或與開發人員工具相關的任何其他內容。

  • 透過 crbug.com 提供建議或意見。
  • 如要回報開發人員工具問題,請在開發人員工具中依序點選「更多選項」更多   >「說明」 >「回報開發人員工具的問題」
  • @ChromeDevTools 張貼推文。
  • 歡迎前往開發人員工具的 YouTube 影片或開發人員工具的 YouTube 影片提供新功能留言。