一种接口调用的鉴权方法、装置、设备及存储介质与流程

本发明涉及计算机网络技术领域，尤其涉及一种接口调用的鉴权方法、装置、设备及存储介质。

背景技术：

随着移动互联网的不断深入发展，越来越多的公司和企业逐渐开始把项目迁移到微服务架构上。在目前的微服务架构中，通常前后端是分离的，前端可以对后端接口进行调用。当用户发起对后端接口的调用请求时，基于安全考虑，需要首先判断该用户是否具备调用该接口的权限。

目前，针对接口调用权限的鉴权方法，主要根据服务端存储的用户密钥以及api权限列表，来判断用户对其访问的api是否有权限。此外，该过程还需对用户密钥进行签名验证或加密算法认证。

但是，随着业务能力的变化，当新增或删除接口时，现有的鉴权方法需要对服务端存储的全部用户密钥以及api权限列表进行配置，效率较低。

技术实现要素：

本申请实施例提供了一种接口调用的鉴权方法、装置、设备及存储介质，用于解决随着业务能力的变化，当新增或删除接口时，现有的鉴权方法需要对服务端存储的全部用户密钥以及api权限列表进行配置，效率较低的问题，可以实现接口调用鉴权和用户权限管理相结合，有效提升鉴权效率。

为解决上述技术问题，本说明书实施例是这样实现的：

第一方面，提出了一种接口调用的鉴权方法，应用于用户中心服务器，包括：

接收应用程序接口api网关发送的鉴权请求，所述鉴权请求包括待调用的api的信息及待调用所述api的用户的用户信息；

根据所述待调用的api的信息，通过查询权限管理系统中预先存储的api与api提供功能的菜单之间的映射关系，确定所述待调用的api提供功能的菜单；

根据所述待调用的api提供功能的菜单，通过查询所述权限管理系统中预先存储的菜单与可访问所述菜单的角色之间的映射关系，确定与所述待调用的api提供功能的菜单相映射的角色，作为具备所述待调用的api的调用权限的角色；

根据所述具备所述待调用的api的调用权限的角色，通过查询所述权限管理系统中预先存储的用户信息与角色之间的映射关系，确定与所述待调用的api的调用权限的角色相映射的用户信息，作为具备所述待调用的api的调用权限的用户信息；

根据所述待调用所述api的用户的用户信息是否与所述具备所述待调用的api的调用权限的用户信息相匹配，判断所述待调用所述api的用户是否具备所述待调用的api的调用权限。

第二方面，提出了一种接口调用的鉴权方法，应用于api网关，包括：

拦截终端向用户中心服务器发送的api访问请求，所述访问请求包括待调用的api的信息及令牌；

对所述令牌进行解析，以获得待调用所述api的用户的用户信息；

根据所述待调用的api的信息及所述用户信息，生成包含所述待调用的api的信息及所述用户信息的鉴权请求发送至所述用户中心服务器；

接收所述用户中心服务器返回的鉴权结果；所述鉴权结果，由所述用户中心服务器基于如权利要求1所述的方法确定；

若所述鉴权结果为鉴权通过，则将所述api访问请求转发至所述待调用的api。

第三方面，提出了一种接口调用的鉴权装置，包括：

鉴权请求接收单元，用于接收应用程序接口api网关发送的鉴权请求，所述鉴权请求包括待调用的api的信息及待调用所述api的用户的用户信息；

菜单确定单元，用于根据所述待调用的api的信息，通过查询权限管理系统中预先存储的api与所述api提供功能的菜单之间的映射关系，确定所述待调用的api提供功能的菜单；

角色确定单元，用于根据所述待调用的api提供功能的菜单，通过查询所述权限管理系统中预先存储的菜单与可访问所述菜单的角色之间的映射关系，确定与所述待调用的api提供功能的菜单相映射的角色，作为具备所述待调用的api的调用权限的角色；

有权限用户信息确定单元，用于根据所述具备所述待调用的api的调用权限的角色，通过查询所述权限管理系统中预先存储的用户信息与角色之间的映射关系，确定具备所述待调用的api的调用权限的用户信息；

鉴权单元，用于根据所述待调用所述api的用户的用户信息是否与所述具备所述待调用的api的调用权限的用户信息相匹配，判断所述待调用所述api的用户是否具备所述待调用的api的调用权限。

第四方面，提出了一种接口调用的鉴权装置，包括：

