面試題:如何限制一個賬號只能在一處登錄?
有位同學在面試的過程中被問到了一個很有意思的問題:【如何限制一個賬號只能在一處登錄?】,既:單設備登錄。
PS:很多同學會把單設備登錄 和單點登錄搞混,但是他們之間本質(zhì)上是不一樣的。
- 單設備登錄:同一賬號 在同一時間只能在一個設備上登錄,如果用戶在另一臺設備上登錄,則之前的設備會被自動下線。
- 單點登錄(SSO):用戶在多個系統(tǒng)或應用之間只需要登錄一次,就可以訪問所有相關系統(tǒng),無需再次輸入憑據(jù)。
言歸正傳,咱們回到當前面試題本身,如何限制一個賬號只能在一處登錄?
技術(shù)方案
要實現(xiàn) 單設備登錄,我們需要設立一種機制,確保同一賬號在不同設備上不能同時保持活躍。
常見的實現(xiàn)方式僅從前端角度來說的話,主要有兩種:
1. 基于 Token 版本控制(推薦)
核心思想:Token 版本號(token_version)充當唯一憑證,每次新設備登錄時,版本號 +1,舊 Token 失效。
我們來拆解下這個流程:
首先第一步: 用戶首次登錄
- 用戶登錄后,數(shù)據(jù)庫中的 token_version 設為 1。
- 后端生成 JWT Token,并在 payload 中加入 { userId: 1, tokenVersion: 1 }。
- 返回 Token 給前端,前端存儲在 localStorage 或 Authorization 頭中。
然后第二步: 用戶在新設備登錄
- 新設備登錄后,后端查詢該用戶的 token_version,然后 +1,更新到數(shù)據(jù)庫(如 token_version=2)。
- 生成新的 Token { userId: 1, tokenVersion: 2 },返回給新設備。
第三步: 舊設備攜帶 Token 訪問接口
- 舊設備的 Token 仍然是 { userId: 1, tokenVersion: 1 },但數(shù)據(jù)庫中 token_version=2。
- 服務器驗證 Token,發(fā)現(xiàn) tokenVersion !== 數(shù)據(jù)庫的 token_version,返回 401,拒絕訪問。
第四步: 舊設備強制下線
舊設備前端收到 401 響應后:
- 清除本地 Token
- 跳轉(zhuǎn)到登錄頁
- 提示 "賬號已在其他設備登錄,請重新登錄"
以上方案是實現(xiàn) 單設備登錄 最簡單的方案,核心就是維護了 token_version 的版本值
2. 基于 WebSocket 的實時強制下線
核心思想:每次用戶在新設備登錄時,服務器通過 WebSocket 通知舊設備下線,舊設備收到消息后清除 Token 并強制登出。
咱們通常拆解下這個流程:
首先第一步: 用戶首次登錄
- 用戶登錄后,服務器建立 WebSocket 連接,并在 Redis 或者 數(shù)據(jù)庫中存儲對應狀態(tài),如: { userId: 1, socketId: "xyz123" } 以記錄該設備的 WebSocket 連接 ID。
然后第二步:用戶在新設備登錄
- 新設備登錄后,服務器檢測到該用戶已有活躍連接。
- 給舊設備發(fā)送 WebSocket 消息:"你的賬號已在其他設備登錄,請重新登錄"
- 刪除舊設備的 WebSocket 連接記錄
- 新設備建立 WebSocket 連接,存儲 { userId: 1, socketId: "abc456" }。
第三步:舊設備收到 WebSocket 消息
舊設備監(jiān)聽到 "被踢下線" 消息:
- 清除本地 Token
- 自動跳轉(zhuǎn)到登錄頁
- 提示 "賬號已在其他設備登錄"
與上一個相比,這里核心就是利用了 WebSocket 雙向通訊 的能力來實現(xiàn) 強制下線 的功能,好處是可以做到 即時響應。麻煩的地方是需要重新對接 ws 協(xié)議。
我們可以通過以下表格來對比下兩種方案的差異:
方案 | 優(yōu)勢 | 劣勢 |
基于 Token 版本控制 | 邏輯簡單,后端維護 Token 版本即可,兼容性好 | 需要前端主動處理 401,可能有短暫的延遲 |
基于 WebSocket 實時強制下線 | 即時性強,用戶體驗更好 | 需要 WebSocket 連接,維護連接狀態(tài),斷連時需要額外處理 |
當然,這兩種方案也可以結(jié)合起來進行使用:
以 WebSocket 優(yōu)先,當 WebSocket 連接異常時,后端回退到 Token 版本校驗。這樣既能 保證即時強制下線,也能 兼容不支持 WebSocket 的場景。