現(xiàn)在幾乎大部分的App
都支持使用多個第三方賬號進行登錄，如：微信、QQ、微博等，我們把此稱為多賬號統(tǒng)一登陸。而這些賬號的表設(shè)計，流程設(shè)計至關(guān)重要，不然后續(xù)擴展性賊差。本文不提供任何代碼實操，但是梳理一下博主根據(jù)我司賬號模塊的設(shè)計，提供思路，僅供參考。

一、 自建的登陸體系

1.1 手機號登陸注冊

該設(shè)計的思路是每個手機號對應(yīng)一個用戶，手機號為必填項。

流程：

* 首先輸入手機號，然后發(fā)送到服務(wù)端。先判斷該手機號是否存在賬號，如果沒有，就會生成隨機驗證碼，將手機號和驗證碼綁定到Redis
中，并設(shè)置一定的過期時間（過期時間一般是5分鐘，這就是我們一般手機驗證碼的有效期），最后將驗證碼通過短信發(fā)送給用戶。
* 用戶接收到驗證碼后，在界面填寫驗證碼以及密碼等基礎(chǔ)信息，然后將這些數(shù)據(jù)發(fā)送服務(wù)端。服務(wù)端收到后，先判斷在Redis
里面這個手機號對應(yīng)的驗證碼是否一致，，失敗就返回錯誤碼，成功就給用戶創(chuàng)建一個賬號和保存密碼。
* 注冊成功后，用戶即可通過自己的手機號+密碼進行登陸。
問題：

* 用戶體驗差，需要完成獲取驗證碼，填寫驗證碼/密碼/用戶名等諸多的信息完成注冊，然后才能使用；
* 容易遺忘密碼，遺忘后，只能通過忘記密碼來重新設(shè)置密碼。
1.2 優(yōu)化注冊登陸

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

流程：

* 輸入手機號，然后發(fā)送到服務(wù)端。服務(wù)端生成隨機驗證碼，將手機號和驗證碼綁定到Redis
中，并設(shè)置一定的過期時間（過期時間一般是5分鐘，這就是我們一般手機驗證碼的有效期），最后將驗證碼通過短信發(fā)送給用戶。
* 用戶接收到驗證碼后，在界面只需填寫收到的驗證碼，提交到服務(wù)端。服務(wù)端收到后，先判斷在Redis
里面這個手機號對應(yīng)的驗證碼是否一致，失敗就返回錯誤碼，成功就直接登錄。如果是老用戶，直接拉取用戶信息；如果是新用戶，則提示他可以完善用戶信息（不強制）。
* 用戶通過手機號 + 驗證碼登錄后，也可選擇設(shè)置密碼，然后就可以通過手機號 + 密碼的方式登錄，即：密碼是非必填項。
用戶表設(shè)計：

id user_name user_password user_mobile state more
用戶id 用戶名 用戶密碼 手機號碼 賬號狀態(tài) 其他信息
1.3 引入第三方賬戶方案

1.3.1 微博登錄

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

流程：

* 客戶端調(diào)用微博登錄的界面，進行輸入用戶名、密碼，登錄成功后，會返回access_token,通過access_token調(diào)取API接口獲取用戶信息。
* 服務(wù)端通過用戶信息在我們用戶表創(chuàng)建一個賬號，以后，該第三方賬號即可通過該微博賬號直接進行登陸。
微博用戶信息表設(shè)計：

id user_id uid access_token
主鍵id 用戶id 微博唯一id 授權(quán)碼
1.3.2 噩夢來臨

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

二、 優(yōu)化賬號體系

2.1 原賬號體系分析

* 自建登陸體系：無論 手機號 + 密碼 , 還是 手機號 + 驗證碼 , 都是一種 用戶信息+密碼 的驗證形式；
* 第三方登錄：也是用戶信息+密碼 的形式, 用戶信息即第三方系統(tǒng)中的 ID(第三方系統(tǒng)中的唯一標(biāo)識), 密碼即 access_token,
只不過是一種有使用時效定期修改的密碼。
2.2 新的賬號體系

2.2.1 數(shù)據(jù)表設(shè)計

用戶基礎(chǔ)信息表：

id nickname avatar more
用戶id 昵稱 頭像 其他信息
用戶授權(quán)信息表：

id user_id identity_type identifier credential
主鍵id 用戶id 登錄類型(手機號/郵箱) 或第三方應(yīng)用名稱 (微信/微博等) 手機號/郵箱/第三方的唯一標(biāo)識 密碼憑證 (自建賬號的保存密碼,
第三方的保存 token)
說明：

* 用戶表分為 用戶基礎(chǔ)信息表 + 用戶授權(quán)信息表；
* 用戶信息表不保存任何密碼, 不保存任何登錄信息(如用戶名, 手機號, 郵箱), 只留有昵稱、頭像等基礎(chǔ)信息; 所有和授權(quán)相關(guān),都放在用戶信息授權(quán)表,
用戶信息表和用戶授權(quán)表是一對多的關(guān)系。
2.2.2 登錄流程

* 手機號 + 驗證碼
沿用之前的方案。

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

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

* 第三方登錄, 如微信登錄：
查詢type= 'weixin' 結(jié)合 identifier= '微信 openId', 如果有記錄, 則直接登錄成功, 并更新token;
假設(shè)與微信服務(wù)器通信不被劫持的情況下無需判斷憑證問題。

2.2.3 優(yōu)缺點

優(yōu)點:

* 登錄類型無限擴展, 新增登錄類型的開發(fā)成本顯著降低;
* 原來條件下, 應(yīng)用需要驗證手機號是否已驗證和郵箱是否已驗證, 需要相對應(yīng)多一個字段如 phone_verified 和 email_verified,
如今只要在用戶授權(quán)信息表中增加一個統(tǒng)一的verified 字段, 每種登錄方式都可以直觀看到是否已驗證情況;
* 在用戶授權(quán)信息表中添加相應(yīng)的時間和 IP 地址, 就可以更加完整地跟蹤用戶的使用習(xí)慣, 比如:已經(jīng)不使用微博登錄兩年多, 已經(jīng)綁定微信 300天;
* 如果你說郵箱和手機號就是用戶信息的組成部分, 用戶基礎(chǔ)信息表盡管拓展, 用戶基礎(chǔ)信息表里依然有email , phone ,
但他們僅僅作為“展示用途”,和昵稱,頭像或者性別這些屬性沒有本質(zhì)區(qū)別;
* 可按需綁定任意數(shù)量的同類型登錄方式, 即一個用戶可以綁定多個微信, 可以有多個郵箱, 可以有多個手機號。當(dāng)然你也可以限制一種登錄方式只有一條記錄;
缺點 :

* 用戶同時存在郵箱、用戶名、手機號等多種站內(nèi)登錄方式時, 改密碼時必須一起改, 否則就變成了郵箱 + 新密碼, 手機號 + 舊密碼都可以登錄,
肯定是很詭異的情況;
* 代碼量增加了, 有些情況下邏輯判斷增加了, 難度增大了; 舉個例子, 無論用戶是否已登錄, 無論用戶是否已注冊過,
都是點擊同一鏈接前往微博第三方授權(quán)后返回, 可能出現(xiàn)幾種情況:
* 該微博在本站未注冊過, 很好, 直接給他注冊關(guān)聯(lián)并登錄；
* 該微博已經(jīng)在本站存在, 當(dāng)前用戶未登錄, 直接登錄成功；
* 該微博未在本站注冊, 但當(dāng)前用戶已經(jīng)登錄并關(guān)聯(lián)的是另一個微博帳號, 作何處理取決于是否允許綁定多個微博帳號；
* 該微博未在本站注冊過, 當(dāng)前用戶已登錄, 嘗試進行綁定操作；
* 該微博已經(jīng)注冊, 用戶又已使用該帳號登錄, 為何他重復(fù)綁定自己;
* 該微博已經(jīng)在本站存在, 但當(dāng)前用戶已經(jīng)登錄并關(guān)聯(lián)的是另一個微博帳號, 作何處理?
三、 一鍵登陸

3.1 背景

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

* 輸入手機號、等待驗證碼短信、輸入驗證碼、點擊登錄。整個流程走完可能需要 20 秒以上，操作也比較繁瑣；
* 它是依賴短信網(wǎng)絡(luò)的，因為如果收不到短信，也就登錄不了了。
* 從安全角度考慮，還存在驗證碼泄漏的風(fēng)險。如果有人知道了你的手機號，并且竊取到了驗證碼，那他也能登錄你的賬號了。
但回過頭來想一下，為什么我們需要驗證碼？驗證碼的作用就是確定這個手機號是你的，那除了使用短信，是否還有別的方式對手機號進行認(rèn)證？

* 如果能獲取到當(dāng)前使用的手機號，就能對用戶輸入的號碼進行驗證了。但出于安全考慮，客戶端是無法直接獲取到手機號的，運營商則可以通過 SIM 卡數(shù)據(jù)查詢到。
*
現(xiàn)在運營商已經(jīng)開放了相關(guān)的能力，現(xiàn)在我們可以在用戶輸入手機號后，通過調(diào)用運營商的接口，判斷用戶輸入的手機號是否和本地號碼一致。這樣一來，用戶就省去了等待驗證碼短信、輸入驗證碼的過程，也不受短信網(wǎng)絡(luò)的限制，簡化了登錄流程。
* 但再進一步想，如果運營商可以把當(dāng)前的號碼直接返回給我們，而不只是用于驗證，那用戶連手機號都不需要填了。
這就是該部分的主角：一鍵登錄。

3.2 本機號碼認(rèn)證

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

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

主要步驟如下：

* SDK 初始化：調(diào)用 SDK 的初始化方法，傳入項目在平臺上的 AppKey 和 AppSecret。
* 喚起授權(quán)頁：調(diào)用 SDK 喚起授權(quán)接口。SDK
會先向運營商發(fā)起獲取手機號掩碼的請求，請求成功后跳轉(zhuǎn)到授權(quán)頁。授權(quán)頁會顯示手機號掩碼以及運營商協(xié)議給用戶確認(rèn)。
* 同意授權(quán)并登錄：用戶同意相關(guān)協(xié)議，點擊授權(quán)頁面的登錄按鈕，SDK 會請求本次取號的 token，請求成功后將 token 返回給客戶端。
* 取號：將獲取到的 token 發(fā)送到我們自己的服務(wù)器，由服務(wù)器攜帶 token
調(diào)用運營商一鍵登錄的接口，調(diào)用成功就返回手機號碼了。服務(wù)器用手機號進行登錄或注冊操作，返回操作結(jié)果給客戶端，完成一鍵登錄。
目前阿里云已經(jīng)提供了該方式并可兼容三大運營商的號碼，詳見阿里云SDK
<https://help.aliyun.com/document_detail/121113.html?spm=a2c4g.11186623.6.554.386517eau11jSe>

四、小結(jié)

博主看來，沒有最好的方案，選擇適用當(dāng)前系統(tǒng)的設(shè)計即可。不要深究孰優(yōu)孰劣，鞋合不合腳，只有腳知道。

• ? 上一篇：ASP.NET Core MVC 之視圖組件（View Component）
• ? 下一篇：Linux ln 命令