访问请求拦截单元，用于拦截终端向用户中心服务器发送的api访问请求，所述访问请求包括待调用的api的信息及令牌；

令牌解析单元，用于对所述令牌进行解析，以获得待调用所述api的用户的用户信息；

鉴权请求生成单元，用于根据所述待调用的api的信息及所述用户信息，生成包含所述待调用的api的信息及所述用户信息的鉴权请求发送至所述用户中心服务器；

鉴权结果接收单元，用于接收所述用户中心服务器返回的鉴权结果；所述鉴权结果，由所述用户中心服务器基于如权利要求1所述的方法确定；

转发单元，用于若所述鉴权结果为鉴权通过，则将所述api访问请求转发至所述待调用的api。

第五方面，提出了一种接口调用的鉴权系统，包括用户中心服务器以及api网关，其中：

所述用户中心服务器，用于执行如权利要求1至3中任一项所述的方法；

所述api网关，用于执行如权利要求4、5中任一项所述的方法。

第六方面，提出了一种电子设备，应用于应用服务端，该电子设备包括：

处理器；以及

被安排成存储计算机可执行指令的存储器，所述可执行指令在被执行时使所述处理器执行以下操作：

接收应用程序接口api网关发送的鉴权请求，所述鉴权请求包括待调用的api的信息及待调用所述api的用户的用户信息；

根据所述待调用的api的信息，通过查询权限管理系统中预先存储的api与api提供功能的菜单之间的映射关系，确定所述待调用的api提供功能的菜单；

根据所述待调用的api提供功能的菜单，通过查询所述权限管理系统中预先存储的菜单与可访问所述菜单的角色之间的映射关系，确定与所述待调用的api提供功能的菜单相映射的角色，作为具备所述待调用的api的调用权限的角色；

根据所述具备所述待调用的api的调用权限的角色，通过查询所述权限管理系统中预先存储的用户信息与角色之间的映射关系，确定与所述待调用的api的调用权限的角色相映射的用户信息，作为具备所述待调用的api的调用权限的用户信息；

根据所述待调用所述api的用户的用户信息是否与所述具备所述待调用的api的调用权限的用户信息相匹配，判断所述待调用所述api的用户是否具备所述待调用的api的调用权限。

第七方面，提出了一种计算机可读存储介质，所述计算机可读存储介质存储一个或多个程序，所述一个或多个程序当被包括多个应用程序的电子设备执行时，使得所述电子设备执行以下操作：

接收应用程序接口api网关发送的鉴权请求，所述鉴权请求包括待调用的api的信息及待调用所述api的用户的用户信息；

根据所述待调用的api的信息，通过查询权限管理系统中预先存储的api与api提供功能的菜单之间的映射关系，确定所述待调用的api提供功能的菜单；

根据所述待调用的api提供功能的菜单，通过查询所述权限管理系统中预先存储的菜单与可访问所述菜单的角色之间的映射关系，确定与所述待调用的api提供功能的菜单相映射的角色，作为具备所述待调用的api的调用权限的角色；

根据所述具备所述待调用的api的调用权限的角色，通过查询所述权限管理系统中预先存储的用户信息与角色之间的映射关系，确定与所述待调用的api的调用权限的角色相映射的用户信息，作为具备所述待调用的api的调用权限的用户信息；

根据所述待调用所述api的用户的用户信息是否与所述具备所述待调用的api的调用权限的用户信息相匹配，判断所述待调用所述api的用户是否具备所述待调用的api的调用权限。

由以上实施例提供的技术方案可见，通过查询权限管理系统中预先存储的api与api提供功能的菜单、菜单与可访问所述菜单的角色以及用户信息与角色之间的映射关系，可以查询出具备所述待调用的api的调用权限的用户信息的集合，在进行用户对待调用api的鉴权时，根据用户信息是否属于该集合即可快速判定该用户是否具备待调用的api的调用权限。本方案将api鉴权和用户权限管理进行了结合，简化了鉴权过程。

另外，本方案中如新增或删除接口，仅需在权限管理系统中新增或删除api与api提供功能的菜单之间的映射关系，不需一一修改用户以及api权限列表，提升了效率。

附图说明

此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：

图1是本说明书第一实施方式提供的接口调用的鉴权方法的流程示意图。

图2是本说明书第一实施方式提供的权限控制系统示意图。

图3是本说明书第二实施方式提供的接口调用的鉴权方法的流程示意图。

