系統接口權限設計

 

一、     前言

隨着時代發展和技術的進步，系統也在不斷發展和完善，從原有的單一的企業開發使用，到現在的跨平台、多系統、多用戶的集成對接開發模式。系統的發展也是非常迅速的，很多設計和對接模式也需要不斷的改僅和升級。現在的一個系統往往不單單是某一個團隊開發、使用，而是多個團隊同時開發不同的模塊，以及現在的系統往往是平台化的，一些第三方在使用對接的時候，就需要考慮到每個對接者是否具有相應的權限。每個對接者可能所具有的的權限都是不同的且權限的有效期也都是不盡相同，這就需要一個接口訪問的權限分配和校驗模塊。

二、     平台設計

1. 數據庫設計

第三方應用接入表t_app_regist

字段名	類型	字段長度	字段釋義	是否必填
id	int	11	主鍵	是
appcode	varchar	32	微應用編號	否
appname	varchar	32	微應用名稱	否
icon	int	11	微應用圖標	否
appdes	varchar	500	微應用描述	否
apptype	char	1	應用分類，0：系統應用 1：微應用	否
appvstype	char	1	應用類型：H為H5；A為安卓；I為IOS	否
appimgs	varchar	500	應用截圖	否
appkey	varchar	50	給予第三方的應用標識	否
appsecret	varchar	50	用於鑒權api使用的傳輸加密秘鑰	否
owner	varchar	32	微應用歸屬單位	否
apparea	varchar	32	應用所屬地域	否
appind	varchar	32	應用所屬行業	否
auditstatus	char	1	審核狀態：W待審核；Y審核通過；N未通過	否
createtime	datetime	0	創建時間	否
updatetime	datetime	0	更新時間	否
creator	varchar	32	創建者	否
updator	varchar	32	更新着	否

　　　　　　第三方對接接入需先在我們的系統中創建一個應用，系統會自動生成應用的授權信息，包括appcode、appkey、appsecret,這是應用授權所必需的信息。

 

 

微應用授權表t_app_license

字段名	類型	字段長度	字段釋義	是否必填
id	int	11	主鍵	是
appkey	varchar	32	應用的唯一標識key	否
appsecret	varchar	32	應用的密鑰	否
jsapiticket	varchar	32	前端鑒權的jsapiticket	否
accesstoken	varchar	32	令牌	否
validperiod	int	11	有效期（單位秒）	否
createtime	datetime	0	創建時間	否
updatetime	datetime	0	更新時間	否

　　　　　　微應用授權表是給所有的第三方的微應用生成jsapiticket和accesstoken，jsapiticket用於前端的鑒權，accesstoken是第三方在請求系統的接口及相應能力的時候需傳遞的參數，系統會檢驗此accesstoken是否存在及有效，若accesstoken檢驗成功則放行，檢驗失敗則攔截請求。

2. 邏輯設計

　　　　 

 

 

3. 接口訪問設計

　　　　　

 

三、     平台自身系統對接

由於目前系統都是向前后端分離的大趨勢發展，當前后端分離的系統，前端在請求后端服務時，一般有兩種權限管控方式。

1. 直接訪問：若前后端系統部署在同一服務器，或者同一個網段（內網），以及可以通過設置IP白名單訪形式等的其他軟硬件安全管控場景下，請求接口以及平台資源時可以不要求使用accesstoken令牌，可直接訪問。
2. accesstoken授權校驗：若前后端系統並非部署在同一服務器，或者不在同一個網段（內網），以及沒有設置IP白名單等其他軟硬件管控手段，可以理解為和第三方對接無明顯差異的情況下，可以考慮通過accesstoken的授權校驗來對接前后端系統。

備注：不僅是前后端，平台自身不同的業務系統之間的對接也可參考上述的對接方式進行對接，這樣可以保證系統的安全穩定、免受其他未知系統的攻擊。

四、     第三方對接

出於安全考慮，第三方對接平台需要驗證身份的合法性，現在市面上的開放平台也基本上都是這樣的一個流程：先在平台上注冊一個應用，拿到appcode、appkey、appsecret等參數，通過這幾個參數獲取開放平台的accesstoken令牌，用accesstoken令牌來和開放平台進行數據交互，例如：釘釘和微信。當然這里對接模式也是這樣的一個流程。

一般情況下獲取的accesstoken令牌都是有一個有效期的，這里的有效期是7200秒，所以第三方需要在令牌失效前重新獲取新的accesstoken進行保存，在第三方進行接口請求及數據交換時，需要帶上這個accesstoken，平台會校驗后判斷是否放行或者攔截請求。

五、     小結

此系統接口權限管控設計是參考釘釘及微信的開放平台設計的，能夠保證很多平台系統在前后端對接、與第三方對接時的安全穩定，免受未知系統的攻擊。這里僅對系統是否能夠與平台接口對接的管控，如果需要對每一個具體的接口一一進行權限分配和管控的話，可以再新增“接口訪問表”、“接口訪問-授權關聯表”，這樣即可實現每個accesstoken關聯某些特定授權的接口資源，實現接口細化權限管控。