API網關設計(一)之Token多平臺身份認證方案
隨着4g的發展示現在早已不是當年的web登錄單一模式,而不久5g的到來又會帶來無人車等其餘設備的接入。因此爲了應對未來的時代的變化,一個好的多平臺認證登錄方案是切實所需。
概述
今天我們面對移動互聯網的發展,系統通常是多個客戶端對應一個服務端。
客戶端統一經過F5或者Nginx代理轉發到API網關,最後發送到服務API。
以下圖架構圖所示
![avatar avatar](http://static.javashuo.com/static/loading.gif)
這個過程中就存在多個很明顯須要作的事,以下列表git
- 身份認證(登錄以及會話級用戶認證)
- 權限認證(固然是認證用戶身份以後,確認是否有權限調用API)
- 調用頻率控制(限流算法如計數,滑動窗口,漏桶,令牌桶)
- 負載算法(如權重,均衡,例外再好比灰度發佈都是同一個思路)
而我們今天主要講的了就是身份認證這一塊具體怎麼設計Token,在前一篇文章中已經描述過總體的登錄邏輯,不清楚的同窗能夠看一下。github
Token設計
現在的系統不可能存在一個token走到底打通全部系統,爲啥這麼說?
因爲不一樣的客戶端,會存在不一樣的認證場景。
我們具體看一下分析過程web
認證場景
客戶端如下幾點用戶認證的場景算法
- 移動端登錄,會話API調用
- web端登錄,會話API調用
- 移動端掃碼登錄web(如微信掃碼)
- 移動端受權登錄(如微信受權)
而經過客戶端的認證場景,我們又能具體推理出功能級別的具體場景以下api
- 客戶端記住用戶密碼免登錄認證
- API調用的會話級別認證
- 移動端已登錄受權web端免密登錄
Token設計要點
經過上面的認證場景才能不可貴出以下結論安全
- 多層級Token
- Token之間可向下受權
- Token使用頻率
- Token失效時間
級別劃分 1~3 分別爲低中高微信
Token |
名稱 |
級別 |
使用頻率 |
有效期 |
保密級別 |
變化成本 |
webtoken |
web端token |
3(持久化) |
1 |
>=1天 |
3 |
3 |
mobiletoken |
mobile端token |
3(持久化) |
1 |
>=1天 |
3 |
3 |
sessiontoken |
會話token |
2(會話級) |
3 |
分鐘級別 |
3 |
1 |
accesstoken |
API認證token |
1(短暫認證) |
3 |
秒級 |
2 |
1 |
再具體看一張token層級架構圖
![avatar avatar](http://static.javashuo.com/static/loading.gif)
爲啥要將token分這麼多類型了?
我們先根據上圖捋一下思路具體以下幾步cookie
- 用戶名和密碼認證獲取webtoken或者mobiletoken
- 用戶登原先存在webtoken或mobiletoken能夠拿到sessiontoken
- 經過sessiontoken能夠去拿去短暫的accesstoken
- 經過accesstoken能夠調用API
層級token優點
經過上面我們能夠看出來最終調用api是經過accesstoken,那麼我們爲何還須要設計
多層token了?主要有如下幾個緣由session
- 不一樣的客戶端對於免登錄的要求是不同的,好比web端輸入一個用戶名密碼或者經過手機接受一個驗證碼是很方便的事情,因此token時間不會存放特別長。可是對於移動端來講,對於用戶體驗比較好的狀況就是隨時隨刻都是登錄狀態,輸入一次密碼最好能用個大半年。
- 安全性考慮這一點是因爲第點的緣由致使,因爲webtoken或者mobiletoken存儲在客戶端的時間較長。若是調用頻率很高,及其容易致使被抓包獲取到黑客手中。所以引入了會話級別token經過持久化在客戶端的mobiletoken等去獲取。會話token的特色就是調用頻率高,失效時間快,就算被被人拿到了不會形成奔潰式的問題出現。
- 統一後臺api調用控制,accesstoken的存在是真正調用api的token,也是經過sessiontoken獲取。爲了避免同客戶端統一接入api實現,若是acesstoken不統一。那代碼層面實現又所有耦合到了一塊兒,若是是統一的就能夠將代碼抽出來一個層級放在網關統一實現。
綜合上面能夠總結出來的優點有以下幾點架構
- 解耦系統 (accesstoken網關以後的系統能夠任意部署)
- 提升系統擴展性(能夠接入不一樣性質的客戶端)
- 層級清楚便於維護(token分層代碼,便於獨立維護)
token安全控制
首先我們得明白一個道理對於任何登錄系統來講根本就不存在百分百的安全,惟一能夠作到的就是提升破解成本。具體的安全控制方法個人總結以下
- 使用https哪怕被抓包看到的也是加密數據,除非客戶端和服務端都被黑了。這尼瑪這人這麼優秀,乾點啥很差。。。
- 根據業務要求設置不一樣token失效時間,token失效時間越短越安全,用戶體驗也會有所下滑
- token能夠根據動態加密算法以及密碼定時更新,而後經過cookie打回客戶端
- 移動端能夠獲取設備id以及ip,當短期內出現同一帳號不一樣設備請求,及時失效全部token,或者發出告警短信給用戶,權限級別較高的操做禁用。
- 移動端加入人臉或者指紋識別
完整架構圖
![avatar avatar](http://static.javashuo.com/static/loading.gif)
歡迎掃碼關注公衆號繼續討論
![avatar avatar](http://static.javashuo.com/static/loading.gif)