图4是本说明书第三实施方式提供的接口调用的鉴权方法的流程示意图。

图5是本说明书第四实施方式提供的接口调用的鉴权装置的模块结构示意图。

图6是本说明书第五实施方式提供的接口调用的鉴权装置的模块结构示意图。

图7是本说明书第六实施方式提供的电子设备的结构示意图。

具体实施方式

为使本申请的目的、技术方案和优点更加清楚，下面将结合本申请具体实施例及相应的附图对本申请技术方案进行清楚、完整地描述。显然，所描述的实施例仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

api(applicationprogramminginterface，应用程序编程接口)是一些预先定义的函数，目的是提供应用程序与开发人员基于某软件或硬件得以访问一组例程的能力，而又无需访问源码，或理解内部工作机制的细节。api调用权限的鉴权一般通过签名验证或加密算法认证校验api访问权限。服务端存有一张用户权限表，这个数据表主要用来记录用户的keysecret(密钥)以及对应的有调用权限的api权限列表，通过查询该表即可检查这个用户对访问的api是否有权限，如果有权限则对签名进行验证，签名验证通过后，判定鉴权通过。但是，随着业务能力的变化，当新增或删除接口时，现有的鉴权方法需要对服务端存储的全部用户密钥以及api权限列表进行配置，效率较低。

为了解决随着业务能力的变化，当新增或删除接口时，现有的鉴权方法需要对服务端存储的全部用户密钥以及api权限列表进行配置，效率较低的问题，本说明书的第一实施方式涉及一种接口调用的鉴权方法，如图1所示，包括以下步骤：

s101：接收应用程序接口api网关发送的鉴权请求，鉴权请求包括待调用的api的信息及待调用api的用户的用户信息；

s102：根据待调用的api的信息，通过查询权限管理系统中预先存储的api与api提供功能的菜单之间的映射关系，确定待调用的api提供功能的菜单；

s103：根据待调用的api提供功能的菜单，通过查询权限管理系统中预先存储的菜单与可访问菜单的角色之间的映射关系，确定与待调用的api提供功能的菜单相映射的角色，作为具备待调用的api的调用权限的角色；

s104：根据具备待调用的api的调用权限的角色，通过查询权限管理系统中预先存储的用户信息与角色之间的映射关系，确定与待调用的api的调用权限的角色相映射的用户信息，作为具备待调用的api的调用权限的用户信息；

s105：根据待调用api的用户的用户信息是否与具备待调用的api的调用权限的用户信息相匹配，判断待调用api的用户是否具备待调用的api的调用权限。

在步骤s101中，用户中心服务器接收api网关发送的鉴权请求，该鉴权请求包括待调用的api的信息，如请求访问的api的路径、请求的类型，以及待调用api的用户的用户信息，如用户主键、用户编码、用户姓名、归属机构等。

在步骤s102中，如图2所示，权限管理系统中预先存储有api与api提供功能的菜单之间的映射关系、菜单与可访问菜单的角色之间的映射关系以及用户信息与角色之间的映射关系。其中，菜单是用户访问的入口，菜单分为多级，如一级菜单，二级菜单，菜单形式可以为按钮或tab标签页等。权限管理系统定义实现各项菜单的功能所需要调用的api接口，如一级菜单“查询”下属的二级菜单“查询用户”关联了finduserapi，当用户点击“查询用户”按钮时，由其关联的finduserapi提供服务。

权限管理系统还定义对接系统的角色，指定角色具有的菜单权限，由于定义实现各项菜单的功能所需要调用的api接口，从而使得角色和具体的api进行关联。

作为一个例子，角色“总公司用户管理岗”，该角色关联菜单包括一级菜单用户管理，二级菜单用户信息管理、用户账户管理。其中，二级菜单关联的api路径如/微服务名/usergradeapi/finduser、/微服务名/prpdmonopolyconfig/getutiiuser。此时，“总公司用户管理岗”角色就和api接口finduser和getutiluser进行了关联。

可以理解，当用户配置了角色时，就建立了用户信息与角色的映射关系，，继而用户信息和api之间的对应关系就生成了。当用户不再配置某角色或新配置某角色时，在权限管理系统中，用户信息和api之间的对应关系也会随之更新。当新增或删除某个api接口时，只需在api与api提供功能的菜单之间的映射关系中进行修改，用户信息和api之间的对应关系也会随之更新。

