基於分層的token架構設計

概述

在微服務運行體系中，不一樣類型的客戶端均經過網關訪問接口資源，就會出現如下圖片的格局

不一樣的客戶端產生了不一樣的用戶使用場景，這些場景將在安全、會話、權限、調用等方面存在着諸多的不一樣之處：

• 有不一樣的環境安全威脅
• 不一樣的會話生存週期
• 不一樣的用戶權限控制體系
• 不一樣級別的接口調用方式

場景

• web瀏覽器登錄系統，使用系統服務
• 手機APP登錄系統，使用系統服務
• 使用開放平臺登錄系統，使用系統服務
• 用戶在PC處理登陸狀態時經過手機掃碼受權手機登陸
• 用戶在手機處理登陸狀態進經過手機掃碼受權PC進行登陸

按照場景能夠劃分token的類別
原始帳號密碼類別

• 用戶名和密碼
• APPKEY 和APPSercret

會話類別

• 瀏覽器端TOKEN
• APP端TOKEN
• API端TOKEN

接口調用類別

• API端TOKEN

身份受權類別

• PC和移動端相互受權的token

token的層級關係

原始帳號密碼類別

廣義的 帳號/密碼 有以下的呈現方式:

• 傳統的註冊用戶名和密碼
• 應用程序的app_id/app_key
  它們的特色以下：

會有特別的意義
好比：用戶本身爲了方便記憶，會設置有必定含義的帳號和密碼。

不常修改
帳號密碼對用戶有特別含義，通常沒有特殊狀況不會願意修改。 而APPKEY/APPSERCREAT則會寫在應用程序中，修改會意味着從新發布上線的成本

一旦泄露影響深遠
正由於不常修改，只要泄露了基本至關於用戶的網絡身份被泄露，並且只要沒被察覺這種身份盜用就會一直存在

因此在認證系統中應該儘可能減小傳輸的機會，避免泄露。

會話類別的token

功能：充當着session的角色，不一樣的客戶端有不一樣的生命週期。

使用步驟：

• 用戶使用帳號密碼，換取會話token

不一樣的平臺的token有不一樣的特色。

Web平臺生存週期短

主要緣由：

一、環境安全性
因爲web登陸環境通常極可能是公共環境，被他人盜取的風險值較大

二、輸入便捷性
在PC上使用鍵盤輸入會比較便捷

移動端生存週期長

主要緣由：

一、環境安全性
移動端平臺是我的用戶極其私密的平臺，它人接觸的機會不大

二、輸入便捷性
在移動端上使用手指在小屏幕上觸摸輸入體驗差，輸入成本高

接口調用類別

功能：服務端應用程序api接口訪問和調用的憑證。

使用步驟：

一、使用具備較長生命週期的會話token來換取此接口訪問token。
其曝光頻率直接和接口調用頻率有關，屬於高頻使用的憑證。 爲了照顧到隱私性，儘可能減小其生命週期，即便被截取了，也不至於產生嚴重的後果。

注意：在客戶端token之下還加上一個access_token， 主要是爲了讓具備不一樣生命週期的客戶端token最後在調用api的時候， 可以具備統一的認證方式。

身份受權類別

pam_token

功能：由已經登陸和認證的PC端生成的二維碼的原始串號（Pc Auth Mobile）。

主要步驟以下：

一、PC上用戶已經完成認證，登陸了系統
二、PC端生成一組和此用戶相關聯的pam_token
三、PC端將此pam_token的使用連接生成二維碼
四、移動端掃碼後，請求服務器，並和用戶信息關聯
五、移動端獲取refresh_token(長時效的會話)
六、根據 refresh_token 獲取 access_token
七、完成正常的接口調用工做

備註:

• 生存週期爲2分鐘,2分鐘後過時刪除
• 沒有被使用時,每1分鐘變一次
• 被使用後,馬上刪除掉
• 此種認證模式通常不會被使用到

map_token

功能：由已經登陸的移動app來掃碼認證PC端系統，並完成PC端系統的登陸（Mobile Auth Pc）。

主要步驟：

一、移動端完成用戶身份的認證登陸app
二、未登陸的PC生成匿名的 map_token
三、移動端掃碼後在db中生成 map_token 和用戶關聯（完成簽名）
四、db同時針對此用戶生成 web_token
五、PC端一直以 map_token 爲參數查找此命名用戶的 web_token
六、PC端根據 web_token 去獲取 access_token
七、後續正常的調用接口調用工做

備註:

• 生存週期爲2分鐘,2分鐘後過時刪除
• 沒有被使用時,每1分鐘變一次
• 被使用後,馬上刪除掉