一種全新的分佈式用戶認證架構設計

前言

分佈式用戶認證, 有個簡單的稱謂就是單點登錄, 即一處登錄,處處通行.
說詳細一點就是,集中的用戶統一身份認證和分佈的式的用戶驗證和資源訪問控制.
對於小公司而言,提供的服務少,經常用戶認證和服務混合在一塊兒,體會不到分佈式用戶認證好處.
隨着公司規模的擴大,提供的服務愈來愈多,把用戶認證和服務提供拆分開來,實現分佈式用戶認證,可下降系統的相互依賴性,提升系統的可擴展性.

常見的方案

基於普通token的方案.

這個方案一般在用戶登陸後,把用戶信息儲存與中心服務器, 同時給客戶端一個普通token, 之後訪問服務時均以此token識別用戶身份. 這個token只是一個hash值,一個惟一的ID,自身不含用戶信息,要辨別token的真僞,須要的中心服務器查詢,這是一個集中用戶認證的方案,簡單易用,當可擴展性不高.

本文介紹一個新的方案

基於JSON Web Token(JWT)的方案.

JWT,簡單的說就是把用戶的公開信息和信息的簽名合成一個字符串，保證信息沒法僞造．詳細可參考互聯網上的資料。
JWT 和基於hash值的普通token的主要不一樣點：

1. JWT 自身包含用戶的公開信息。
2. JWT 不用到中心服務器查詢就可驗證真僞。
   這些特色，使得JWT 很像現實生活中的身份證，簽證等證件。
   這個方案，經過用戶登錄後，中心服務器給客戶端一個JWT，這個JWT包含用戶的公開信息，還有用戶權限等信息。以後，客戶端訪問服務時，就以這個JWT做爲身份識別，而服務提供者，不用到中心服務器查詢，本身可校驗這個JWT的真僞。

以示範案例說明

以一個社區應用例，功能模塊以下:

1. 發帖討論的論壇模塊
2. 實時通訊模塊
3. 收費的教育視頻模塊
4. 收費的音樂模塊
   固然，以上四部分都須要用戶認證。
   這四個模塊，一般由四個項目組完成。

做爲架構設計者，有兩個重要的思想：

1. 假設這四個模塊，分別由四個獨立的公司來開發。
2. 每一個模塊不僅咱們公司用，其餘公司也可用
   就是把API或是服務service 當作最終獨立的產品來設計，這樣就能設計出好的架構．

對於這個系統，咱們看看用戶認證系統如何設計？
拋開傳統的登錄概念，傳統的登錄一般只是登錄一個地方，訪問一種服務．

當設計認證系統時，不要想咱們在設計軟件系統，就當在設計一個國家，沒錯一個虛擬的國家．
看看國家的分佈式用戶認證是怎麼運做的？
以美國爲例，移民局負責頒發用戶簽證，而裏面的大學，酒店，企業就是各類服務提供者．
這裏用戶認證和服務提供是分開的．

要入境美國，首先得像移民局申請簽證．
當用戶拿着簽證去住酒店時，酒店服務員會查看簽證的真僞及有效期．
當用戶拿着簽證去住企業應聘時，企業會查看簽證的真僞及有效期，還有就是權限，若是是旅遊簽證，對不起，旅遊簽證不能打工．
注意：簽證是由移民局集中發行的，而校驗確是分佈的.
酒店服務員驗證簽證時，不會打電話到移民局查詢真僞．

咱們的用戶認證系統，其實只要把這一套機制幫過來便可．
由統一的用戶認證系統負責頒發簽證，而用戶訪問各類服務時，持有這個簽證就能夠了．
用戶認證後，咱們能夠把用戶的公開信息如user id等，還有就是受權信息，好比６個月的視頻教程受權，１個月的音樂受權等寫到這個簽證上，這樣用戶就可訪問各類服務．
JWT 防僞有兩類簽名機制，一類是基於secretKey的Hash機制，一類是非對稱簽名機制．
第一類Hash機制，JWT的建立和驗證使用同一個祕鑰，僅適合公司內部用．對應開放平臺，要開放給其餘公司使用，須要採用非對稱簽名機制，這樣建立和校驗是兩個祕鑰，保證token的集中發行．

分佈式JWT用戶驗證的問題．

分佈式JWT用戶驗證的問題的一個問題是，Token 一旦發行，沒法註銷，只能等其自行失效．
這個不單是JWT的問題，全部可分佈式驗證的證件都有這個問題，包括身份證，簽證，駕照等．
駕照丟了，去管理局註銷，但這個註銷，不會讓丟失的駕照當即失效，除非駕照的驗證是集中式的．
這也是爲何幾乎全部的證件都有一個有效期的緣由．

對應JWT，爲了保證安全，咱們可使用一個比較短的有效期，同時採用一種以舊換新的機制，確保安全．
這個機制有點相似生活中的駕照年審或者簽證延期，即每隔一段時間作一次審查並核發新證，因爲不須要人工操做，咱們的這個審查頻率提升一些．

Token以舊換新的機制,請參看：
http://www.jianshu.com/p/b4cf771e570e

注：現實生活中，護照和簽證有些差異，對於軟件系統這個差異就不考慮了，統一當成證實身份的證件．