在进行鉴权时，根据鉴权请求中包括的待调用的api的路径和类型，在权限管理系统中进行查询，由于权限管理系统中预先存储有api与api提供功能的菜单之间的映射关系，即可确定待调用的api可以提供功能的菜单。

在步骤s103中，根据已经确定的待调用的api可以提供功能的菜单，在权限管理系统中进行查询，如前文所述，由于权限管理系统中预先存储有菜单与可访问菜单的角色之间的映射关系，即可与待调用的api提供功能的菜单相映射的角色，该角色即为作为具备待调用的api的调用权限的角色。

在步骤s104中，根据具备待调用的api的调用权限的角色，通过查询权限管理系统中预先存储的用户信息与角色之间的映射关系，确定与待调用的api的调用权限的角色相映射的用户信息。如图2中，待调用的api为api-4，根据api与api提供功能的菜单之间的映射关系可知，api-4对应的菜单为菜单3，根据菜单与可访问菜单的角色之间的映射关系可知，菜单3对应的角色为角色1和角色2，即角色1和角色2具备操作菜单3的权限，角色1和角色2对应的用户为用户1、用户2、用户3以及用户4，那么，api-4对应的用户信息即为用户1、用户2、用户3以及用户4，这些用户具备调用api-4的权限。

在步骤s105中，将待调用api的用户的用户信息与前述确定的具备待调用的api的调用权限的用户信息进行匹配，如待调用api-4的用户为用户1，用户1和前述确定的用户集合相匹配，即用户1属于该集合，则用户1具备调用api-4的权限；如待调用api-4的用户为用户5，用户5不属于用户1、用户2、用户3以及用户4组成的集合，则用户5不具备调用api-4的权限。

利用本实施例在对接口调用进行鉴权时，通过查询权限管理系统中预先存储的api与api提供功能的菜单、菜单与可访问所述菜单的角色以及用户信息与角色之间的映射关系，可以查询出具备所述待调用的api的调用权限的用户信息的集合，在进行用户对待调用api的鉴权时，根据用户信息是否属于该集合即可快速判定该用户是否具备待调用的api的调用权限。本方案将api鉴权和用户权限管理进行了结合，简化了鉴权过程。另外，本方案中如新增或删除接口，仅需在权限管理系统中新增或删除api与api提供功能的菜单之间的映射关系，不需一一修改用户以及api权限列表，提升了效率。

作为一个例子，在根据待调用的api的信息，通过查询权限管理系统中预先存储的api与api提供功能的菜单之间的映射关系,确定待调用的api提供功能的菜单之前，可以首先在redis缓存中进行查询，redis缓存中存储有查询权限管理系统确定的api的信息与具备api的调用权限的用户信息的映射关系，如经查询确定接口api-4对应的用户信息为用户1、用户2、用户3以及用户4，该映射关系存储在redis缓存中，当接收到鉴权请求后，可以首先在缓存中查询是否存在接口api-4对应的用户信息，如存在，则进一步判断调用api-4的用户是否为用户1、用户2、用户3以及用户4，如是，则鉴权通过，如不是，则鉴权不通过。如在缓存中没有查询到接口api-4的信息，则表示此次是首次对接口api-4的鉴权，执行根据待调用的api的信息，通过查询权限管理系统中预先存储的api与api提供功能的菜单之间的映射关系，确定待调用的api提供功能的菜单。

可以理解，针对首次进行鉴权的api，在权限管理系统中通过查询预先存储的映射关系，可以确定具备待调用的api的调用权限的用户信息，将该api和对应的用户信息存储在redis缓存中，在对该api进行非首次鉴权时，可首先在redis缓存中直接查询到具备待调用的api的调用权限的用户信息，可以有效简化鉴权过程，提升鉴权效率。

本说明书的第二实施方式涉及一种接口调用的鉴权方法，应用于api网关，如图2所示，包括：

s201：拦截终端向用户中心服务器发送的api访问请求，访问请求包括待调用的api的信息及令牌；

s202：对令牌进行解析，以获得待调用api的用户的用户信息；

s203：根据待调用的api的信息及用户信息，生成包含待调用的api的信息及用户信息的鉴权请求发送至用户中心服务器；

s204：接收用户中心服务器返回的鉴权结果；

s205：若鉴权结果为鉴权通过，则将api访问请求转发至待调用的api。

