淺談帳號系統設計

如今幾乎大部分的App都支持使用多個第三方帳號進行登陸，如：微信、QQ、微博等，咱們把此稱爲多帳號統一登錄。而這些帳號的表設計，流程設計相當重要，否則後續擴展性賊差。本文不提供任何代碼實操，可是梳理一下博主根據我司帳號模塊的設計，提供思路，僅供參考。

1、 自建的登錄體系

1.1 手機號登錄註冊

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

流程：

1. 首先輸入手機號，而後發送到服務端。先判斷該手機號是否存在帳號，若是沒有，就會生成隨機驗證碼，將手機號和驗證碼綁定到Redis中，並設置必定的過時時間（過時時間通常是5分鐘，這就是咱們通常手機驗證碼的有效期），最後將驗證碼經過短信發送給用戶。
2. 用戶接收到驗證碼後，在界面填寫驗證碼以及密碼等基礎信息，而後將這些數據發送服務端。服務端收到後，先判斷在Redis裏面這個手機號對應的驗證碼是否一致，，失敗就返回錯誤碼，成功就給用戶建立一個帳號和保存密碼。
3. 註冊成功後，用戶便可經過本身的手機號+密碼進行登錄。

問題：

1. 用戶體驗差，須要完成獲取驗證碼，填寫驗證碼/密碼/用戶名等諸多的信息完成註冊，而後才能使用；
2. 容易遺忘密碼，遺忘後，只能經過忘記密碼來從新設置密碼。

1.2 優化註冊登錄

該方案的思路是弱化密碼的必填性，即不管用戶是否註冊過，可經過手機號 + 驗證碼 直接進行登錄(保留手機號 + 密碼登陸的方式)。

流程：

1. 輸入手機號，而後發送到服務端。服務端生成隨機驗證碼，將手機號和驗證碼綁定到Redis中，並設置必定的過時時間（過時時間通常是5分鐘，這就是咱們通常手機驗證碼的有效期），最後將驗證碼經過短信發送給用戶。
2. 用戶接收到驗證碼後，在界面只需填寫收到的驗證碼，提交到服務端。服務端收到後，先判斷在Redis裏面這個手機號對應的驗證碼是否一致，失敗就返回錯誤碼，成功就直接登陸。若是是老用戶，直接拉取用戶信息；若是是新用戶，則提示他能夠完善用戶信息（不強制）。
3. 用戶經過手機號 + 驗證碼登陸後，也可選擇設置密碼，而後就能夠經過手機號 + 密碼的方式登陸，即：密碼是非必填項。

用戶表設計：

id	user_name	user_password	user_mobile	state	more
用戶id	用戶名	用戶密碼	手機號碼	帳號狀態	其餘信息

1.3 引入第三方帳戶方案

1.3.1 微博登陸

進入 Web2.0 時代 ,微博開放了第三方網站登陸, 產品說, 這個咱們得要, 加個用微博賬號就能登陸咱們的App吧，並且得和咱們本身的用戶表關聯。

流程：

1. 客戶端調用微博登陸的界面，進行輸入用戶名、密碼，登陸成功後，會返回access_token,經過access_token調取API接口獲取用戶信息。
2. 服務端經過用戶信息在咱們用戶表建立一個帳號，之後，該第三方帳號便可經過該微博帳號直接進行登錄。

微博用戶信息表設計：

id	user_id	uid	access_token
主鍵id	用戶id	微博惟一id	受權碼

1.3.2 噩夢來臨

緊接着, QQ又開放用戶登陸了, 微信開放用戶登陸了，網易開發用戶登陸了。。。。。。一會兒要接入好多家第三方登陸了, 只能按照 「微博用戶信息表」 新建一個表，重寫一套各個第三方登陸。

2、 優化帳號體系

2.1 原帳號體系分析

1. 自建登錄體系：不管 手機號 + 密碼 , 仍是 手機號 + 驗證碼 , 都是一種 用戶信息+密碼 的驗證形式；
2. 第三方登陸：也是用戶信息+密碼 的形式, 用戶信息即第三方系統中的 ID(第三方系統中的惟一標識), 密碼即 access_token, 只不過是一種有使用時效按期修改的密碼。

2.2 新的帳號體系

2.2.1 數據表設計

用戶基礎信息表：

id	nickname	avatar	more
用戶id	暱稱	頭像	其餘信息

用戶受權信息表：

id	user_id	identity_type	identifier	credential
主鍵id	用戶id	登陸類型(手機號/郵箱) 或第三方應用名稱 (微信/微博等)	手機號/郵箱/第三方的惟一標識	密碼憑證 (自建帳號的保存密碼, 第三方的保存 token)

說明：

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. 若是你說郵箱和手機號就是用戶信息的組成部分, 用戶基礎信息表儘管拓展, 用戶基礎信息表裏依然有email , phone , 但他們僅僅做爲「展現用途」,和暱稱,頭像或者性別這些屬性沒有本質區別;
5. 可按需綁定任意數量的同類型登陸方式, 即一個用戶能夠綁定多個微信, 能夠有多個郵箱, 能夠有多個手機號。固然你也能夠限制一種登陸方式只有一條記錄;

缺點 :

1. 用戶同時存在郵箱、用戶名、手機號等多種站內登陸方式時, 改密碼時必須一塊兒改, 不然就變成了郵箱 + 新密碼, 手機號 + 舊密碼均可以登陸, 確定是很詭異的狀況;
2. 代碼量增長了, 有些狀況下邏輯判斷增長了, 難度增大了; 舉個例子, 不管用戶是否已登陸, 不管用戶是否已註冊過, 都是點擊同一連接前往微博第三方受權後返回, 可能出現幾種狀況:
   1. 該微博在本站未註冊過, 很好, 直接給他註冊關聯並登陸；
   2. 該微博已經在本站存在, 當前用戶未登陸, 直接登陸成功；
   3. 該微博未在本站註冊, 但當前用戶已經登陸並關聯的是另外一個微博賬號, 做何處理取決因而否容許綁定多個微博賬號；
   4. 該微博未在本站註冊過, 當前用戶已登陸, 嘗試進行綁定操做；
   5. 該微博已經註冊, 用戶又已使用該賬號登陸, 爲什麼他重複綁定本身;
   6. 該微博已經在本站存在, 但當前用戶已經登陸並關聯的是另外一個微博賬號, 做何處理?

3、 一鍵登錄

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

4、小結

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