如何設計 QQ、微信等第三方帳號登錄？

多帳戶的統一登陸

名稱解釋

這裏的多帳戶區別於系統級別的，咱們講的多帳戶系統是指，在咱們互聯網應用當中，咱們的應用會使用多個第三方帳號進行登陸，好比如今經常使用的APP：網易、微信、QQ等等。

本文內容

多帳戶系統的技術方案細節，以及相應的表設計，流程設計。

架構演進

初期

歸結爲初期是由於這個時候用戶量比較少，甚至尚未接入上面所說的其餘第三方的帳戶系統，只是自建的體系就能夠知足，自建體系目前經常使用的有：

用戶名密碼註冊登錄

這種方式在不少初期網站建設會使用，先註冊，再進行登陸，在老一點的cms中都能找到這個影子。

• 流程圖：
  
• 流程說明：
  一、前端將用戶名、密碼發送到服務器，服務器進行常規的判斷，判斷用戶名、密碼長度是否知足，用戶名是否重複等條件，條件不經過直接返回對應錯誤碼給到前端，這裏密碼字段，爲了防止傳輸過程當中被截胡，建議加密再上傳，咱們的傳輸密碼默認都是會進行一個md5加密，而後記錄到數據庫再進行一層加密，就算是脫庫也沒事，密碼不要明文存儲。
  二、校驗經過後，就將用戶名密碼寫入數據庫，並進行後面積分發放等操做，這裏不展開。
  三、如今進行登陸，前端將用戶名，密碼發送給到服務端，服務端首先會校驗登陸次數是否超過設置的閾值，若是超過只能繼續等待被關小黑屋。
  四、若是未超過繼續登陸邏輯，判斷用戶名、密碼是否正確，不正確密碼則進行閾值的判斷，若是超過則關小黑屋，記住小黑屋必須設置過時時間，要否則就會永久關上了，這個能夠用redis的過時來作。
  五、登陸成功後進行後續的一切後置邏輯，好比加積分...等操做。

手機號註冊登錄

• 流程圖
  
• 流程說明：
  一、首先輸入手機號，而後發送到服務端，服務端將手機號記錄在咱們數據庫中，而後生成隨機驗證碼，並將手機號和驗證碼綁定到一個redis裏面，而後記錄過時時間，這個過時時間通常是10分鐘左右，這就是咱們通常手機驗證碼的有效期。
  二、手機接收到手機短信後，那麼就在界面填寫驗證碼發送服務端，服務端收到驗證碼後就會在redis裏面查詢到這個手機號對應的驗證碼，失敗就返回錯誤碼。
  成功後就進行登陸操做。
  三、這裏看起來沒有明確的註冊登陸操做，其實在發送手機號碼就能夠認爲是一個常規的註冊，而後後面的驗證碼輸入就是一個登錄操做。

問：若是要密碼怎麼辦？
答：在後續產品裏面增長一個「手機號碼密碼補錄的功能」便可，這也是如今很常規的手法，可是如今移動互聯網大爆炸時代，密碼已經顯得不是那麼重要了，若是手機號碼能操做的 app，能夠不用密碼來操做。

數據庫設計

表結構：

自增id	用戶名	密碼	手機號	錯誤次數
1	user1	7fef6171469e80d32c0559f88b377245	13456789012	0
2	user2	7fef6171469e80d32c0559f88b377245	13456789013	0

說明 ：
這裏只是單純說明須要用到的數據，沒有擴展具體場景,這個表結構可以知足上面兩個方案的設計。

引入第三方帳戶方案

這裏是以 QQ-SDK 的登陸邏輯， 咱們先看一下時序圖：

• 說明：
  一、客戶端本身調起登陸的界面，進行輸入用戶名、密碼，這裏的是第三方的用戶名，密碼，登陸成功後，會返回access_token openid expire_in,這過程會使用到oauth2.0，不過在sdk裏面進行內置回調獲取了，後面咱們會說明咱們自身實現的oauth2.0
  二、客戶端拿到access_token、openid、login_type（qq、wechat...）請求應用服務器，應用服務器拿到這些數據後就會根據對應的login_type去對應的用戶中心進行access_token和openid進行校驗。校驗不經過則返回對應錯誤碼
  三、校驗經過後就會判斷本地是否有這個login_type和openid是否存在，不存在則進行獲取遠程的用戶名、頭像等基礎信息來做爲本地基礎數據，而且返回code值
  四、若是已經存在，那就是進行登陸操做，返回code值。
  五、客戶端拿到code值後進行token值的換取，這個徹底遵守oauth2.0的協議來走的，後續每次請求必須帶上token，token值在服務端的時間比較久，由於咱們想要作的是那種永不下線的操做，因此每次請求咱們都將token過時時間進行累加。

數據庫設計

用戶基礎表（users）
字段	備註
user_id	用戶id
token	用戶登錄的token
expire_in	token過時時間
try_times	登陸失敗次數

用戶驗證關聯表（user_auth_rel）
字段	備註
id	自增id
user_id	用戶id
auth_id	驗證表id
auth_type	驗證類型(local、third)

本地用戶表（user_local_auth）
字段	備註
auth_id	認證id，自增id
user_name	用戶惟一標識
password	用戶密碼
mobile	用戶手機

第三方用戶表（user_third_auth）
字段	備註
auth_id	用戶id
openid	第三方用戶惟一標識
login_type	第三方平臺標識(qq、wechat...)
access_token	第三方獲取的access_token,校驗使用

• 說明
  一、users表只是單純針對咱們業務側的登陸，主要是作自身業務的oauth2.0業務，
  二、user_local_auth是作本身用戶名、密碼登陸，手機號碼登陸信息記錄，
  三、user_third_auth是咱們第三方用戶體系的數據記錄，
  四、user_auth_rel是用來關聯咱們users表與user_local_auth、user_third_auth。
  五、整個設計理念就是將自建用戶與第三方在存儲上區分，這在架構演進上也是合乎情理的，開始用戶體系大多自建，然後纔是對外接入。

總結

一、總的來說，第三方用戶的接入技術上來說是比較簡單的，這裏設計多一個user_thirds是能夠支持足夠多的第三方接入，固然通常咱們也就兩三個登陸就好，太多登陸方不只增長自身維護成本，界面擺盤也很差看。
二、這裏的設計方案不包含分表分庫、沒有服務化，就是簡單直接的設計。