在微服务体系架构中，将应用程序划分为几个低耦合的服务(称为微服务)，每个服务都有其独特的功能。api网关可以充当使用这些微服务的客户端的中央接口，客户端不必访问数十个单独的服务，而是可以向api网关发送单个请求，api网关来聚集微服务。作为将客户端与服务连接起来的中央接口，api网关不仅可以通过路由分发客户的请求，还可以处理重要的安全和管理任务，如身份验证，输入验证，指标收集和响应转换。

在步骤s201中，当用户操作了菜单等功能按钮时，即会触发对服务该菜单功能的api的访问，终端生成对api的访问请求，访问请求中包括待调用的api的信息，如api和请求类型，以及令牌。令牌为用户登录终端系统时，由平台发放的，令牌中包括用户主键等，用户进行功能访问时，均会携带认证平台发放的令牌，以便进行相应的身份认证。所有对api的访问请求会统一由api网关进行拦截。

在步骤s202中，api网关拦截到用户访问请求，获取请求报文头中的令牌，对令牌进行有效性校验。令牌的有效性验证通过后，对令牌进行解密解析，获取如用户主键、用户编码、用户姓名、归属机构等的用户信息。

在一个例子中，可以根据api的访问路径查看该访问的api是否在api网关进行了注册，如果未注册，那api网关直接丢弃该请求；如果已经注册，则可以继续进行后续的鉴权步骤。

在步骤s203中，api网关通过getway封装方法getwayrequsetcontext获取访问请求中的api请求路径和请求类型，通过组装用户主键、api路径、请求类型属性形成鉴权请求报文访问用户中心服务器的鉴权接口，即生成鉴权请求并发送至用户中心服务器。

在步骤s204中，用户中心服务器基于权限管理系统完成鉴权，生成鉴权结果发送至api网关，api网关接收该鉴权结果。

在步骤s205中，当鉴权结果为鉴权通过时，则将用户对待调用的api的访问请求转发至对应的api，当鉴权结果为鉴权不通过时，api网关根据返回状态false提示前台服务该用户无权限访问该接口api。

可以理解，api网关对api访问请求进行拦截，并进行了令牌有效性校验、令牌解析等操作，根据解析出的api信息和用户信息，生成鉴权请求发送至用户中心服务器，用户中心服务器通过权限管理系统完成鉴权，api网关根据鉴权结果完成对api访问请求的转发，该方案将api鉴权和用户权限管理进行了结合，简化了鉴权过程。

本说明书的第三实施方式涉及一种接口调用的鉴权方法，为一具体实施例，如图4所示，包括以下步骤：

(1)用户登录系统：

获取用户认证平台发放的token，token包括用户唯一标识。

(2)用户点击菜单按钮，触发api访问请求：

当用户操作具体功能按钮时，例如用户操作用户信息管理查询用户按钮，由于查询用户按钮关联了finduserapi，那么当用户点击查询用户按钮时，即触发了api访问/微服务名/usergradeapi/finduser。

(3)api网关拦截api访问请求：

所有api访问请求会统一由api网关进行拦截，用户进行功能访问时，均会携带认证平台发放的token，以便进行相应的身份认证。

(4)验证token是否有效：

api网关获取访问请求报文头中authorization属性的value值，即为token。随后根据拦截到的token进行token校验，校验token是否有效。

(5)解析token，获取用户信息：

token有效性验证通过后，通过工具类对token进行解密解析，获取如用户主键、用户编码、用户姓名、归属机构等用户信息。

(6)验证待访问api是否在api网关注册：

根据访问路径，如https://127.0.0.1:8080/网关名/微服务名/usergradeapi/finduser，查看该访问的api是否在api网关进行了注册，如果未注册，api网关直接进行请求拦截；如果已经注册，则继续进行后续鉴权步骤。

(7)组装用户信息及api路径，生成鉴权请求：

api网关通过getway封装方法getwayrequsetcontext获取请求方法中的请求路径，如，/微服务名/usergradeapi/finduser、请求类型：post。api网关程序通过组装用户主键、api路径、请求类型属性形成请求报文访问用户中心服务器的鉴权接口checkfrontpower接口。

(8)用户中心服务器接收鉴权请求，判断待鉴权api是否为首次请求：

在进行鉴权时，用户中心服务器运用redis缓存技术。当第一次接收对某一api的鉴权请求时，用户中心会根据api，通过用户对应的角色-角色包含的菜单信息-菜单关联的api，经过反向查询，查询出该api对应的所有用户信息，并通过set形式存储在redis缓存中。存储格式为用户主键、api，如此，缓存中存储了具备该api调用权限的所有用户信息；

