基於分層的token架構設計

春夏秋冬過發表於2017-10-23

概述

在微服務執行體系中,不同型別的客戶端均通過閘道器訪問介面資源,就會出現以下圖片的格局

clipboard.png

不同的客戶端產生了不同的使用者使用場景,這些場景將在安全、會話、許可權、呼叫等方面存在著諸多的不同之處:

  • 有不同的環境安全威脅
  • 不同的會話生存週期
  • 不同的使用者許可權控制體系
  • 不同級別的介面呼叫方式

場景

  • web瀏覽器登陸系統,使用系統服務
  • 手機APP登陸系統,使用系統服務
  • 使用開放平臺登陸系統,使用系統服務
  • 使用者在PC處理登入狀態時通過手機掃碼授權手機登入
  • 使用者在手機處理登入狀態進通過手機掃碼授權PC進行登入

按照場景可以劃分token的類別
原始賬號密碼類別

  • 使用者名稱和密碼
  • APPKEY 和APPSercret

會話類別

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

介面呼叫類別

  • API端TOKEN

身份授權類別

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

token的層級關係

clipboard.png

原始賬號密碼類別

廣義的 賬號/密碼 有如下的呈現方式:

  • 傳統的註冊使用者名稱和密碼
  • 應用程式的app_id/app_key
    它們的特點如下:

會有特別的意義
比如:使用者自己為了方便記憶,會設定有一定含義的賬號和密碼。

不常修改
賬號密碼對使用者有特別含義,一般沒有特殊情況不會願意修改。 而APPKEY/APPSERCREAT則會寫在應用程式中,修改會意味著重新發布上線的成本

一旦洩露影響深遠
正因為不常修改,只要洩露了基本相當於使用者的網路身份被洩露,而且只要沒被察覺這種身份盜用就會一直存在

所以在認證系統中應該儘量減少傳輸的機會,避免洩露。

會話類別的token

功能:充當著session的角色,不同的客戶端有不同的生命週期。

使用步驟:

  • 使用者使用賬號密碼,換取會話token

不同的平臺的token有不同的特點。

Web平臺生存週期短

主要原因:

1、環境安全性
由於web登入環境一般很可能是公共環境,被他人盜取的風險值較大

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

移動端生存週期長

主要原因:

1、環境安全性
移動端平臺是個人使用者極其私密的平臺,它人接觸的機會不大

2、輸入便捷性
在移動端上使用手指在小螢幕上觸控輸入體驗差,輸入成本高

介面呼叫類別

功能:服務端應用程式api介面訪問和呼叫的憑證。

使用步驟:

1、使用具有較長生命週期的會話token來換取此介面訪問token。
其曝光頻率直接和介面呼叫頻率有關,屬於高頻使用的憑證。 為了照顧到隱私性,儘量減少其生命週期,即使被擷取了,也不至於產生嚴重的後果。

注意:在客戶端token之下還加上一個access_token, 主要是為了讓具有不同生命週期的客戶端token最後在呼叫api的時候, 能夠具有統一的認證方式。

身份授權類別

pam_token

功能:由已經登入和認證的PC端生成的二維碼的原始串號(Pc Auth Mobile)。

主要步驟如下:

1、PC上使用者已經完成認證,登入了系統
2、PC端生成一組和此使用者相關聯的pam_token
3、PC端將此pam_token的使用連結生成二維碼
4、移動端掃碼後,請求伺服器,並和使用者資訊關聯
5、移動端獲取refresh_token(長時效的會話)
6、根據 refresh_token 獲取 access_token
7、完成正常的介面呼叫工作

備註:

  • 生存週期為2分鐘,2分鐘後過期刪除
  • 沒有被使用時,每1分鐘變一次
  • 被使用後,立刻刪除掉
  • 此種認證模式一般不會被使用到

map_token

功能:由已經登入的移動app來掃碼認證PC端系統,並完成PC端系統的登入(Mobile Auth Pc)。

主要步驟:

1、移動端完成使用者身份的認證登入app
2、未登入的PC生成匿名的 map_token
3、移動端掃碼後在db中生成 map_token 和使用者關聯(完成簽名)
4、db同時針對此使用者生成 web_token
5、PC端一直以 map_token 為引數查詢此命名使用者的 web_token
6、PC端根據 web_token 去獲取 access_token
7、後續正常的呼叫介面呼叫工作

備註:

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

相關文章