題干與適用場景
SaaS 已有密碼登入，計畫加入 Passkey。使用者可能在手機、筆記型電腦與硬體安全金鑰上登入；部分憑據可由平台同步，企業高風險操作要求更強的使用者驗證。請設計註冊、驗證、帳戶恢復、遷移與觀測方案。
題目範圍是 WebAuthn 與服務端驗證邊界。Passkey 不會自動解決工作階段管理、帳戶恢復、裝置撤銷或業務授權。
面試官考察點
面試官會檢查你是否理解：瀏覽器與認證器持有私鑰，服務端保存公鑰；每次驗證使用一次性隨機 challenge；驗證器必須檢查 challenge、RP ID、origin、簽章以及所需的使用者存在/使用者驗證旗標。
優秀回答還會區分「抗釣魚」與「永不遺失」：同步憑據改善可用性，卻可能不符合最高等級的不可匯出要求。恢復流程若繞過同等強度的證明，整套方案仍會被最弱路徑擊穿。
回答前需要澄清的問題
- 哪些操作只需要登入，哪些操作必須滿足 UV 或裝置綁定？
- RP ID 是否涵蓋多個子網域？是否會在跨來源 iframe 中呼叫？
- 企業是否禁止可同步憑據，或只允許硬體金鑰？
- 帳戶恢復需要保留哪些既有因素，人工審查能否介入？
- 舊密碼、TOTP 與 Passkey 的遷移順序及撤銷期限是什麼？
30 秒回答框架
「服務端為每次註冊或登入產生一次性 challenge 並綁定工作階段，驗證後檢查 RP ID、origin、challenge、簽章與所需 UP/UV 旗標。註冊時只保存公鑰、credential ID、計數器與策略中繼資料，不保存私鑰。對同步憑據按風險分級；高風險操作要求 UV 或裝置綁定。恢復要使用既有強因素、短時一次性流程與風險審查，不能把簡訊當成無條件後門。」
分步驟深入解答
第一步：定義註冊與驗證資料
註冊前由服務端產生不可預測、短時有效且只使用一次的 challenge，保存到工作階段或一次性儲存。客戶端呼叫 navigator.credentials.create()，認證器產生金鑰對並回傳公鑰憑據。
服務端保存 credential ID、公鑰、所屬帳號、RP ID、簽章計數器、備份資格與備份狀態等必要中繼資料。私鑰始終留在認證器或平台憑據管理器中。
第二步：執行嚴格的驗證檢查
登入時服務端產生新的 challenge 與 publicKeyCredentialRequestOptions，客戶端呼叫 navigator.credentials.get()。收到 assertion 後驗證：
const valid = await verifyAuthenticationResponse({
response,
expectedChallenge: session.challenge,
expectedOrigin: "https://app.example.com",
expectedRPID: "app.example.com",
requireUserVerification: true
});驗證成功後立即消費 challenge，拒絕重複使用、過期或跨工作階段的回應，再根據公鑰驗證簽章。也要處理使用者取消、瀏覽器不支援與認證器暫時無法使用。
第三步：理解 RP ID、origin 與跨來源風險
RP ID 標識憑據所屬的依賴方；憑據不能拿去給另一個 RP ID 驗證。服務端同時檢查呼叫 origin，不能只比較主網域字串。跨來源 iframe 或 Related Origin Requests 要額外評估使用者是否清楚「正在為誰登入」，並在支援矩陣中單獨測試。
不能把「頁面顯示公司 Logo」當成來源證明。來源、RP ID、challenge 與簽章必須由瀏覽器/認證器上下文與服務端共同驗證。
第四步：按風險解釋 UP、UV 與同步狀態
UP 表示使用者與認證器發生互動；UV 表示認證器在本地完成使用者驗證。普通登入可以按風險選擇要求，轉帳、金鑰匯出或管理員操作則應要求 UV，並在服務端檢查回傳旗標。
同步憑據提升跨裝置可用性，但 NIST 指出同步會涉及金鑰可匯出性；是否符合某個身分保證等級，要按部署策略判斷。記錄備份資格與狀態，不能把「可同步」誤稱為「已經同步」或「裝置綁定」。
第五步：設計恢復、遷移與撤銷
使用者遺失裝置時，優先使用另一把已註冊的 Passkey、企業恢復金鑰或經審查的強身分流程。恢復 token 必須短時、單次、綁定工作階段並可撤銷；恢復後通知使用者、輪換工作階段，並讓使用者檢查及刪除舊憑據。
遷移密碼時保留可控過渡期，成功建立 Passkey 後逐步降低密碼依賴，不在同一次請求中靜默刪除所有舊因素。每個 credential 都有獨立撤銷狀態；異常計數器、風險裝置與恢復事件進入稽核流。
高品質示範回答
「我會先把安全目標分級。服務端每次註冊與驗證都產生一次性 challenge，放進短時工作階段；收到回應後驗證 challenge、RP ID、origin、簽章以及該操作要求的 UP/UV 旗標，成功後立即消費 challenge。資料庫只存公鑰、credential ID、計數器、帳號與備份狀態，私鑰不離開認證器。
跨來源 iframe 不預設開放，若必須使用就把呼叫 origin、頂層 origin 與 RP ID 寫入測試矩陣。普通登入可接受符合策略的同步憑據，高風險操作要求 UV 或裝置綁定。恢復優先使用其他強 Passkey 或企業恢復金鑰，短時一次、風險控制與通知必須齊全；簡訊只能作為有明確風險承受度的補充，不能成為繞過強驗證的永久後門。上線觀察 challenge 重放、origin 不匹配、UV 不滿足、恢復成功率與異常撤銷事件。」
常見錯誤
- 只驗證簽章 → 簽章正確不代表 challenge、RP ID 與 origin 正確 → 逐項檢查並消費 challenge。
- 把 UP 當成 UV → 使用者觸碰認證器不等於本地完成身分驗證 → 按高風險操作要求並檢查 UV。
- 把同步 Passkey 說成裝置綁定 → 同步狀態與是否已同步是不同事實 → 記錄備份資格/狀態並按身分保證等級決策。
- 恢復直接發簡訊連結 → 最弱路徑可接管整個帳戶 → 引入既有強因素、短時 token、風險控制與通知。
- 只按主網域檢查來源 → origin 包含協定、主機與連接埠 → 比較正規化的完整 origin。
- challenge 可以重複使用 → 被攔截的 assertion 可能被重放 → 隨機、短時、單次消費並綁定工作階段。
追問及應對
追問一：Passkey 為什麼能抗釣魚？
認證器根據來源與 RP ID 選擇憑據，並對服務端 challenge 與上下文簽章；釣魚站點不能讓認證器為另一個來源產生同一服務的有效證明。服務端仍必須驗證 origin、RP ID 與 challenge。
追問二：為什麼 challenge 不能只放在客戶端？
服務端必須知道自己發出的隨機值，才能判斷回應對應目前登入意圖並拒絕重放。客戶端生成或單獨保存的值不能證明服務端曾發起該次請求。
追問三：同步憑據是否一定不安全？
不應做二元結論。同步提升恢復性與跨裝置體驗，但金鑰可匯出性、提供者策略與組織身分保證要求不同。服務端應按風險等級檢查備份旗標，並對高風險操作要求更強因素。
追問四：使用者把所有裝置都遺失了怎麼辦？
恢復流程必須視為高風險驗證：使用企業恢復金鑰、另一種已審查的強因素或人工審核，限制時效與範圍，通知使用者並撤銷未知憑據。不能因為「方便找回」而永久降低登入強度。