当接收到api鉴权请求时，用户中心服务器通过在redis缓存中进行查询来判断该api是否是首次鉴权，如果在redis缓存中查到了该api，则表示为非首次鉴权，可直接从缓存中读取该api对应的用户信息，判断其中是否有当前访问用户，如有，则鉴权通过，如没有，则鉴权不通过，并将鉴权结果返回。

如果在缓存中查询不到该api，则会进入后续步骤。

(9)通过权限管理系统，查询具备待鉴权api调用权限的用户信息集合：

通过查询权限管理系统中预先存储的api与api提供功能的菜单之间的映射关系、菜单与可访问菜单的角色之间的映射关系、用户信息与角色之间的映射关系，确定与待调用的api的调用权限的角色相映射的用户信息，组成具备待调用的api的调用权限的用户信息的集合。

(10)判断待调用api的用户是否属于集合，进行鉴权：

判断待调用api的用户是否属于查询到的用户信息的集合，如属于，则用户中心服务器返回鉴权通过；如不属于，则用户中心服务器返回鉴权不通过。

本说明书的第四实施方式涉及一种接口调用的鉴权装置500，如图5所示，包含：鉴权请求接收单元501、菜单确定单元502、角色确定单元503、有权限用户信息确定单元504以及鉴权单元505，各模块功能详细说明如下：

鉴权请求接收单元501，用于接收应用程序接口api网关发送的鉴权请求，鉴权请求包括待调用的api的信息及待调用api的用户的用户信息；

菜单确定单元502，用于根据待调用的api的信息，通过查询权限管理系统中预先存储的api与api提供功能的菜单之间的映射关系，确定待调用的api提供功能的菜单；

角色确定单元503，用于根据待调用的api提供功能的菜单，通过查询权限管理系统中预先存储的菜单与可访问菜单的角色之间的映射关系，确定与待调用的api提供功能的菜单相映射的角色，作为具备待调用的api的调用权限的角色；

有权限用户信息确定单元504，用于根据具备待调用的api的调用权限的角色，通过查询权限管理系统中预先存储的用户信息与角色之间的映射关系，确定具备待调用的api的调用权限的用户信息；

鉴权单元405，用于根据待调用api的用户的用户信息是否与具备待调用的api的调用权限的用户信息相匹配，判断待调用api的用户是否具备待调用的api的调用权限。

进一步地，本发明实施方式提供的针对接口调用的鉴权装置500中，菜单确定单元502还包括redis缓存查询单元，用于：

根据待调用的api的信息，判断待调用的api的信息是否与redis缓存中存储的api的信息相匹配；

若判断结果为不匹配，根据待调用的api的信息，通过查询权限管理系统中预先存储的api与api提供功能的菜单之间的映射关系,确定待调用的api提供功能的菜单。

进一步地，本发明实施方式提供的针对接口调用的鉴权装置500中，菜单确定单元502还包括redis缓存查询判定单元，用于：

若判断结果为匹配，通过查询redis缓存中存储的api的信息与具备api的调用权限的用户信息的映射关系，确定具备待调用的api的调用权限的用户信息；

判断待调用api的用户的用户信息是否与具备待调用的api的调用权限的用户信息相匹配；

若判断结果为匹配，则判定待调用api的用户具备待调用的api的调用权限。

可以理解，针对首次进行鉴权的api，在权限管理系统中通过查询预先存储的映射关系，可以确定具备待调用的api的调用权限的用户信息，将该api和对应的用户信息存储在redis缓存中，在对该api进行非首次鉴权时，可首先在redis缓存中直接查询到具备待调用的api的调用权限的用户信息，可以有效简化鉴权过程，提升鉴权效率。

利用本实施例的装置在对接口调用进行鉴权时，通过查询权限管理系统中预先存储的api与api提供功能的菜单、菜单与可访问所述菜单的角色以及用户信息与角色之间的映射关系，可以查询出具备所述待调用的api的调用权限的用户信息的集合，在进行用户对待调用api的鉴权时，根据用户信息是否属于该集合即可快速判定该用户是否具备待调用的api的调用权限。本方案将api鉴权和用户权限管理进行了结合，简化了鉴权过程。另外，本方案中如新增或删除接口，仅需在权限管理系统中新增或删除api与api提供功能的菜单之间的映射关系，不需一一修改用户以及api权限列表，提升了效率。

