前言

昨天已經用簡單的方式介紹過 FIDO2、WebAuthn 與 CTAP 的基本分工。今天不再重複「三者分別是什麼」，而是往下一層拆解它們實際如何合作。

本文會從 WebAuthn 的註冊與登入請求開始，說明瀏覽器如何把操作交給內建或外部 Authenticator；使用外部 Authenticator 時，CTAP 又如何透過 USB、NFC、BLE 或 Hybrid Transport 傳遞指令。最後再說明不同 Authenticator 類型，以及 Attestation 在註冊流程中的作用。

因此，本文將以 Day19 所介紹的 Passkey 登入流程為基礎，進一步說明 FIDO2、WebAuthn、CTAP 與 Authenticator 在實際運作中的分工與互動。

今天內容涵蓋：

1. FIDO2 認證請求的傳遞路徑
2. WebAuthn 定義哪些介面
3. CTAP 負責什麼
4. Authenticator 在哪裡，以及 Attestation 有什麼用途

一、FIDO2 認證請求的傳遞路徑

一次 FIDO2 認證會從 Relying Party 發出請求，經由 WebAuthn 進入 Client；接下來是否使用 CTAP，則取決於選擇的是內建或外部 Authenticator。內建 Authenticator 通常由作業系統透過平台介面操作；安全金鑰或另一台手機等外部 Authenticator，才會透過 CTAP 溝通。完成建立憑證或簽章後，結果再經由 WebAuthn 回到 Relying Party。

對照上圖，整體架構可以分成三個部分：

• 服務端（Relying Party）： 網站與後端服務負責建立註冊或登入請求，並在收到結果後驗證 Challenge、Origin、RP ID 與簽章。
• 使用者裝置（Client Device）： 瀏覽器接收網站的 WebAuthn 請求，作業系統再依照使用者選擇，決定使用內建 Authenticator 或外部 Authenticator。
• 外部 Authenticator： 安全金鑰或另一台手機等裝置，透過 CTAP 接收建立憑證或產生簽章的指令。

除了上述三個主要區域，圖中的服務端下方還標示了「FIDO Server（Metadata）」。這表示服務端可以視需要取得 Authenticator 的 Metadata；實際提供這些資料的是 FIDO Metadata Service（MDS），內容包括 Authenticator 的型號、認證狀態與安全資訊。Relying Party 通常只會在註冊或政策檢查時查詢，一般 Passkey 登入不一定會使用此服務。

在主要認證路徑中，網站與 Client 之間都由 WebAuthn 負責傳遞標準請求與回應；只有在使用外部 Authenticator 時，Client 才需要再透過 CTAP 與該裝置溝通。

二、WebAuthn 定義哪些介面

昨天已從使用者角度說明 Passkey 的註冊與登入流程；本節改從網站開發者的角度，整理 WebAuthn 在 Relying Party 與 Client 之間定義的介面與資料邊界。

在瀏覽器環境中，開發者最常接觸以下兩個 API：

WebAuthn 主要定義以下三項內容：

1. 請求格式： 網站必須提供哪些註冊或登入參數，例如 Challenge、RP ID 與使用者驗證條件。
2. 網站身分邊界： 瀏覽器會檢查目前的 Origin 與 RP ID，避免其他網域任意要求使用不屬於自己的憑證。
3. 回應格式： Authenticator 產生的公開金鑰、憑證識別資訊或簽章，必須以標準結構回傳給服務端。

瀏覽器完成介面與網站來源檢查後，服務端仍須驗證 Challenge、Origin、RP ID 與簽章，才能接受註冊或登入結果。

💡WebAuthn 本身不保存私密金鑰，也不負責執行簽章；這些工作由 Authenticator 完成。網站只需要透過 WebAuthn 提出註冊或登入要求，後續由瀏覽器與作業系統決定如何操作對應的 Authenticator。

三、CTAP 負責什麼

