現在幾乎大部分的App都支援使用多個第三方賬號進行登入，如：微信、QQ、微博等，我們把此稱為多賬號統一登陸。而這些賬號的表設計，流程設計至關重要，不然後續擴充套件性賊差。本文不提供任何程式碼實操，但是梳理一下博主根據我司賬號模組的設計，提供思路，僅供參考。

一、 自建的登陸體系

1.1 手機號登陸註冊

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

流程：

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

問題：

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

1.2 優化註冊登陸

該方案的思路是弱化密碼的必填性，即無論使用者是否註冊過，可通過手機號 + 驗證碼 直接進行登陸(保留手機號 + 密碼登入的方式)。

流程：

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

使用者表設計：

1.3 引入第三方賬戶方案

1.3.1 微博登入

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

流程：

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

微博使用者資訊表設計：

1.3.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, 如今只要在 user_auths 表中增加一個統一的 verified 欄位, 每種登入方式都可以直觀看到是否已驗證情況;
3. 在 user_auths 新增相應的時間和 IP 地址, 就可以更加完整地跟蹤使用者的使用習慣, 比如:已經不使用微博登入兩年多, 已經繫結微信 300天;
4. 如果你說郵箱和手機號就是使用者資訊的組成部分, users 表儘管拓展, users 表裡依然有email , phone , 但他們僅僅作為“展示用途”,和暱稱,頭像或者性別這些屬性沒有本質區別;
5. 可按需繫結任意數量的同類型登入方式, 即一個使用者可以繫結多個微信, 可以有多個郵箱, 可以有多個手機號。當然你也可以限制一種登入方式只有一條記錄;

缺點 :

1. 使用者同時存在郵箱、使用者名稱、手機號等多種站內登入方式時, 改密碼時必須一起改, 否則就變成了郵箱 + 新密碼, 手機號 + 舊密碼都可以登入, 肯定是很詭異的情況;
2. 程式碼量增加了, 有些情況下邏輯判斷增加了, 難度增大了; 舉個例子, 無論使用者是否已登入, 無論使用者是否已註冊過, 都是點選同一連結前往微博第三方授權後返回, 可能出現幾種情況:
   1. 該微博在本站未註冊過, 很好, 直接給他註冊關聯並登入；
   2. 該微博已經在本站存在, 當前使用者未登入, 直接登入成功；
   3. 該微博未在本站註冊, 但當前使用者已經登入並關聯的是另一個微博帳號, 作何處理取決於是否允許繫結多個微博帳號；
   4. 該微博未在本站註冊過, 當前使用者已登入, 嘗試進行繫結操作；
   5. 該微博已經註冊, 使用者又已使用該帳號登入, 為何他重複繫結自己;
   6. 該微博已經在本站存在, 但當前使用者已經登入並關聯的是另一個微博帳號, 作何處理?

三、 一鍵登陸

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 呼叫運營商一鍵登入的介面，呼叫成功就返回手機號碼了。伺服器用手機號進行登入或註冊操作，返回操作結果給客戶端，完成一鍵登入。

目前阿里雲已經提供了該方式並可相容三大運營商的號碼，詳見阿里雲SDK

四、小結

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