使用者中心系統設計

背景

一般來說大型網際網路公司會把授權和使用者資訊的邏輯放到一個應用中，而這個應用我們統一稱為使用者中心。

使用者中心不關心具體的業務邏輯，隻處理使用者資訊相關的管理及授權登入。當第三方應用需要登入的時候，會把使用者的登入請求轉發到使用者中心處理，處理完畢後，傳回給第三方應用，第三方應用根據對應的憑證登入到系統内部。

主要功能如下

• 使用者登入與注冊
• 基本資訊查詢與修改

從功能來看，整個使用者中心還是很簡單單，不過其中的邏輯還挺複雜的，比如注冊功能，就要分為手機注冊與郵箱注冊，手機要發送手機驗證碼，郵箱需要發送驗證郵件，點選郵箱裡面的連結跳轉并進行後續注冊流程，上面每步都需要業務上重新發送機制。

功能介紹

使用者登入

在網際網路使用者中心體系中，一般會支援手機、郵箱、帳号、三方登入。其中三方登入一般會接入 QQ、微信、微網誌這三種方式。

密碼登入

1. 使用者在浏覽器端填寫 username + password ，然後送出到服務端
2. 服務端拿到使用者送出的 username + password 驗證。
3. 驗證成功後，伺服器傳回請求，同時将 cookie 寫到對應域      

上述流程中，大家肯定會考慮到密碼的安全性，我們到底該怎麼做才能防止密碼被洩露？對稱加密還是非對稱加密? 如果是對稱加密，用戶端被黑客反編譯，就能拿到密鑰，那麼所有使用者的密碼就會存在非常大的洩露風險？如果是非對稱加密，私鑰要放在哪裡才能保證安全？

通用簡單的解決方案: Https + MD5 + 随機鹽

Https 我就不用在述說了，基本上 Chrome、Firfox 都對不是 Https 的站點進行安全提醒，是以 Https 該上的還是盡快上吧

那如果公司很窮，買不起 Https 證書咋辦呢？那麼隻能在前端頁面上做點文章。

由于前端代碼暴露在浏覽器上，我們隻能采用不可逆的密碼或者摘要算法，類是與 MD5 / Hash 算法 。如果進階的話，就采用随機 Salt 來提高攻擊成本，針對不同使用者，加入不同的 Salt，而不是固定鹽的方式。使用這種方式的前提「目前對安全的要求不高」

那我們該如何驗證密碼？用戶端端送出 MD5(password）密碼。服務端通過 MD5 (Salt + MD5(passowrd))的邏輯來計算最終密碼，同時 Salt 隻會出現在服務端，且每個使用者采用不同 Salt 的方式來生成。這一系列過程中，都沒有接觸到原始的使用者密碼，如果出現使用者的密碼被劫持的話，隻會發生在使用者在送出密碼前截獲，這個也就是為什麼需要密碼控件？

三方登入

當使用者以某種登入方式成功登入之後，我們能可以擷取到對應 User 表中的使用者基礎資訊，而登入操作隻是為了認證使用者這個過程，無論用本地密碼驗證還是第三方登入，以上過程本質上都是認證的形式。

是以使用者的資訊與登入的授權其實是獨立開來的，即 uid 與 登入方式是一對多的關系。比如： 使用者 A 使用「微信」登入，服務端認證身份後 uid = abc。而下一次使用者 A 使用「微網誌」登入，同樣服務端認證出來 uid = abc。

使用者資訊表（user_base）隻存儲使用者 Profile 相關資訊

id | name | city
----+------+-----------------
 A1 | Tom  | 上海
 A2 | Jack |  背景      

id | user_id | password
----+---------+----------
 1 | A1      | qazwsx
 2 | A2      | edcrfv      

id | user_id | weibo_id | weibo_access_token | weibo_expires
----+---------+----------+--------------------+---------------
 1 | A1      | W-qaz | xxxxxxxxxx         | 604800
 2 | A2      | W-wsx | xxxxxxxxxx         | 604800      

原創文章請随便轉載。願和大家分享，并且一起進步。-- 江 coder