開放平臺：權限校驗auth框架

背景：
門戶網站分爲我的用戶，我的開發者，機構用戶，頁面不一樣的操做須要特定的用戶才能操做。如api申請，密鑰下載只有機構用戶纔可操做，重置密碼須要登陸後纔可操做。
管理端分爲系統管理員，開放平臺管理員，銀行管理員，不一樣的角色具備不一樣的權限，
權限按資源劃分
服務間調用也須要進行保護，如調用發送短信接口，調用發送站內信的接口，不能不加限制地對外暴露。
所以須要以接口爲粒度進行統一鑑權，在接口處註明須要的權限，需註明請求來源：門戶，管理端，服務間調用。若是是門戶或管理端，還可標註須要的角色或資源。可校驗多個來源。

技術設計：
對於門戶網站和管理端，用戶登陸成功後生成包含用戶信息（userId）的JWT token，前端保存在vuex中。每次操做請求將token放入front- Authorization和manage- Authorization以供服務端校驗。其中front和manage表明源自門戶和管理端。
服務間調用發送http請求時，在header處添加service- Authorization，值爲有效期爲30s的JWT token，service表明源自服務間調用。
經過註解標記須要校驗的接口，並添加所須要的請求來源和資源名稱，若是匹配則放行，不然報無權限請求。
利用攔截器對請求進行切面操做，若是該方法加@AuthRequest註解則尋找header，若包含front- Authorization，manage- Authorization或service- Authorization，則對該token進行JWT校驗。其中front和service校驗較爲簡單，直接校驗即刻，manage校驗token成功後還需從token中獲取userId，經過服務間調用判斷該用戶是否擁有該資源。若是門戶和管理端校驗成功，從token中取出userId，role放入attribute，供接口使用。
引入該包還爲feign調用添加service- Authorization的header

流程圖：

說明：
門戶網站，管理端和服務間調用一般經過gateway，可是統一校驗不在gateway，而在各自服務，緣由以下：

• 更安全，有的請求可能直接經過服務調用，而非gateway，所以須要在服務的接口層面作校驗
• 配置更方便

權限是一種安全策略，用戶只可訪問被受權的資源。所以須要採起策略控制用戶的行爲。
涉及到如下幾個方面：

• 用戶認證：如何校驗用戶的合法性並保存用戶的登陸狀態
• 權限校驗：如何保護服務端的接口，用戶是否有資格調用接口，包括：從web端發送來的請求，服務間的調用
• 權限管理：如何給用戶分配資源，RBAC

權限功能在服務從單體轉向微服務架構面臨以下挑戰：

• 如何保證用戶的登陸狀態。單體中可將登陸狀態保存至session中，但微服務中應用被分爲多個服務，服務應該是無狀態的，不能保存用戶的登陸狀態；
• 微服務拆分後，調用來源不只僅是客戶端，還有來自服務間的調用，所以須要全面考慮多個來源的調用
• 權限校驗功能不能散落在各個服務中，應統一處理
• 先後端分離，只作數據交互，前端路由/按鈕資源化，如何管理資源

微服務應用的權限功能應具備特色：

• 與業務系統解耦，功能獨立，職責單一
• 保證可用性，當權限服務不可用時，不能改變業務系統的行爲
• 保證性能，避免因鑑權致使響應時間增長
• 對已有代碼侵入性小，改造方便

現有的解決方案：

• Oauth2：受權框架
• JWT token：認證協議
• Security：有些重
• Shiro：可作權限認證，密碼加密等，但不太適用於微服務環境，SecurityManager
• 分佈式session：將username，session id做爲key存儲至分佈式存儲中，用戶訪問微服務時，能夠從分佈式存儲中斷定。保證了高可用和可擴展。缺點是存在安全隱患。

通過比較，決定自行研發一套權限校驗框架，包括：

• JWT Token進行用戶認證及鑑權
• RBAC權限分配體系

架構圖：

Token設計
一段字符串，用戶登錄成功後服務端生成返回至客戶端保存，做爲後續已登錄狀態的憑證。
優勢：

• 每次請求將token放入header中，可避免CSRF
• 自身無狀態，可在服務間共享，服務端不保存token仍可校驗其合法性。（不用在服務端保存k-v）

應具備如下特色：

• 一個Token就是一些信息的集合，包含如username，phone-number，資源等信息；
• 可做爲用戶認證的憑據。由於token是被簽名的，服務端可對cookie和HTTP Authrorization Header進行Token信息的檢查，若是校驗合法，可認爲該請求是安全的
• Token有必定的有效期，保證安全性
• Token在有效期內有效，沒法經過自身失效，除非經過放入redis輔助校驗

過時策略：
Token過時後應進行續簽，而不是跳轉到登錄畫面，形成糟糕的用戶體驗。Token失效時間過長會存在安全性隱患，太短會形成頻繁的refresh token。好的體驗應該是在用戶無感知的狀況下進行token刷新。

• 服務端保存token狀態，用戶每次操做均刷新token有效期，可作到一段時間沒有操做即登出，但這種方案對內存壓力較大，每次操做都要訪問，失去了token可被驗證的便捷性
• refresh token：用戶登錄成功後返回token及refresh token，token過時後經過refresh token續簽token，token有效期短而refresh token有效期長，refresh token失效後認爲登出。可實現每次登錄保存登陸狀態必定時間。能夠避免對內存的頻繁讀寫

什麼時候refresh token：

• 前端創建定時任務每隔必定時間經過refresh token獲取新token
• 收到響應後，若是響應爲token過時，經過refresh token獲取新token，再次發送請求，若是refresh token過時，說明需從新登陸