背景
前段時間做數據平臺的鑑權，想了很多種方案，但最後還是選擇了JWT來進行身份驗證與權限控制。
期間考慮過傳統的user/passwd -> session_id，也考慮了隨機生成Token，後端再來維護一套權限控制邏輯，甚至打算使用類似kebos這種來實現安全通信，但對於數據平臺這種業務，感覺權限控制這裏這些方案都有點重量級了。
內網環境相對是安全的，對內網進行混雜模式抓包會被安全的人抓到，所以身份僞造這個問題其實不是那麼嚴重。使用證書這種方式系統消耗又很大，資源利用率不高。
思來想去，發現還是得從我們最初的目的出發，想明白客戶到底想要什麼，而不是爲了高大上而選擇難度最高的方案。
我們需要什麼
我們要的很簡單，區分接口調用方，對接口添加權限控制，無權限、無Token的調用返回400錯誤，同時對所有請求的入參、出參都進行記錄。
簡單點就是，我們需要知道 是否有權限的 誰 在什麼時候 調用了 什麼接口，入參是什麼，得到了什麼返回。
這就很簡單了。
跟鑑權有關的，我們只需要區分出是誰跟是否有權限即可。
結合內網環境相對安全，可提供固定Token、接口訪問頻繁，鑑權最好與數據庫分離，實現橫向擴容等原因，JWT便從衆多方案中脫穎而出。
使用JWT的原因
- 鑑權邏輯無需訪問數據庫，任何情況下都不會擊穿緩存打到數據庫影響業務；
- 與數據庫解耦，橫向擴容性佳，Token發放、驗證都可以脫離數據庫
- 同樣是提供Token，但JWT中可附帶允許的權限/操作，業務無需實現複雜的權限控制邏輯，只需要判斷Token中是否有對應權限即可；
- 數據平臺主要的功能就是提供數據訪問接口與數據上傳接口，沒有傳統Web應用的那種上下文關係。過重的鑑權邏輯不太符合當前業務特點；
- 使用多版本私鑰，通過更改固定版本簽名所用的私鑰可以批量廢除發出的Token；使用Redis等緩存後亦可實現對單一Token的回收
- 業務只有上傳/拉取這兩個操作，只需要區分當前用戶是誰即可
結論：什麼時候使用JWT比較合適？
- 沒有上下文的環境（有其實也可以，但這樣他的優勢就沒那麼大）
- 只需要區分用戶
- 不想讓鑑權用到的數據庫成爲可能的瓶頸
- 業務行爲簡單，只提供curd這類功能
- 可以實現自動化的Token發放，並且網絡環境相對安全