權限系統設計學習總結(3)——多賬戶的統一登錄

前言

多賬戶系統是指,在我們互聯網應用當中,我們的應用會使用多個第三方賬號進行登錄,必須現在常用的APP(網易雲音樂)登錄方式包含:網易、微信、QQ。大部分的 App 都支持使用多個第三方賬號進行登錄,如:微信、QQ、微博等,我們把此稱爲多賬號統一登陸。而這些賬號的表設計,流程設計至關重要。

一、自建賬戶體系

歸結爲創業初期是因爲這個時候用戶量比較少,甚至還沒有接入上面所說的其他第三方的賬戶系統,只是自建的體系就可以滿足,自建體系的話,目前常用的有:用戶名密碼註冊登陸。這種方式在很多初期網站建設會使用,先註冊,再進行登錄,在老一點的cms中都能找到這個影子。

流程說明:

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

手機號註冊登陸

流程說明:

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

這裏看起來沒有明確的註冊登錄操作,其實在發送手機號碼就可以認爲是一個常規的註冊,然後後面的驗證碼輸入就是一個登陸操作。

問:那我要密碼咋辦?

答:在後續產品裏面增加一個手機號碼密碼補錄的功能即可,這也是現在很常規的手法,但是現在移動互聯網大爆炸時代,密碼已經顯得不是那麼重要了,反正我從來記不住密碼,如果手機號碼能操作的app,絕對不用密碼來操作。

數據庫設計

說明:這裏只是單純說明需要用到的數據,沒有擴展具體場景,這個表結構能夠滿足上面兩個方案的設計。

二、引入第三方賬戶方案

這裏是以QQ-SDK的登錄邏輯, 我們先來一波時序圖

說明:

  1. 客戶端自己調起登錄的界面,進行輸入用戶名、密碼,這裏的是第三方的用戶名,密碼,登錄成功後,會返回access_token openid expire_in,這過程會使用到oauth2.0,不過在sdk裏面進行內置回調獲取了,後面我們會說明我們自身實現的oauth2.0
  2. 客戶端拿到access_token、openid、login_type(qq、wechat…)請求應用服務器,應用服務器拿到這些數據後就會根據對應的login_type去對應的用戶中心進行access_token和openid進行校驗。校驗不通過則返回對應錯誤碼。
  3. 校驗通過後就會判斷本地是否有這個login_type和openid是否存在,不存在則進行獲取遠程的用戶名、頭像等基礎信息來作爲本地基礎數據,並且返回code值。
  4. 如果已經存在,那就是進行登錄操作,返回code值。
  5. 客戶端拿到code值後進行token值的換取,這個完全遵照oauth2.0的協議來走的,後續每次請求必須帶上token,token值在服務端的時間比較久,因爲我們想要做的是那種永不下線的操作,所以每次請求我們都將token過期時間進行累加。

數據庫設計

用戶基礎表(users)

用戶驗證關聯表(user_auth_rel)

本地用戶表(user_local_auth)

第三方用戶表(user_third_auth)

說明:

  1. users表只是單純針對我們業務側的登錄,主要是做自身業務的oauth2.0業務,
  2. user_local_auth是做自己用戶名、密碼登錄,手機號碼登錄信息記錄,
  3. user_third_auth是我們第三方用戶體系的數據記錄,
  4. user_auth_rel是用來關聯我們users表與user_local_auth、user_third_auth。

整個設計理念就是將自建用戶與第三方在存儲上區分,這在架構演進上也是合乎情理的,開始用戶體系大多自建,而後纔是對外接入。

三、總結

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

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章