CTAP 不是提供給網站直接呼叫的 API，而是瀏覽器／作業系統用來操作外部 Authenticator 的通訊協定。當 WebAuthn 請求抵達 Client，且使用者選擇安全金鑰或另一台手機時，Client 才會把相應動作轉成 CTAP 指令。

本文所稱的 CTAP 主要指 CTAP2，也是目前 FIDO2 與 Passkey 使用的版本。

WebAuthn 與 CTAP2 的主要動作可以這樣對照：

CTAP 如何連接外部 Authenticator

CTAP 指令可以透過不同方式傳送，實際採用哪一種方式，取決於 Authenticator 與 Client 支援的能力：

網站開發者不需要分別撰寫「使用 Windows Hello」、「讀取 USB 安全金鑰」或「連接手機」的程式，只要呼叫 WebAuthn。接著要使用哪一個 Authenticator，以及透過平台介面、USB、NFC、BLE 或 Hybrid Transport 連接，會由瀏覽器與作業系統處理。

四、Authenticator 在哪裡，以及 Attestation 有什麼用途

Authenticator 是實際保存或使用 Passkey 私密金鑰，並負責建立金鑰與產生簽章的元件。它可能位於目前使用的裝置中，也可能是另外連接的安全金鑰或手機。

Authenticator 位於目前裝置或外部裝置

Platform 與 Roaming 的分類，描述的是 Authenticator 和「目前正在登入的裝置」之間的關係：

例如，在 Mac 上直接使用 Touch ID 登入時，使用的是 Platform Authenticator；若在電腦上掃描 QR Code，改用手機裡的 Passkey 登入，手機就是外部的 Roaming Authenticator。

這兩種分類看的是「這次登入時，Authenticator 位於哪裡」，不是看 Passkey 從哪裡同步而來。

Attestation 用來確認什麼

一般 Passkey 登入只需要確認簽章是否正確，不必知道使用者使用哪一種裝置。但在企業或高安全需求環境中，Relying Party 可能還要確認「這組憑證是不是由核准的 Authenticator 建立」，這就是 Attestation 的用途。

可將 Attestation 理解為 Authenticator 在註冊時提供的裝置來源證明。它可以協助確認 Authenticator 的廠商、型號或認證狀態，但不能用來證明使用者本人是誰。

例如，公司若規定員工只能使用特定型號的安全金鑰，便可在註冊時取得 Attestation，並搭配第一節提到的 FIDO Metadata Service（MDS）檢查該型號是否符合政策。一般網站若只在意 Passkey 能否正確完成簽章，通常不需要要求 Attestation。

小結

FIDO2、WebAuthn 與 CTAP 的關係可以整理成以下重點：

• FIDO2： 整體公開金鑰認證架構，主要由 WebAuthn 與 CTAP 組成。
• WebAuthn： 負責 Relying Party 與瀏覽器／作業系統之間的標準請求與回應。
• CTAP： 負責 Client 與外部 Authenticator 之間的溝通；使用內建 Authenticator 時不一定會經過 CTAP。
• Authenticator： 保存或使用私密金鑰，並執行建立憑證與簽章等密碼學操作。
• Attestation： 提供可選的 Authenticator 來源資訊，主要用於企業政策或特定安全需求。

下一篇將先介紹 Authentication（認證）與 Authorization（授權）的差異，釐清「確認使用者是誰」與「決定使用者可以做什麼」這兩個階段。之後再依序介紹 RBAC、ABAC、ACL 與 ReBAC 等存取控制模型。

參考資源

• FIDO Authentication Specifications Overview
• FIDO2：Web Authentication（WebAuthn）
• Client to Authenticator Protocol（CTAP 2.2）
• Web Authentication API Level 2－W3C
• Quick overview of WebAuthn、FIDO2 and CTAP－Yubico
• WebAuthn APIs－Microsoft Learn
• FIDO Passkeys and Cross-Device Authentication