題幹與適用場景
產品想把少量加密設定綁定到使用者的 WebAuthn 憑證，以減少伺服器端狀態。請說明 largeBlob 的適用場景、註冊與驗證階段的讀寫差異、客戶端如何判斷結果，以及不支援時如何保持登入和資料正確性。
面試官考察點
- 是否理解 largeBlob 是與單一憑證關聯的 opaque 資料，不是通用客戶端儲存。
- 是否區分註冊時的
support、驗證時的read/write及對應輸出欄位。 - 是否注意 FIDO/驗證器容量、可探索憑證和一次只能寫入一個憑證等限制。
- 是否能設計能力探測、伺服器備份、隱私和失敗降級。
回答前需要釐清的問題
- 資料是否必須跟著憑證走，還是伺服器資料庫、IndexedDB 已足夠？
- 資料大小、機密性、可恢復性和跨裝置同步要求是什麼？
- 目標驗證器是否支援 largeBlob，是否使用可探索憑證？
- 寫入失敗、憑證遺失或使用者換裝置後，系統如何恢復？
30 秒回答框架
我會把 largeBlob 當成特定驗證器能力，而非主要儲存。註冊時要求 support: preferred 並讀取 supported；驗證時用 read 或 write，寫入要精確指定一個憑證，結果透過 blob 或 written 判斷。資料應加密、限量並保留伺服器可恢復副本。能力缺失、容量不足或寫入失敗時繼續使用伺服器狀態，不阻塞登入，也不把未確認寫入視為成功。
分步驟深入解答
1. 選擇正確的資料邊界
規範把 largeBlob 定義為與憑證關聯的 opaque 資料。它適合少量、與該憑證綁定的設定或金鑰材料，不適合取代使用者資料、跨憑證同步或大型物件資料庫。驗證器容量有限，伺服器仍應保存恢復所需資訊。
2. 註冊階段只探測能力
註冊擴充使用 largeBlob: { support: "preferred" } 或 required。supported 只表示建立出的憑證是否支援儲存；註冊階段不能直接寫入 blob。若使用 required，不支援的驗證器應被排除，產品要評估是否降低登入覆蓋率。
3. 驗證階段分開讀寫
驗證時可要求 read: true 讀取，或提供 write 寫入；兩者同時出現會失敗。寫入要求 allowCredentials 恰好包含一個憑證，成功後檢查 written。只有讀取成功才有 blob，不能只看擴充物件存在。
4. 設計隱私、恢復與降級
驗證器上的資料是 opaque，不代表應用層加密；客戶端和伺服器應自行做加密、版本和完整性校驗。憑證不可用、裝置不支援、容量不足或使用者拒絕時，回退伺服器副本。日誌只記錄能力與結果，不記錄 blob 內容。
高品質示範回答
我不會把 largeBlob 當成伺服器端狀態的替代品。它適合把少量、不可解釋的資料與某個 WebAuthn 憑證綁定。註冊時用 support: preferred 做能力探測，讀取 supported；驗證時選擇 read 或 write，寫入必須只針對一個憑證，並檢查 blob 或 written。應用層負責加密、版本和完整性，伺服器保留可恢復副本。對不支援的驗證器、可探索憑證限制、容量不足、寫入失敗和換裝置，都回到伺服器狀態且不阻塞驗證。只有明確接受相容性損失並有遷移方案時，才考慮 required。這樣利用驗證器儲存，同時保持登入和資料恢復可靠。
常見錯誤
- 把 largeBlob 當成 IndexedDB、Cookie 或任意大小的雲端同步儲存。
- 誤以為註冊階段可以直接寫入 blob。
- 同時送出
read和write，或寫入時指定多個憑證。 - 只判斷擴充物件存在，沒有檢查
supported、blob或written。 - 未加密就把敏感資料寫進 opaque blob。
- 驗證器不支援時阻斷登入，沒有伺服器端回退。
追問及應對
preferred 與 required 如何選擇？
preferred 允許繼續選擇不支援的驗證器並走降級；required 會排除不支援的候選驗證器。除非產品能接受覆蓋率下降且必須依賴該能力，否則優先 preferred。
為什麼寫入必須只有一個憑證？
規範要求寫入操作透過唯一的 allowCredentials 目標定位要更新的憑證。多個候選會導致不支援錯誤，應用應先確定使用者選擇的憑證。
裝置遷移時怎麼處理？
把 blob 視為可選快取或金鑰副本，伺服器保存恢復材料。新裝置用重新註冊或驗證流程取得伺服器狀態，不能假設驗證器上的 blob 會自動跨裝置同步。