前言：從理論到實作藍圖

在過去五天，我們深入研讀了 FIDO/WebAuthn 這部精密的「數位信任架構」。我們理解了它的基本原則（公鑰密碼學）、核心角色（RP, Authenticator），以及兩大核心儀式（註冊與驗證）。

今天我們要把腦中對理論的理解，轉化為一張張具體、可執行的建築藍圖。這份藍圖將指導我們在接下來的幾週內，如何安全、高效地建造出我們的次世代身分認證系統。

章節一：系統架構全覽 (System Architecture Overview)

在敲下第一行程式碼之前，我們必須先回答一個問題：「我們的系統由哪些部分組成？它們之間如何溝通？」

我們的系統主要由以下幾個關鍵組件構成：

1. Web 前端 (Client)：使用者與我們服務互動的主要入口。它負責呈現註冊/登入介面，並透過瀏覽器的 WebAuthn API 與使用者的驗證器溝通。
2. Flutter App (Client)：我們的行動端應用，它將在第三階段扮演「推播認證」的核心角色。它會直接與行動作業系統（Android/iOS）原生的 FIDO API 互動。
3. Firebase Functions (我們的 Relying Party 後端)：這是整個系統的大腦。所有 FIDO 註冊與驗證的邏輯都在這裡實現。它負責產生挑戰、驗證簽章，並與資料庫溝通。
4. Firestore (資料庫)：我們的信任資料庫。它將安全地儲存使用者的基本資料，以及最重要的——與 FIDO 相關的公鑰憑證。
5. Firebase Cloud Messaging (FCM)：負責在 Web 端發起登入請求時，向使用者的手機 App 發送推播通知的訊息通道。

從圖中可以看到，無論是 Web 或是 App，所有的核心驗證邏輯都收斂在後端（Firebase Functions），確保了安全策略的統一與集中管理。

章節二：資料庫結構設計 (Schema Design)

資料庫是我們「信任」的最終儲存地。一個清晰、安全的資料庫結構是專案成功的基石。基於 Firestore 的 NoSQL 特性，我們設計如下的集合（Collections）與文件（Documents）結構：

1. users 集合

這個集合用來儲存使用者的基本資訊。

• users/{userId}
  • email: (String) 使用者的電子郵件，用於登入識別。
  • displayName: (String) 使用者的顯示名稱。
  • createdAt: (Timestamp) 帳號建立時間。

2. credentials 子集合

這是 FIDO 的核心！每個使用者文件底下，都會有一個 credentials 子集合，用來存放該使用者註冊過的所有驗證器憑證。一個使用者可以擁有多個憑證（例如，一台筆電的 Touch ID 和一個 YubiKey）。

• users/{userId}/credentials/{credentialId}
  • publicKey: (String) 使用 CBOR 編碼後再轉為 Base64 的公鑰字串。這是驗證簽章的關鍵。
  • signCount: (Number) 簽章計數器。極其重要，用於防止憑證複製攻擊。初始值為 0。
  • transports: (Array of Strings) 記錄驗證器的類型，例如 ["internal"] 或 ["usb", "nfc"]。這有助於後續的登入流程優化。
  • createdAt: (Timestamp) 憑證註冊時間。
  • lastUsedAt: (Timestamp) 上次使用時間。

這樣的設計將使用者資料與 FIDO 憑證清晰地分開，同時利用子集合的特性，讓查詢特定使用者的所有憑證變得非常高效。

章節三：安全設計：引入威脅模型 (Threat Modeling)

一套沒有經過安全審視的架構，就像一棟地基不穩的大樓。現在，我們要戴上駭客的帽子，使用微軟開發的 STRIDE 模型來主動找出系統的潛在威脅，並檢視我們的 FIDO 架構是否能有效應對。

STRIDE 是六種安全威脅類型的縮寫：

通過 STRIDE 分析，我們可以充滿信心地說，我們選擇的 FIDO 架構在核心的身分安全威脅上，提供了業界頂尖的防護能力。

章節四：API 規格初探 (Initial API Specification)

最後，我們將上述設計收斂成一份清晰的後端 API 規格。這將是我們下週後端開發的「施工圖」。

註冊流程 API

1. POST /generate-registration-options

   • 用途: 產生註冊時需要的挑戰與選項。
   • Request Body: { "email": "user@example.com", "displayName": "User Name" }
   • Success Response (200): 回傳一個符合 WebAuthn 標準的 PublicKeyCredentialCreationOptions 物件。

2. POST /verify-registration

   • 用途: 驗證由瀏覽器回傳的註冊憑證。
   • Request Body: { "email": "user@example.com", "credential": { ...PublicKeyCredential } }
   • Success Response (200): { "verified": true }

驗證流程 API

1. POST /generate-authentication-options

   • 用途: 產生登入時需要的挑戰與選項。
   • Request Body: { "email": "user@example.com" }
   • Success Response (200): 回傳一個 PublicKeyCredentialRequestOptions 物件。

2. POST /verify-authentication

   • 用途: 驗證由瀏覽器回傳的登入斷言。
   • Request Body: { "email": "user@example.com", "assertion": { ...PublicKeyCredential } }
   • Success Response (200): { "verified": true, "token": "YOUR_JWT_OR_SESSION_TOKEN" }

結語：藍圖已定，準備動工！

今天，我們完成了從抽象理論到具體實踐的關鍵一步，設計了核心的資料庫結構，用嚴謹的威脅模型審視了其安全性，並最終產出了一份清晰的 API 實作藍圖。

我們不再只是「知道」FIDO 是什麼，而是「知道」我們要如何打造一個基於 FIDO 的安全系統。

第一週的理論基石已經奠定完成。從明天開始，我們將進行第一週的總回顧。下週，我們將捲起袖子，在 Firebase 的雲端環境中，鑄造我們系統的第一個信任錨點——後端 API！