如何設計 QQ、微信、微博、Github 等等,第三方賬號登陸 ?(附表設計)

菜鳥要飛訂閱號發表於2022-12-05
  • 前言:多賬戶登陸
  • 1. 創業初期
    • 使用者名稱密碼註冊登陸
    • 手機號註冊登陸
  • 2. 資料庫設計
  • 3. 引入第三方賬戶方案
  • 4. 資料庫設計
  • 5. 總結

前言:多賬戶登陸

網際網路應用當中,我們的應用會使用多個第三方賬號進行登入,比如:網易、微信、QQ等,我們把此稱為多賬戶統一登陸。透過這篇文章, 我想闡釋多賬戶登陸的技術方案細節,以及相應的表設計,流程設計。我這裡不會有具體程式碼實現細節,只要方案做的對,有思路,程式碼咋寫都不會太爛。
如何設計 QQ、微信、微博、Github 等等,第三方賬號登陸 ?(附表設計)

1. 創業初期

歸結為創業初期是因為這個時候使用者量比較少,甚至還沒有接入上面所說的其他第三方的賬戶系統,只是自建的體系就可以滿足,自建體系的話,目前常用的有如下解決方案:

使用者名稱密碼註冊登陸

這種方式在很多初期網站建設會使用,先註冊,再進行登入,在老一點的cms中都能找到這個影子。流程圖如下:
如何設計 QQ、微信、微博、Github 等等,第三方賬號登陸 ?(附表設計)
流程說明:

  1. 前端將使用者名稱、密碼傳送到伺服器,伺服器進行常規的判斷,判斷使用者名稱、密碼長度是否滿足,使用者名稱是否重複等條件,條件不透過直接返回對應錯誤碼給到前端,這裡密碼欄位,為了防止傳輸過程中被截胡,建議加密再上傳,我們的傳輸密碼預設都是會進行一個md5加密,然後記錄到資料庫再進行一層加密,就算是脫庫也沒事,密碼不要明文儲存。
  2. 校驗透過後,就將使用者名稱密碼寫入資料庫,並進行後面積分發放等操作,這裡不展開。
  3. 現在進行登入,前端將使用者名稱,密碼傳送給到服務端,服務端首先會校驗登入次數是否超過設定的閾值,如果超過只能繼續等待被關小黑屋。
  4. 如果未超過繼續登入邏輯,判斷使用者名稱、密碼是否正確,不正確密碼則進行閾值的判斷,如果超過則關小黑屋,記住小黑屋必須設定過期時間,要不然就會永久關上了,這個可以用redis的過期來做。
  5. 登入成功後進行後續的一切後置邏輯,比如加積分等操作。

手機號註冊登陸

簡訊業務非常成熟,使用手機號註冊方便快捷。其流程如下:
如何設計 QQ、微信、微博、Github 等等,第三方賬號登陸 ?(附表設計)
流程說明:

  1. 首先輸入手機號,然後傳送到服務端,服務端將手機號記錄在我們資料庫中,然後生成隨機驗證碼,並將手機號和驗證碼繫結到一個redis裡面,然後記錄過期時間,這個過期時間一般是10分鐘左右,這就是我們一般手機驗證碼的有效期。
  2. 手機接收到手機簡訊後,那麼就在介面填寫驗證碼傳送服務端,服務端收到驗證碼後就會在redis裡面查詢到這個手機號對應的驗證碼,失敗就返回錯誤碼。
  3. 成功後就進行登入操作。

這裡看起來沒有明確的註冊登入操作,其實在傳送手機號碼就可以認為是一個常規的註冊,然後後面的驗證碼輸入就是一個登陸操作,
問: 那我要密碼咋辦?
答: 在後續產品裡面增加一個手機號碼密碼補錄的功能即可,這也是現在很常規的手法,但是現在移動網際網路大爆炸時代,密碼已經顯得不是那麼重要了,反正我從來記不住密碼,如果手機號碼能操作的app,絕對不用密碼來操作。

2. 資料庫設計

表結構
如何設計 QQ、微信、微博、Github 等等,第三方賬號登陸 ?(附表設計)
說明: 這裡只是單純說明需要用到的資料,沒有擴充套件具體場景,這個表結構能夠滿足上面兩個方案的設計。

3. 引入第三方賬戶方案

這裡是以QQ-SDK的登入邏輯, 我們先來一波時序圖:
如何設計 QQ、微信、微博、Github 等等,第三方賬號登陸 ?(附表設計)
實現思路:

  1. 客戶端自己調起登入的介面,進行輸入使用者名稱、密碼,這裡的是第三方的使用者名稱,密碼,登入成功後,會返回access_token openid expire_in,這過程會使用到oauth2.0,不過在sdk裡面進行內建回撥獲取了,後面我們會說明我們自身實現的oauth2.0
  2. 客戶端拿到access_token、openid、login_type(qq、wechat…)請求應用伺服器,應用伺服器拿到這些資料後就會根據對應的login_type去對應的使用者中心進行access_token和openid進行校驗。

校驗不透過則返回對應錯誤碼

  1. 校驗透過後就會判斷本地是否有這個login_type和openid是否存在,不存在則進行獲取遠端的使用者名稱、頭像等基礎資訊來作為本地基礎資料,並且返回code值
  2. 如果已經存在,那就是進行登入操作,返回code值。
  3. 客戶端拿到code值後進行token值的換取,這個完全遵照oauth2.0的協議來走的,後續每次請求必須帶上token,token值在服務端的時間比較久,因為我們想要做的是那種永不下線的操作,所以每次請求我們都將token過期時間進行累加。

4. 資料庫設計

表結構
資料庫的整理 使用者基礎表(users):
如何設計 QQ、微信、微博、Github 等等,第三方賬號登陸 ?(附表設計)
使用者驗證關聯表(user_auth_rel)
如何設計 QQ、微信、微博、Github 等等,第三方賬號登陸 ?(附表設計)
本地使用者表(user_local_auth)
如何設計 QQ、微信、微博、Github 等等,第三方賬號登陸 ?(附表設計)
第三方使用者表(user_third_auth)
如何設計 QQ、微信、微博、Github 等等,第三方賬號登陸 ?(附表設計)
說明

  1. users表只是單純針對我們業務側的登入,主要是做自身業務的oauth2.0業務,
  2. user_local_auth是做自己使用者名稱、密碼登入,手機號碼登入資訊記錄,
  3. user_third_auth是我們第三方使用者體系的資料記錄,
  4. user_auth_rel是用來關聯我們users表與user_local_auth、user_third_auth。
  5. 整個設計理念就是將自建使用者與第三方在儲存上區分,這在架構演進上也是合乎情理的,開始使用者體系大多自建,而後才是對外接入。

5. 總結

總的來講,第三方使用者的接入技術上來講是比較簡單的,這裡設計多一個user_thirds是可以支援足夠多的第三方接入,當然一般我們也就兩三個登入就好,太多登入方不僅自身維護成本,介面擺盤也不好看不是。

希望大家能夠透過以上學習,能夠對於我們多賬戶登入有一個比較好的認知,這裡設計方案不包含分表分庫、沒有服務化,就是簡單直接的設計,當然使用者量和需要的不一樣,在這個基礎上還要加很多東西,謝謝大家閱讀,喜歡文章歡迎轉發,點贊。

作者丨低調的碼農;來源:

來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/31557372/viewspace-2671003/,如需轉載,請註明出處,否則將追究法律責任。

相關文章