基於token的多平台身份認證架構設計
1 概述
在存在賬號體系的信息系統中，對身份的鑒定是非常重要的事情。
隨着移動互聯網時代到來，客戶端的類型越來越多， 逐漸出現了 一個服務器，N個客戶端的格局 。
不同的客戶端產生了不同的用戶使用場景，這些場景：
- 有不同的環境安全威脅
- 不同的會話生存周期
- 不同的用戶權限控制體系
- 不同級別的接口調用方式
綜上所述，它們的身份認證方式也存在一定的區別。
本文將使用一定的篇幅對這些場景進行一些分析和梳理工作。
2 使用場景
下面是一些在IT服務常見的一些使用場景:
- 用戶在web瀏覽器端登錄系統,使用系統服務
- 用戶在手機端（Android/iOS）登錄系統,使用系統服務
- 用戶使用開放接口登錄系統,調用系統服務
- 用戶在PC處理登錄狀態時通過手機掃碼授權手機登錄（使用得比較少）
- 用戶在手機處理登錄狀態進通過手機掃碼授權PC進行登錄（比較常見）
通過對場景的細分,得到如下不同的認證token類別:
-
- 原始賬號密碼類別
-
- 用戶名和密碼
- API應用ID/KEY
-
- 會話ID類別
-
- 瀏覽器端token
- 移動端token
- API應用token
-
- 接口調用類別
-
- 接口訪問token
-
- 身份授權類別
-
- PC和移動端相互授權的token
3 token的類別
不同場景的token進行如下幾個維度的對比:
天然屬性 對比:
-
- 使用成本
-
本認證方式在使用的時候,造成的不便性。比如:
- 賬號密碼需要用戶打開頁面然后逐個鍵入
- 二維碼需要用戶掏出手機進行掃碼操作
-
- 變化成本
-
本認證方式,token發生變化時,用戶需要做出的相應更改的成本:
- 用戶名和密碼發生變化時,用戶需要額外記憶和重新鍵入新密碼
- API應用ID/KEY發生變化時,第三方應用需要重新在代碼中修改並部署
- 授權二維碼發生變化時,需要用戶重新打開手機應用進行掃碼
-
環境風險
- 被偷窺的風險
- 被抓包的風險
- 被偽造的風險
可調控屬性 對比:
-
- 使用頻率
-
- 在網路中傳送的頻率
-
- 有效時間
-
- 此token從創建到終結的生存時間
最終的目標:安全和影響。
安全和隱私性主要體現在:
- token 不容易被竊取和盜用（通過對傳送頻率控制）
- token 即使被竊取,產生的影響也是可控的（通過對有效時間控制）
關於隱私及隱私破壞后的后果,有如下的基本結論:
- 曝光頻率高的容易被截獲
- 生存周期長的在被截獲后產生的影響更嚴重和深遠
遵守如下原則:
- 變化成本高的token不要輕易變化
- 不輕易變化的token要減少曝光頻率（網絡傳輸次數）
- 曝光頻率高的token的生存周期要盡量短
將各類token的固有特點及可控屬性進行調控后, 對每個指標進行量化評分（1~5分），我們可以得到如下的對比表：
備注:
- user_name/passwd 和 app_id/app_key 是等價的效果
4 token的層級關系
參考上一節的對比表，可以很容易對這些不同用途的token進行分層，主要可以分為4層：
-
- 密碼層
-
最傳統的用戶和系統之間約定的數字身份認證方式
-
- 會話層
-
用戶登錄后的會話生命周期的會話認證
-
- 調用層
-
用戶在會話期間對應用程序接口的調用認證
-
- 應用層
-
用戶獲取了接口訪問調用權限后的一些場景或者身份認證應用
在一個多客戶端的信息系統里面,這些token的產生及應用的內在聯系如下:
- 用戶輸入用戶名和用戶口令進行一次性認證
- 在 不同 的終端里面生成擁有 不同 生命周期的會話token
- 客戶端會話token從服務端交換生命周期短但曝光 頻繁 的接口訪問token
- 會話token可以生成和刷新延長 access_token 的生存時間
- access_token可以生成生存周期最短的用於授權的二維碼的token
使用如上的架構有如下的好處：
- 良好的統一性。可以解決不同平台上認證token的生存周期的 歸一化 問題
- 良好的解耦性。核心接口調用服務器的認證 access_token 可以完成獨立的實現和部署
- 良好的層次性。不同平台的可以有完全不同的用戶權限控制系統，這個控制可以在 會話層 中各平台解決掉
4.1 賬號密碼
廣義的 賬號/密碼 有如下的呈現方式:
- 傳統的注冊用戶名和密碼
- 應用程序的app_id/app_key
它們的特點如下：
-
- 會有特別的意義
-
比如：用戶自己為了方便記憶，會設置有一定含義的賬號和密碼。
-
- 不常修改
-
賬號密碼對用戶有特別含義，一般沒有特殊情況不會願意修改。 而app_id/app_key則會寫在應用程序中，修改會意味着重新發布上線的成本
-
- 一旦泄露影響深遠
-
正因為不常修改，只要泄露了基本相當於用戶的網絡身份被泄露，而且只要沒被察覺這種身份盜用就會一直存在
所以在認證系統中應該盡量減少傳輸的機會，避免泄露。
4.2 客戶端會話token
功能：充當着session的角色，不同的客戶端有不同的生命周期。
使用步驟：
- 用戶使用賬號密碼，換取會話token
不同的平台的token有不同的特點。
Web平台生存周期短
主要原因：
-
- 環境安全性
-
由於web登錄環境一般很可能是公共環境，被他人盜取的風險值較大
-
- 輸入便捷性
-
在PC上使用鍵盤輸入會比較便捷
移動端生存周期長
主要原因：
-
- 環境安全性
-
移動端平台是個人用戶極其私密的平台，它人接觸的機會不大
-
- 輸入便捷性
-
在移動端上使用手指在小屏幕上觸摸輸入體驗差，輸入成本高
4.3 access_token
功能：服務端應用程序api接口訪問和調用的憑證。
使用步驟：
- 使用具有較長生命周期的會話token來換取此接口訪問token。
其曝光頻率直接和接口調用頻率有關，屬於高頻使用的憑證。 為了照顧到隱私性，盡量減少其生命周期，即使被截取了，也不至於產生嚴重的后果。
注意：在客戶端token之下還加上一個access_token， 主要是為了讓具有不同生命周期的客戶端token最后在調用api的時候， 能夠具有統一的認證方式。
4.4 pam_token
功能：由已經登錄和認證的PC端生成的二維碼的原始串號（Pc Auth Mobile）。
主要步驟如下：
- PC上用戶已經完成認證，登錄了系統
- PC端生成一組和此用戶相關聯的pam_token
- PC端將此pam_token的使用鏈接生成二維碼
- 移動端掃碼后，請求服務器，並和用戶信息關聯
- 移動端獲取refresh_token(長時效的會話)
- 根據 refresh_token 獲取 access_token
- 完成正常的接口調用工作
備注:
- 生存周期為2分鍾,2分鍾后過期刪除
- 沒有被使用時,每1分鍾變一次
- 被使用后,立刻刪除掉
- 此種認證模式一般不會被使用到
4.5 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分鍾變一次
- 被使用后,立刻刪除掉
5 小結與展望
本文所設計的基於token的身份認證系統，主要解決了如下的問題：
- token的分類問題
- token的隱私性參數設置問題
- token的使用場景問題
- 不同生命周期的token分層轉化關系
本文中提到的設計方法，在 應用層 中可以適用於且不限於如下場景中：
- 用戶登錄
- 有時效的優惠券發放
- 有時效的邀請碼發放
- 有時效的二維碼授權
- 具有時效 手機/郵件 驗證碼
- 多個不同平台調用同一套API接口
- 多個平台使用同一個身份認證中心
至於更多的使用場景，就需要大家去發掘了。
關於如何在技術上實現不同token的生存周期問題，將在后續文章中進行介紹，敬請期待。
補充內容：關於具備生命周期的token的技術實現方式
http://www.cnblogs.com/beer/p/6030882.html
| 作者: | Harmo哈莫 |
|---|---|
| 作者介紹: | https://zhengwh.github.io |
| 技術博客: | http://www.cnblogs.com/beer |
| Email: | dreamzsm@gmail.com |
| QQ: | 1295351490 |
| 時間: | 2016-02 |
| 版權聲明: | 歡迎以學習交流為目的讀者隨意轉載，但是請 【注明出處】 |
| 支持本文: | 如果文章對您有啟發，可以點擊博客右下角的按鈕進行 【推薦】 |