系统接口权限设计

 

一、     前言

随着时代发展和技术的进步，系统也在不断发展和完善，从原有的单一的企业开发使用，到现在的跨平台、多系统、多用户的集成对接开发模式。系统的发展也是非常迅速的，很多设计和对接模式也需要不断的改仅和升级。现在的一个系统往往不单单是某一个团队开发、使用，而是多个团队同时开发不同的模块，以及现在的系统往往是平台化的，一些第三方在使用对接的时候，就需要考虑到每个对接者是否具有相应的权限。每个对接者可能所具有的的权限都是不同的且权限的有效期也都是不尽相同，这就需要一个接口访问的权限分配和校验模块。

二、     平台设计

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关联某些特定授权的接口资源，实现接口细化权限管控。