多賬號統一登陸，怎么實作？

來源：www.dustyblog.cn

現在幾乎大部分的 App 都支持使用多個第三方賬號進行登錄，如：微信、QQ、微博等，我們把此稱為多賬號統一登陸，而這些賬號的表設計，流程設計至關重要，不然后續擴展性賊差，

本文不提供任何代碼實操，但是梳理一下博主根據我司賬號模塊的設計，提供思路，僅供參考，

一、 自建的登陸體系

1.1.1 手機號登陸注冊

該設計的思路是每個手機號對應一個用戶，手機號為必填項，

流程：

1. 首先輸入手機號，然后發送到服務端，先判斷該手機號是否存在賬號，如果沒有，就會生成隨機驗證碼，將手機號和驗證碼系結到 Redis中，并設定一定的過期時間（過期時間一般是5分鐘，這就是我們一般手機驗證碼的有效期），最后將驗證碼通過短信發送給用戶，
2. 用戶接收到驗證碼后，在界面填寫驗證碼以及密碼等基礎資訊，然后將這些資料發送服務端，服務端收到后，先判斷在 Redis里面這個手機號對應的驗證碼是否一致，，失敗就回傳錯誤碼，成功就給用戶創建一個賬號和保存密碼，
3. 注冊成功后，用戶即可通過自己的 手機號+密碼進行登陸，

問題：

1. 用戶體驗差，需要完成獲取驗證碼，填寫驗證碼/密碼/用戶名等諸多的資訊完成注冊，然后才能使用；
2. 容易遺忘密碼，遺忘后，只能通過忘記密碼來重新設定密碼，

1.1.2 優化注冊登陸

該方案的思路是榷訓密碼的必填性，即無論用戶是否注冊過，可通過 手機號+驗證碼 直接進行登陸(保留 手機號+密碼登錄的方式)，

流程：

1. 輸入手機號，然后發送到服務端，服務端生成隨機驗證碼，將手機號和驗證碼系結到 Redis中，并設定一定的過期時間（過期時間一般是5分鐘，這就是我們一般手機驗證碼的有效期），最后將驗證碼通過短信發送給用戶，
2. 用戶接收到驗證碼后，在界面只需填寫收到的驗證碼，提交到服務端，服務端收到后，先判斷在 Redis里面這個手機號對應的驗證碼是否一致，失敗就回傳錯誤碼，成功就直接登錄，如果是老用戶，直接拉取用戶資訊；如果是新用戶，則提示他可以完善用戶資訊（不強制），
3. 用戶通過 手機號+驗證碼登錄后，也可選擇設定密碼，然后就可以通過 手機號+密碼的方式登錄，即：密碼是非必填項，

用戶表設計：

1.2 引入第三方賬戶方案

1.2.1 微博登錄

進入 Web2.0 時代 ,微博開放了第三方網站登錄, 產品說, 這個我們得要, 加個用微博帳號就能登錄我們的 App吧，而且得和我們自己的用戶表關聯，

流程：

1. 客戶端呼叫微博登錄的界面，進行輸入用戶名、密碼，登錄成功后，會回傳 access_token,通過 access_token調取 API介面獲取用戶資訊，
2. 服務端通過用戶資訊在我們用戶表創建一個賬號，以后，該第三方賬號即可通過該微博賬號直接進行登陸，

微博用戶資訊表設計：

1.2.2 噩夢來臨

緊接著, QQ又開放用戶登錄了, 微信開放用戶登錄了，網易開發用戶登錄了，，，，，，一下子要接入好多家第三方登錄了, 只能按照 “微博用戶資訊表” 新建一個表，重寫一套各個第三方登錄，

二、 優化賬號體系

2.1 原賬號體系分析

1. 自建登陸體系：無論 手機號+密碼 , 還是 手機號+驗證碼 , 都是一種 用戶資訊+密碼 的驗證形式；
2. 第三方登錄：也是 用戶資訊+密碼 的形式, 用戶資訊即第三方系統中的 ID(第三方系統中的唯一標識), 密碼即 access_token, 只不過是一種有使用時效定期修改的密碼，

2.2 新的賬號體系

2.2.1 資料表設計

用戶基礎資訊表：

用戶授權資訊表：

說明：

1. 用戶表分為 用戶基礎資訊表 + 用戶授權資訊表；
2. 用戶資訊表不保存任何密碼, 不保存任何登錄資訊(如用戶名, 手機號, 郵箱), 只留有昵稱、頭像等基礎資訊; 所有和授權相關,都放在用戶資訊授權表, 用戶資訊表和用戶授權表是一對多的關系 ，

2.2.2 登錄流程

• 手機號+驗證碼

沿用之前的方案，

• 郵箱/手機號+密碼:

用戶填寫 郵箱/手機號+密碼; 請求登錄的時候, 先判斷型別, 如手機號登錄為例：

使用 type='phone' 結合 identifier='手機號' 查找, 如有, 取出并判斷 password_hash(密碼)是否和該條目的 credential 相符, 相符則通過驗證, 隨后通過 user_id 獲取用戶資訊;

• 第三方登錄, 如微信登錄：

查詢 type='weixin' 結合 identifier='微信 openId', 如果有記錄, 則直接登錄成功, 并更新 token; 假設與微信服務器通信不被劫持的情況下無需判斷憑證問題，

2.2.3 優缺點

優點:

1. 登錄型別無限擴展, 新增登錄型別的開發成本顯著降低;
2. 原來條件下, 應用需要驗證手機號是否已驗證和郵箱是否已驗證, 需要相對應多一個欄位如 phone_verified 和 email_verified, 如今只要在 用戶授權資訊表 表中增加一個統一的 verified欄位, 每種登錄方式都可以直觀看到是否已驗證情況;
3. 在 用戶授權資訊表 添加相應的時間和 IP 地址, 就可以更加完整地跟蹤用戶的使用習慣, 比如:已經不使用微博登錄兩年多, 已經系結微信 300天;
4. 如果你說郵箱和手機號就是用戶資訊的組成部分, users 表盡管拓展, users 表里依然有email , phone , 但他們僅僅作為“展示用途”,和昵稱,頭像或者性別這些屬性沒有本質區別;
5. 可按需系結任意數量的同型別登錄方式, 即一個用戶可以系結多個微信, 可以有多個郵箱, 可以有多個手機號，當然你也可以限制一種登錄方式只有一條記錄;

缺點 :

1. 用戶同時存在郵箱、用戶名、手機號等多種站內登錄方式時, 改密碼時必須一起改, 否則就變成了 郵箱+新密碼, 手機號+舊密碼都可以登錄, 肯定是很詭異的情況;

2. 代碼量增加了, 有些情況下邏輯判斷增加了, 難度增大了; 舉個例子, 無論用戶是否已登錄, 無論用戶是否已注冊過, 都是點擊同一鏈接前往微博第三方授權后回傳, 可能出現幾種情況：

該微博在本站未注冊過, 很好, 直接給他注冊關聯并登錄；

該微博已經在本站存在, 當前用戶未登錄, 直接登錄成功；

該微博未在本站注冊, 但當前用戶已經登錄并關聯的是另一個微博帳號, 作何處理取決于是否允許系結多個微博帳號；

該微博未在本站注冊過, 當前用戶已登錄, 嘗試進行系結操作；

該微博已經注冊, 用戶又已使用該帳號登錄, 為何他重復系結自己;

該微博已經在本站存在, 但當前用戶已經登錄并關聯的是另一個微博帳號, 作何處理?

三、 一鍵登陸

3.1 背景

回顧一下 手機號+驗證碼 的登錄方式：

1. 輸入手機號、等待驗證碼短信、輸入驗證碼、點擊登錄，整個流程走完可能需要 20 秒以上，操作也比較繁瑣；
2. 它是依賴短信網路的，因為如果收不到短信，也就登錄不了了，
3. 從安全角度考慮，還存在驗證碼泄漏的風險，如果有人知道了你的手機號，并且竊取到了驗證碼，那他也能登錄你的賬號了，

但回過頭來想一下，為什么我們需要驗證碼？驗證碼的作用就是確定這個手機號是你的，那除了使用短信，是否還有別的方式對手機號進行認證？

1. 如果能獲取到當前使用的手機號，就能對用戶輸入的號碼進行驗證了，但出于安全考慮，客戶端是無法直接獲取到手機號的，運營商則可以通過 SIM 卡資料查詢到，
2. 現在運營商已經開放了相關的能力，現在我們可以在用戶輸入手機號后，通過呼叫運營商的介面，判斷用戶輸入的手機號是否和本地號碼一致，這樣一來，用戶就省去了等待驗證碼短信、輸入驗證碼的程序，也不受短信網路的限制，簡化了登錄流程，
3. 但再進一步想，如果運營商可以把當前的號碼直接回傳給我們，而不只是用于驗證，那用戶連手機號都不需要填了，

這就是該部分的主角：一鍵登錄 ，

3.2 本機號碼認證

獲取到當前手機使用的手機卡號，直接使用這個號碼進行登錄，這就是一鍵登錄，

這種登錄方式的好處是顯而易見的，它可以更方便、快捷地完成注冊、登錄流程，將原本可能需要 20 秒的流程，縮短到了 2 秒左右，很大程度上提升了登錄的用戶體驗，

主要步驟如下：

1. SDK 初始化：呼叫 SDK 的初始化方法，傳入專案在平臺上的 AppKey 和 AppSecret，
2. 喚起授權頁：呼叫 SDK 喚起授權介面，SDK 會先向運營商發起獲取手機號驗碼的請求，請求成功后跳轉到授權頁，授權頁會顯示手機號掩碼以及運營商協議給用戶確認，
3. 同意授權并登錄：用戶同意相關協議，點擊授權頁面的登錄按鈕，SDK 會請求本次取號的 token，請求成功后將 token 回傳給客戶端，
4. 取號：將獲取到的 token 發送到我們自己的服務器，由服務器攜帶 token 呼叫運營商一鍵登錄的介面，呼叫成功就回傳手機號碼了，服務器用手機號進行登錄或注冊操作，回傳操作結果給客戶端，完成一鍵登錄，

四、小結

博主看來，沒有最好的方案，選擇適用當前系統的設計即可，不要深究孰優孰劣，鞋合不合腳，只有腳知道，

近期熱文推薦：

1.1,000+ 道 Java面試題及答案整理(2021最新版)

2.別在再滿屏的 if/ else 了，試試策略模式，真香！！

3.臥槽！Java 中的 xx ≠ null 是什么新語法？

4.Spring Boot 2.5 重磅發布，黑暗模式太炸了！

5.《Java開發手冊（嵩山版）》最新發布，速速下載！

覺得不錯，別忘了隨手點贊+轉發哦！

標籤：Java

上一篇：mybatis_day01

下一篇：Cobar SQL審計的設計與實作