如何設計安全的 Magic Link 登入？
題目與使用情境
低風險 SaaS 希望使用者輸入信箱後收到一次性登入連結。請設計請求、寄送、驗證、工作階段建立、撤銷與稽核流程。回答要明確信箱被控制、連結被轉寄、郵件預取、重放、頻率濫用與高風險操作的邊界。
面試官考察什麼
- 能否使用不可預測、短時、單次使用的權杖。
- 是否避免帳戶枚舉、日誌洩漏與驗證介面暴力嘗試。
- 能否區分登入便利性與驗證保證、抗釣魚能力。
- 是否把工作階段、撤銷、通知、稽核與降級納入完整流程。
作答前的釐清問題
先確認業務風險、信箱是否已驗證、是否支援多裝置、連結有效期、郵件供應商、MFA 與高風險操作。若涉及支付、權限提升或敏感資料，應改用抗釣魚驗證或額外驗證，不把信箱連結當作唯一高保證因素。
30 秒回答框架
服務端產生高熵隨機權杖，只存雜湊、使用者、用途、過期時間與使用狀態；對已存在與不存在信箱保持一致回應並限速。連結透過 HTTPS 驗證，原子地消費權杖，再建立短期工作階段並旋轉工作階段識別。權杖只允許使用一次，失敗、過期、撤銷與異常裝置都記錄稽核。Magic Link 安全性受信箱與瀏覽器信道影響，不能宣稱抗釣魚或滿足所有 NIST 高保證要求。
分步驟深入解答
1. 產生與儲存
使用密碼學安全隨機數，權杖放在 URL 的一次性參數中；資料庫保存雜湊而非明文。記錄用途、使用者、建立時間、過期時間、已消費時間與請求情境。驗證時做恒時比較並限制嘗試次數。
2. 請求與驗證
請求介面對所有信箱回傳相同提示、回應時間與狀態，避免枚舉。按 IP、信箱、裝置與全域維度限速，並對郵件寄送設配額。驗證成功必須在交易或原子條件更新中把權杖標記為已消費，防止並發連點重放。
3. 工作階段與風險控制
消費權杖後旋轉工作階段識別、設定安全 Cookie，並通知使用者登入裝置與位置。郵件預取或安全掃描器可能先訪問連結，可使用中間確認頁與明確使用者動作。敏感操作要求重新驗證、MFA 或 WebAuthn；不要把登入連結直接升級為長期高權限憑證。
高品質示範回答
我會把 Magic Link 定義為低風險、便利的登入因素，而非通用的抗釣魚驗證。使用者請求後，服務端用 CSPRNG 產生高熵隨機值，只保存雜湊、用途、過期時間與消費狀態，並對所有信箱回傳相同結果。驗證端透過 HTTPS 查找雜湊，在原子條件更新中標記單次消費，再旋轉工作階段 ID、寫入安全 Cookie 與稽核事件。連結短時有效、可撤銷，郵件 URL 不進入日誌或分析系統。針對郵件預取，我會先展示確認頁並要求使用者點擊繼續；針對轉寄與多裝置，明確是否允許一次消費與如何通知。支付、權限提升等操作改用 MFA 或 WebAuthn。測試涵蓋重放、並發點擊、枚舉、限速、郵件洩漏、裝置異常與撤銷。
常見錯誤
- 在資料庫或日誌保存明文權杖。
- 驗證成功後不原子消費，造成並發重放。
- 對不存在信箱回傳不同錯誤，允許帳戶枚舉。
- 把 Magic Link 說成天然抗釣魚或等同硬體金鑰。
- 權杖過期後仍能換長期工作階段，或缺少登入通知與撤銷。
追問及應對
郵件客戶端預取連結怎麼辦？
不要在 GET 存取時直接完成登入；先進入確認頁，用明確使用者動作消費權杖，並記錄預取與真實點擊的差異。
權杖應保存多久？
依風險與郵件延遲預算選擇短窗口，持續監控重放與未使用比例；過期後只能重新申請，不能延長舊權杖。
為什麼不能用於管理員或支付確認？
信箱信道可能被轉寄、劫持或釣魚，且 NIST 將某些郵件確認用途與高保證驗證區分。高風險操作應疊加抗釣魚驗證、交易綁定與獨立通知。