本说明书的第五实施方式涉及一种接口调用的鉴权装置600，如图6所示，包含：访问请求拦截单元601、令牌解析单元602、鉴权请求生成单元603、鉴权结果接收单元604以及转发单元605，各模块功能详细说明如下：

访问请求拦截单元601，用于拦截终端向用户中心服务器发送的api访问请求，访问请求包括待调用的api的信息及令牌；

令牌解析单元602，用于对令牌进行解析，以获得待调用api的用户的用户信息；

鉴权请求生成单元603，用于根据待调用的api的信息及用户信息，生成包含待调用的api的信息及用户信息的鉴权请求发送至用户中心服务器；

鉴权结果接收单元604，用于接收用户中心服务器返回的鉴权结果；鉴权结果，由用户中心服务器基于如权利要求1的方法确定；

转发单元605，用于若鉴权结果为鉴权通过，则将api访问请求转发至待调用的api。

进一步地，本发明实施方式提供的针对接口调用的鉴权装置600中，鉴权请求生成单元603包括注册查询单元，用于：

根据待调用的api的信息，查询待调用的api是否在api网关注册；

若查询结果为是，则根据待调用的api的信息及用户信息，生成包含待调用的api的信息及用户信息的鉴权请求发送至用户中心服务器。

可以理解，api网关对api访问请求进行拦截，并进行了令牌有效性校验、令牌解析等操作，根据解析出的api信息和用户信息，生成鉴权请求发送至用户中心服务器，用户中心服务器通过权限管理系统完成鉴权，api网关根据鉴权结果完成对api访问请求的转发，该方案将api鉴权和用户权限管理进行了结合，简化了鉴权过程。

本说明书的第六实施方式涉及一种接口调用的鉴权系统，包括：用户中心服务器以及api网关，各模块功能详细说明如下：

用户中心服务器用于接收应用程序接口api网关发送的鉴权请求，鉴权请求包括待调用的api的信息及待调用api的用户的用户信息；根据待调用的api的信息，通过查询权限管理系统中预先存储的api与api提供功能的菜单之间的映射关系，确定待调用的api提供功能的菜单；根据待调用的api提供功能的菜单，通过查询权限管理系统中预先存储的菜单与可访问菜单的角色之间的映射关系，确定与待调用的api提供功能的菜单相映射的角色，作为具备待调用的api的调用权限的角色；根据具备待调用的api的调用权限的角色，通过查询权限管理系统中预先存储的用户信息与角色之间的映射关系，确定与待调用的api的调用权限的角色相映射的用户信息，作为具备待调用的api的调用权限的用户信息；根据待调用api的用户的用户信息是否与具备待调用的api的调用权限的用户信息相匹配，判断待调用api的用户是否具备待调用的api的调用权限。

api网关用于拦截终端向用户中心服务器发送的api访问请求，访问请求包括待调用的api的信息及令牌；对令牌进行解析，以获得待调用api的用户的用户信息；根据待调用的api的信息及用户信息，生成包含待调用的api的信息及用户信息的鉴权请求发送至用户中心服务器；接收用户中心服务器返回的鉴权结果；若鉴权结果为鉴权通过，则将api访问请求转发至待调用的api。

值得一提的是，本说明书的实施方式中所涉及到的各模块均为逻辑模块，在实际应用中，一个逻辑单元可以是一个物理单元，也可以是一个物理单元的一部分，还可以以多个物理单元的组合实现。此外，为了突出本发明的创新部分，以上实施方式中并没有将与解决本发明所提出的技术问题关系不太密切的单元引入，但这并不表明以上实施方式中不存在其它的单元。

本说明书的第七实施方式涉及一种电子设备，如图7所示。在硬件层面，电子设备包括处理器，可选地还包括内部总线、网络接口、存储器。其中，存储器可能包含内存，例如高速随机存取存储器(random-accessmemory，ram)，也可能还包括非易失性存储器(non-volatilememory)，例如至少1个磁盘存储器等。当然，该电子设备还可能包括其他业务所需要的硬件。

处理器、网络接口和存储器可以通过内部总线相互连接，该内部总线可以是isa(industrystandardarchitecture，工业标准体系结构)总线、pci(peripheralcomponentinterconnect，外设部件互连标准)总线或eisa(extendedindustrystandardarchitecture，扩展工业标准结构)总线等。所述总线可以分为地址总线、数据总线、控制总线等。为便于表示，图7仅用一个双向箭头表示，但并不表示仅有一根总线或一种类型的总线。

