前言
在信息系統逐漸走向數字化、云端化的今天，賬號密碼登錄已不再是足夠安全的手段。數據泄露、撞庫攻擊、社工手段頻發，僅靠「你知道的密碼」已不足以保證賬戶安全。
因此，雙因子認證（2FA, Two-Factor Authentication） 成為企業安全防線中不可或缺的一環。本文將從0出發，為你講解雙因子登錄接口的設計理念、完整流程、技術細節與實踐建議。?
?
一、什么是雙因子認證？
雙因子認證，顧名思義，是使用兩個不同維度的驗證因子來驗證用戶身份，常見的驗證因子類型如下：
| 因子類型 | 描述 | 舉例 |
|---|---|---|
| 第一因子 | 用戶知道的 | 密碼、圖案、PIN |
| 第二因子 | 用戶擁有的或特征 | 手機驗證碼、動態口令、生物特征 |
與傳統登錄只需用戶名密碼不同，2FA 要求用戶 先通過密碼驗證，再使用如短信驗證碼或 App 動態口令來完成最終登錄。
在 2FA 機制中，必須選擇兩類不同類型的因子。例如“密碼 + 驗證碼”，“密碼 + 指紋”，“賬號 + 動態令牌”。
舉個最簡單的例子：
用戶輸入賬號密碼登錄，后端判斷賬號密碼正確，生成一個loginToken，并將其做個映射，響應給前端。前端在第二個因子驗證時，需要帶上這個loginToken，后端要先驗證loginToken是否正確，再驗證第二個因子，比如短信等。
二、為什么不能直接把驗證碼一起提交？
很多人最初的做法是這樣的：
{
"username": "zhangsan",
"password": "123456",
"code": "851022" ? // 短信驗證碼
}
但這樣做會把兩個因子一次性發送到服務器，安全性大打折扣。如果網絡層被監聽（如在不安全的 WiFi 環境），攻擊者只需截獲一次請求即可拿到全部認證信息。
🧠 正確做法：將登錄流程拆分成兩步，分別完成。
三、雙因子登錄接口設計方案
第一步：賬號密碼驗證
接口： /api/login/basic
請求參數：
{
"username": "zhangsan",
"password": "123456"
}
響應數據：
{
"code": 200,
"message": "密碼驗證通過，請進行二次驗證",
"loginToken": "abc123-login-temp-token",
"factor": "sms"
}
后端處理邏輯：
驗證用戶名與密碼
如果正確：
生成一個臨時
loginToken（UUID，隨機字符串）保存
loginToken -> userId到 Redis，設置短期過期（如5分鐘）向用戶手機號發送短信驗證碼
返回 loginToken 給前端，用于第二步驗證
第二步：驗證短信驗證碼
接口：?/api/login/verify-second-factor
請求參數：
{
"loginToken": "abc123-login-temp-token",
"code": "851022"
}
響應數據：
{
"code": 200,
"message": "登錄成功",
"accessToken": "jwt-token-xxx",
"refreshToken": "refresh-token-yyy",
"userInfo": {
"id": 1001,
"username": "zhangsan"
}
}
后端處理邏輯：
檢查 loginToken 是否存在并未過期
根據 loginToken 取出 userId
校驗該用戶的短信驗證碼是否正確
驗證成功：
生成 accessToken（JWT 或 Session）
刪除 loginToken 與驗證碼緩存
返回 accessToken 給前端
結語
雙因子認證已成為保護用戶賬戶安全的主流方案。通過合理的流程拆分、Redis 狀態管理、接口限流控制和錯誤次數保護機制，我們可以有效構建一個 安全、可靠、可擴展的 2FA 登錄系統。
未來還可以繼續拓展如：Google Authenticator（TOTP）、指紋、人臉識別（生物因子）、企業級 USBKey 登錄（數字證書）等。
