題幹與適用場景
你負責一個多語言網站的「使用企業身分登入」入口。產品希望瀏覽器在使用者明確選擇後提供身分提供者帳號，安全策略又要求不能依賴第三方 Cookie 追蹤使用者。請設計 relying party（RP）、identity provider（IdP）和伺服器的協作，並說明 FedCM 不支援、使用者拒絕、多個 IdP、建立工作階段與登出時怎麼處理。
面試官考察點
高品質回答會先把 FedCM 定位為瀏覽器介導的身分聯合介面，而不是新的權杖驗證協定。候選人應說明 RP 透過 navigator.credentials.get() 請求身分，瀏覽器負責顯示選擇介面，IdP 回傳短期 assertion 或授權結果，伺服器仍驗證簽章、issuer、audience、nonce 和狀態後才建立本地工作階段。還要解釋第三方 Cookie 限制、權限政策、使用者選擇和傳統 OAuth/OIDC 重新導向回退的邊界。
回答前需要釐清的問題
身分協定與信任關係
確認 IdP 使用 OAuth、OIDC 還是自訂 assertion，RP 是否允許多個 IdP，以及伺服器既有的 JWKS、issuer 和 audience 設定。FedCM 不會取代 IdP 的簽章金鑰輪替和權杖校驗。
瀏覽器與隱私目標
確認目標瀏覽器、嵌入 iframe、企業政策和第三方 Cookie 現況。FedCM 支援範圍和 UI 行為依賴瀏覽器；不能把 Chrome 的行為假設成所有客戶端都一致。
帳戶關聯與退出策略
確認一個外部 subject 是否只能關聯一個本地帳戶、重複信箱如何處理、全域退出是否要求通知 IdP，以及使用者拒絕授權後是否能改用密碼或信箱登入。
30 秒回答框架
「我把 FedCM 當作瀏覽器控制的身分選擇層。RP 先從伺服器取得一次性狀態和請求參數，再呼叫 navigator.credentials.get()；瀏覽器顯示 IdP 帳號選擇，IdP 回傳受協定約束的身分結果。伺服器驗證 issuer、簽章、audience、nonce、state 和帳戶映射，成功後才建立本站工作階段。不支援時回退到受 CSRF 和 PKCE 保護的 OAuth/OIDC 流程。登出要分別處理本站和 IdP 工作階段，不能假設清掉一個 Cookie 就完成全域退出。」
分步驟深入解答
第一步：建立 RP 與 IdP 設定
伺服器為每個可信 IdP 保存 issuer、client ID、JWKS 位址、允許的協定和回呼策略。前端只取得目前頁面可用的設定識別，不接受使用者輸入的任意 IdP URL。多租戶場景按租戶綁定允許清單，避免開放重新導向或把權杖送往錯誤租戶。
第二步：建立一次性登入狀態
使用者點擊登入後，RP 伺服器產生不可預測的 state、nonce 和短期流程記錄，綁定瀏覽器工作階段、目標租戶和返回路徑。前端呼叫 FedCM 時帶上伺服器下發的參數。state 和 nonce 必須在伺服器保存並一次消費，不能由前端產生或長期重用。
第三步：執行瀏覽器介導請求
前端透過 navigator.credentials.get() 發起身分請求，頁面需要符合安全情境和相應權限政策。瀏覽器顯示帳號選擇 UI，使用者明確選擇後才繼續。FedCM 請求會使用專用的 fetch 目的標記，伺服器據此區分身分流程；前端不要把 UI 出現當成認證成功。
第四步：伺服器驗證身分結果
伺服器檢查回應的 issuer、簽章、過期時間、audience、nonce、state 和 subject，再按明確規則關聯本地帳戶。信箱只能作為輔助欄位，不能在未驗證時直接合併帳戶。驗證通過後才簽發本站工作階段，並記錄 IdP、subject、認證時間和風險訊號。
第五步：設計回退與錯誤狀態
瀏覽器不支援、權限政策阻止、使用者取消和網路失敗要分開處理。回退到 OAuth/OIDC 重新導向時使用 PKCE、嚴格的 redirect URI、state 和 nonce；回退路徑仍由同一個伺服器帳戶映射層收口。前端提示下一步，不暴露 issuer、權杖或內部校驗錯誤。
第六步：處理多個 IdP 與帳戶關聯
若有多個 IdP，頁面先展示業務允許的選項，瀏覽器和 IdP 再完成帳號選擇。伺服器按 (issuer, subject) 建立穩定外部身分鍵，禁止只憑信箱自動合併。使用者新增 IdP 時要求已登入工作階段或額外驗證，並記錄關聯和解除關聯稽核事件。
第七步：登出、撤銷與漸進發布
本站登出應撤銷本地 session、清除安全 Cookie 並使更新權杖失效；若協定或 IdP 支援，再呼叫其登出機制。FedCM 對某些依賴 Cookie 的登出能力可能有限，因此要明確「退出本站」和「退出身分提供商」的差異。發布時按瀏覽器能力和錯誤率逐步啟用，並保留可觀測的回退開關。
高品質示範回答
我會把系統拆成瀏覽器身分選擇、IdP 證明和 RP 工作階段三層。RP 伺服器先產生短期 state、nonce 和租戶綁定的流程記錄，前端在安全情境中發起 FedCM。瀏覽器展示身分選擇介面，使用者確認後由 IdP 回傳結果；伺服器根據 issuer 的 JWKS 驗證簽章、audience、nonce、state、過期時間和 subject，再把 (issuer, subject) 映射到本地帳戶，驗證通過後才建立本站工作階段。
瀏覽器不支援、政策阻止、取消和網路錯誤分別處理，並回退到使用 PKCE 的 OAuth/OIDC 重新導向。回退不會繞過同一套伺服器驗證和帳戶關聯規則。多個 IdP 只允許來自伺服器設定的清單，信箱不作為自動合併主鍵。登出至少撤銷本站工作階段；若要退出 IdP，則使用其協定能力並向使用者說明範圍。灰度發布時觀察成功率、取消率、回退率和帳戶關聯異常，確保隱私收益沒有換來無法診斷的登入故障。
常見錯誤
- 錯誤表現： 把 FedCM 回傳物件當成已經登入。→ 失敗原因： 瀏覽器介導選擇不等於伺服器驗證了 issuer、簽章和 nonce。→ 修正方法： 所有身分結果都進入統一伺服器校驗和工作階段建立流程。
- 錯誤表現： 只用信箱匹配既有帳戶。→ 失敗原因： 信箱可能未驗證、被回收或在不同 IdP 中重複。→ 修正方法： 以
(issuer, subject)為外部主鍵，信箱只用於提示和經確認的關聯。 - 錯誤表現： FedCM 失敗就直接把 token 放進前端儲存。→ 失敗原因： 增加 XSS 暴露面，也繞過原有工作階段策略。→ 修正方法： 讓伺服器交換並設定受保護的工作階段 Cookie，前端只處理狀態。
- 錯誤表現： 認為退出本站會自動退出 IdP。→ 失敗原因： 兩個工作階段的生命週期和協定能力不同。→ 修正方法： 分別撤銷本站工作階段和呼叫 IdP 登出能力，並清楚告知使用者範圍。
追問及應對
追問一：FedCM 和普通 OAuth 重新導向是什麼關係？
FedCM 改變的是瀏覽器介導的選擇與跨站互動方式，OAuth/OIDC 仍負責授權和身分證明。兩者可以共用 issuer、nonce、state、PKCE 和伺服器帳戶映射；回退時不能刪除這些校驗。
追問二：為什麼第三方 Cookie 限制會影響聯合登入？
嵌入式 IdP 過去可能依賴第三方 Cookie 識別已登入使用者。Cookie 被分區或阻止後，瀏覽器需要用顯式、使用者可見的身分選擇來繼續流程。FedCM 降低了隱式跨站識別，但不會替應用決定帳戶權限。
追問三：使用者拒絕一個 IdP 後能否自動換另一個？
不能把拒絕當成靜默授權。可以在頁面提供使用者主動選擇的其他允許 IdP 或密碼入口，並重新建立與目標 IdP 綁定的 state、nonce 和流程記錄，避免重用一次已結束的請求。
追問四：如何驗證灰度發布沒有傷害登入成功率？
按瀏覽器、IdP、國家和嵌入場景拆分成功率、取消率、權限阻止率、回退率、帳戶關聯衝突和平均完成時間。對異常 issuer、簽章失敗和 nonce 重放設置告警；保留伺服器開關，在錯誤率升高時只關閉 FedCM 入口而不改動既有 OAuth 驗證程式碼。