存储器，用于存放程序。具体地，程序可以包括程序代码，所述程序代码包括计算机操作指令。存储器可以包括内存和非易失性存储器，并向处理器提供指令和数据。

处理器从非易失性存储器中读取对应的计算机程序到内存中然后运行，在逻辑层面上形成接口调用的鉴权装置。处理器，执行存储器所存放的程序，并具体用于执行以下操作：

接收应用程序接口api网关发送的鉴权请求，鉴权请求包括待调用的api的信息及待调用api的用户的用户信息；

根据待调用的api的信息，通过查询权限管理系统中预先存储的api与api提供功能的菜单之间的映射关系，确定待调用的api提供功能的菜单；

根据待调用的api提供功能的菜单，通过查询权限管理系统中预先存储的菜单与可访问菜单的角色之间的映射关系，确定与待调用的api提供功能的菜单相映射的角色，作为具备待调用的api的调用权限的角色；

根据具备待调用的api的调用权限的角色，通过查询权限管理系统中预先存储的用户信息与角色之间的映射关系，确定与待调用的api的调用权限的角色相映射的用户信息，作为具备待调用的api的调用权限的用户信息；

根据待调用api的用户的用户信息是否与具备待调用的api的调用权限的用户信息相匹配，判断待调用api的用户是否具备待调用的api的调用权限。

上述如本说明书的实施方式提供的一种接口调用的鉴权方法可以应用于处理器中，或者由处理器实现。处理器可能是一种集成电路芯片，具有信号的处理能力。在实现过程中，上述方法的各步骤可以通过处理器中的硬件的集成逻辑电路或者软件形式的指令完成。上述的处理器可以是通用处理器，包括中央处理器(centralprocessingunit，cpu)、网络处理器(networkprocessor，np)等；还可以是数字信号处理器(digitalsignalprocessor，dsp)、专用集成电路(applicationspecificintegratedcircuit，asic)、现场可编程门阵列(field－programmablegatearray，fpga)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。可以实现或者执行本说明书实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。

结合本说明书实施例所公开的方法的步骤可以直接体现为硬件译码处理器执行完成，或者用译码处理器中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器，闪存、只读存储器，可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器，处理器读取存储器中的信息，结合其硬件完成上述方法的步骤。

本说明书实施例还提出了一种计算机可读存储介质，该计算机可读存储介质存储一个或多个程序，该一个或多个程序包括指令，该指令当被包括多个应用程序的电子设备执行时，能够使该电子设备执行一种接口调用的鉴权方法，并具体用于执行：

接收应用程序接口api网关发送的鉴权请求，鉴权请求包括待调用的api的信息及待调用api的用户的用户信息；

根据待调用的api的信息，通过查询权限管理系统中预先存储的api与api提供功能的菜单之间的映射关系，确定待调用的api提供功能的菜单；

根据待调用的api提供功能的菜单，通过查询权限管理系统中预先存储的菜单与可访问菜单的角色之间的映射关系，确定与待调用的api提供功能的菜单相映射的角色，作为具备待调用的api的调用权限的角色；

根据具备待调用的api的调用权限的角色，通过查询权限管理系统中预先存储的用户信息与角色之间的映射关系，确定与待调用的api的调用权限的角色相映射的用户信息，作为具备待调用的api的调用权限的用户信息；

根据待调用api的用户的用户信息是否与具备待调用的api的调用权限的用户信息相匹配，判断待调用api的用户是否具备待调用的api的调用权限。

上述实施例阐明的系统、装置、模块或单元，具体可以由计算机芯片或实体实现，或者由具有某种功能的产品来实现。一种典型的实现设备为计算机。

为了描述的方便，描述以上装置时以功能分为各种单元分别描述。当然，在实施本说明书时可以把各单元的功能在同一个或多个软件和/或硬件中实现。

本领域内的技术人员应明白，本说明书的实施例可提供为方法、装置、或计算机程序产品。因此，本说明书可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本说明书可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、cd-rom、光学存储器等)上实施的计算机程序产品的形式。

本说明书是参照根据本说明书实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

在一个典型的配置中，计算设备包括一个或多个处理器(cpu)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(ram)和/或非易失性内存等形式，如只读存储器(rom)或闪存(flashram)。内存是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。

还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制时，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。