token 多平臺身份認證架構設計思路

概述

在存在帳號體系的信息系統中，對身份的鑑定是很是重要的事情。

隨着移動互聯網時代到來，客戶端的類型愈來愈多， 逐漸出現了 一個服務器，N個客戶端的格局 。

不一樣的客戶端產生了不一樣的用戶使用場景，這些場景：

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

綜上所述，它們的身份認證方式也存在必定的區別。

本文將使用必定的篇幅對這些場景進行一些分析和梳理工做。

使用場景

下面是一些在IT服務常見的一些使用場景:

• 用戶在web瀏覽器端登陸系統,使用系統服務
• 用戶在手機端（Android/iOS）登陸系統,使用系統服務
• 用戶使用開放接口登陸系統,調用系統服務
• 用戶在PC處理登陸狀態時經過手機掃碼受權手機登陸（使用得比較少）
• 用戶在手機處理登陸狀態進經過手機掃碼受權PC進行登陸（比較常見）

經過對場景的細分,獲得以下不一樣的認證token類別:

• 原始帳號密碼類別
• 用戶名和密碼
• API應用ID/KEY
• 會話ID類別
• 瀏覽器端token
• 移動端token
• API應用token
• 接口調用類別
• 接口訪問token
• 身份受權類別
• PC和移動端相互受權的token

token的類別

不一樣場景的token進行以下幾個維度的對比:

自然屬性對比

• 使用成本
• 帳號密碼須要用戶打開頁面而後逐個鍵入
• 二維碼須要用戶掏出手機進行掃碼操做
• 本認證方式在使用的時候,形成的不便性。好比:
• 變化成本
• 用戶名和密碼發生變化時,用戶須要額外記憶和從新鍵入新密碼
• API應用ID/KEY發生變化時,第三方應用須要從新在代碼中修改並部署
• 受權二維碼發生變化時,須要用戶從新打開手機應用進行掃碼
• 本認證方式,token發生變化時,用戶須要作出的相應更改的成本:
• 環境風險
• 被偷窺的風險
• 被抓包的風險
• 被僞造的風險

可調控屬性對比

• 使用頻率
• 在網路中傳送的頻率
• 有效時間
• 此token從建立到終結的生存時間

最終的目標:安全和影響。

• 安全和隱私性主要體如今:
• token 不容易被竊取和盜用（經過對傳送頻率控制）
• token 即便被竊取,產生的影響也是可控的（經過對有效時間控制）

關於隱私及隱私破壞後的後果,有以下的基本結論:

• 曝光頻率高的容易被截獲
• 生存週期長的在被截獲後產生的影響更嚴重和深遠

遵照以下原則:

• 變化成本高的token不要輕易變化
• 不輕易變化的token要減小曝光頻率（網絡傳輸次數）
• 曝光頻率高的token的生存週期要儘可能短

將各種token的固有特色及可控屬性進行調控後, 對每一個指標進行量化評分（1~5分），咱們能夠獲得以下的對比表：

備註:user_name/passwd 和 app_id/app_key 是等價的效果

token的層級關係

參考上一節的對比表，能夠很容易對這些不一樣用途的token進行分層，主要能夠分爲4層：

• 密碼層
• 最傳統的用戶和系統之間約定的數字身份認證方式
• 會話層
• 用戶登陸後的會話生命週期的會話認證
• 調用層
• 用戶在會話期間對應用程序接口的調用認證
• 應用層
• 用戶獲取了接口訪問調用權限後的一些場景或者身份認證應用

token的分層圖以下：

在一個多客戶端的信息系統裏面,這些token的產生及應用的內在聯繫以下:

• 用戶輸入用戶名和用戶口令進行一次性認證
• 在 不一樣 的終端裏面生成擁有 不一樣 生命週期的會話token
• 客戶端會話token從服務端交換生命週期短但曝光 頻繁 的接口訪問token
• 會話token能夠生成和刷新延長 access_token 的生存時間
• access_token能夠生成生存週期最短的用於受權的二維碼的token

使用如上的架構有以下的好處：

• 良好的統一性。能夠解決不一樣平臺上認證token的生存週期的 歸一化 問題
• 良好的解耦性。核心接口調用服務器的認證 access_token 能夠完成獨立的實現和部署
• 良好的層次性。不一樣平臺的能夠有徹底不一樣的用戶權限控制系統，這個控制能夠在會話層 中各平臺解決掉

帳號密碼

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

• 傳統的註冊用戶名和密碼
• 應用程序的app_id/app_key

它們的特色以下：

• 會有特別的意義
• 好比：用戶本身爲了方便記憶，會設置有必定含義的帳號和密碼。
• 不常修改
• 帳號密碼對用戶有特別含義，通常沒有特殊狀況不會願意修改。而app_id/app_key則會寫在應用程序中，修改會意味着從新發布上線的成本
• 一旦泄露影響深遠
• 正由於不常修改，只要泄露了基本至關於用戶的網絡身份被泄露，並且只要沒被察覺這種身份盜用就會一直存在

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

客戶端會話token

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

使用步驟：

• 用戶使用帳號密碼，換取會話token
• 不一樣的平臺的token有不一樣的特色。

Web平臺生存週期短

• 主要緣由
• 在PC上使用鍵盤輸入會比較便捷
• 因爲web登陸環境通常極可能是公共環境，被他人盜取的風險值較大
• 環境安全性
• 輸入便捷性

移動端生存週期長

• 主要緣由
• 在移動端上使用手指在小屏幕上觸摸輸入體驗差，輸入成本高
• 移動端平臺是我的用戶極其私密的平臺，它人接觸的機會不大
• 環境安全性
• 輸入便捷性

access_token

功能：服務端應用程序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分鐘變一次
• 被使用後,馬上刪除掉

小結與展望

本文所設計的基於token的身份認證系統，主要解決了以下的問題：

• token的分類問題
• token的隱私性參數設置問題
• token的使用場景問題
• 不一樣生命週期的token分層轉化關係

本文中提到的設計方法，在 應用層 中能夠適用於且不限於以下場景中：

• 用戶登陸
• 有時效的優惠券發放
• 有時效的邀請碼發放
• 有時效的二維碼受權
• 具備時效 手機/郵件 驗證碼
• 多個不一樣平臺調用同一套API接口
• 多個平臺使用同一個身份認證中心

至於更多的使用場景，就須要你們去發掘了。

做者：哈莫 
原文：cnblogs.com/beer/p/6029861.html