认证授权方法、授权服务器、API网关、系统及存储介质与流程

认证授权方法、授权服务器、api网关、系统及存储介质
技术领域
1.本申请实施例涉及计算机软件技术领域领域，涉及但不限于一种认证授权方法、授权服务器、api网关、系统及存储介质。


背景技术：

2.在相关技术中，开放应用程序接口3.0(open application programming interface，openapi3.0)规范通过安全方案对象(security scheme object)来定义安全相关的属性，定义可以由操作使用的安全方案，包括超文本传输协议(hypertext transfer protocol，http)身份验证，api密钥(作为标头或作为查询参数)和开放授权(oauth2)的通用流程(隐式流程，密码验证流程，授权码流程)等；这样，通过定义安全属性实现网关认证和授权过程，无法满足较高的服务效率。


技术实现要素：

3.本申请实施例提供一种认证授权技术方案。
4.本申请实施例的技术方案是这样实现的：
5.第一方面，本申请实施例提供一种认证授权方法，所述方法包括：
6.获取预设应用程序接口的定义文件；
7.解析所述定义文件，生成所述预设api的服务授权项；
8.将所述服务授权项，加载到预设客户端的标识信息中，得到可授权信息；
9.接收api网关(api getway)发送的待鉴权客户端的待鉴权信息；
10.基于所述可授权信息对所述待鉴权信息进行鉴权，得到所述待鉴权客户端的鉴权结果。
11.第二方面，本申请实施例提供一种认证授权方法，所述方法包括：
12.响应于待鉴权客户端发送的服务请求，确定所述服务请求的第一签名信息；
13.接收所述待鉴权客户端发送的所述服务请求的第二签名信息和所述待鉴权客户端的待鉴权信息；其中，所述第二签名信息为所述待鉴权客户端对所述服务请求进行签名得到的；
14.在所述第一签名信息与所述第二签名信息相匹配的情况下，在当前缓存信息中查询所述待鉴权信息对应的授权记录信息；
15.在当前缓存信息中不包括所述授权记录信息的情况下，将所述待鉴权信息反馈至授权服务器，以使所述授权服务器对所述待鉴权信息进行鉴权。
16.第三方面，本申请实施例提供一种授权服务器，所述授权服务器包括：
17.第一获取模块，用于获取预设应用程序接口api的定义文件；
18.第一解析模块，用于解析所述定义文件，生成所述预设api的服务授权项；
19.第一加载模块，用于将所述服务授权项，加载到预设客户端的标识信息中，得到可授权信息；
20.第一接收模块，用于接收api网关发送的待鉴权客户端的待鉴权信息；
21.第一鉴权模块，用于基于所述可授权信息对所述待鉴权信息进行鉴权，得到所述待鉴权客户端的鉴权结果。
22.在一些实施例中，所述第一解析模块，包括：
23.第一解析子模块，用于解析所述定义文件，得到所述预设api的属性信息；
24.第一匹配子模块，用于确定与所述属性信息相匹配的域名信息；
25.第一生成子模块，用于在所述属性信息的基础上，添加所述域名信息，生成所述服务授权项。
26.在一些实施例中，所述授权服务器还包括：
27.第二确定模块，用于基于所述服务授权项，确定授权条件；
28.第三确定模块，用于将标识信息满足所述授权条件的客户端，确定为所述预设客户端。
29.在一些实施例中，所述第一接收模块，还用于：接收所述api网关在对所述待鉴权客户端进行认证通过的情况下，发送的所述待鉴权客户端的待鉴权标识信息和统一资源定位符；
30.对应地，所述第一鉴权模块，包括：
31.第二确定子模块，用于确定与所述待鉴权标识信息和统一资源定位符相匹配的目标信息；
32.第三确定子模块，用于在所述可授权信息中包括所述目标信息的情况下，确定所述待鉴权客户端通过鉴权，并向所述api网关反馈鉴权成功信息；
33.第一反馈子模块，用于在所述待鉴权信息中不包括所述目标信息的情况下，确定所述待鉴权客户端未通过鉴权，并向所述api网关反馈鉴权失败信息。
34.第四方面，本申请实施例提供一种api网关，所述api网关包括：
35.第一响应模块，用于响应于待鉴权客户端发送的服务请求，确定所述服务请求的第一签名信息；
36.第一接收模块，用于接收所述待鉴权客户端发送的所述服务请求的第二签名信息和所述待鉴权客户端的待鉴权信息；其中，所述第二签名信息为所述待鉴权客户端对所述服务请求进行签名得到的；
37.第一查询模块，用于在所述第一签名信息与所述第二签名信息相匹配的情况下，在当前缓存信息中查询所述待鉴权信息对应的授权记录信息；
38.第一鉴权模块，用于在当前缓存信息中不包括所述授权记录信息的情况下，将所述待鉴权信息反馈至授权服务器，以使所述授权服务器对所述待鉴权信息进行鉴权。
39.在一些实施例中，所述api网关还包括：
40.第一匹配模块，用于在所述第一签名信息与所述第二签名信息不匹配的情况下，生成认证失败信息；
41.第一反馈模块，用于将所述认证失败信息，返回所述待鉴权客户端。
42.在一些实施例中，所述api网关还包括：
43.第一确定模块，用于确定所述第二签名信息对应的预设签名算法；
44.对应地，所述第一响应模块，还用于：对所述服务请求进行拦截，采用所述预设签
名算法对所述服务请求进行签名，确定所述服务请求的第一签名信息。
45.在一些实施例中，所述第一接收模块，包括：
46.第一确定子模块，用于确定所述服务请求的授权请求消息头；
47.第二确定子模块，用于确定所述授权请求消息头中携带的所述第二签名信息；
48.第三确定子模块，用于确定所述服务请求中携带的所述待鉴权客户端的待授权标识信息和统一资源定位符，以得到所述待鉴权信息。
49.在一些实施例中，所述第一查询模块，包括：
50.第一匹配子模块，用于在所述第一签名信息与所述第二签名信息相同的情况下，确定所述第一签名信息与所述第二签名信息相匹配；
51.第四确定子模块，用于确定所述当前缓存信息；
52.第一查询子模块，用于在所述当前缓存信息中，查询所述待鉴权标识信息的授权记录信息。
53.在一些实施例中，所述第一鉴权模块，还用于：
54.在所述当前缓存信息中不包括所述授权记录信息的情况下，将所述待授权标识信息和统一资源定位符反馈至所述授权服务器，以使所述授权服务器基于所述待授权标识信息和所述统一资源定位符对所述待授权标识信息进行鉴权。
55.在一些实施例中，所述api网关还包括：
56.第二接收模块，用于接收所述授权服务器返回的所述待授权客户端的鉴权结果；
57.第一更新模块，用于将所述鉴权结果记录在当前缓存中，更新所述当前缓存信息，得到更新的缓存信息。
58.在一些实施例中，所述api网关还包括：
59.第一设定模块，用于在所述鉴权结果表征所述待鉴权客户端通过鉴权的情况下，在所述更新的缓存信息中，设定所述待鉴权客户端的权限有效时长；
60.第一发送模块，用于在所述有效时长内，将所述服务请求发送至应用服务器；
61.第三接收模块，用于接收所述应用服务器返回的所述服务请求的处理结果，并将所述处理结果反馈至所述待授权客户端。
62.在一些实施例中，所述api网关还包括：
63.第一生成模块，用于在所述鉴权结果表征所述待鉴权客户端未通过鉴权的情况下，生成鉴权失败信息；
64.第一反馈模块，用于将所述鉴权失败信息反馈至所述待鉴权客户端。
65.第五方面，本申请实施例提供一种认证授权系统，包括：
66.授权服务器，用于实现上述第一方面所述的方法步骤；
67.api网关，用于实现上述第二方面所述的方法步骤。
68.对应地，本申请实施例提供一种计算机存储介质，所述计算机存储介质上存储有计算机可执行指令，该计算机可执行指令被执行后，能够实现上述第一方面所述的方法步骤；或者，该计算机可执行指令被执行后，能够实现上述第二方面所述的方法步骤。
69.本申请实施例提供一种认证授权方法、授权服务器、api网关、系统及存储介质，对于任一应用服务接口，首先获取该api的定义文件，其次，通过对定义文件进行解析，生成该api的服务授权项；如此，通过解析openapi定义文件，为应用服务的每一个应用服务接口都
生成对应的服务授权项，细粒度到单个应用服务接口级别，从而针对不同的客户可以根据服务授权项访问指定的api服务。再次，授权服务器将服务授权项，赋予预设客户端的标识信息，得到可授权信息；最后，通过分析可授权信息与待鉴权信息的对应关系，对待鉴权客户端进行鉴权，从而确定出待鉴权客户端是否通过鉴权；如此，在无须对应用系统进行改造放入情况下，即可实现对待鉴权客户端的认证和细粒度授权。这样，以更细粒度的方式实现了针对单个api设定服务授权项，将单一的的服务接口独立授权给某个客户端，而且将api网关与授权服务器相结合实现对待鉴权客户端的鉴权，能够显著提高服务效率。
附图说明
70.图1为本申请实施例认证授权方法的实现流程示意图；
71.图2为本申请实施例提供的认证授权方法的交互示意图；
72.图3为本申请实施例解析定义文件的界面图；
73.图4为本申请实施例提供的细粒度授权方式的界面示意图；
74.图5为本申请实施例提供的认证授权过程的交互示意图；
75.图6为本申请实施例授权服务器结构组成示意图；
76.图7为本申请实施例api网关结构组成示意图；
77.图8为本申请实施例认证授权系统的组成结构示意图。
具体实施方式
78.为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合本申请实施例中的附图，对发明的具体技术方案做进一步详细描述。以下实施例用于说明本申请，但不用来限制本申请的范围。
79.在以下的描述中，涉及到“一些实施例”，其描述了所有可能实施例的子集，但是可以理解，“一些实施例”可以是所有可能实施例的相同子集或不同子集，并且可以在不冲突的情况下相互结合。
80.在以下的描述中，所涉及的术语“第一\第二\第三”仅仅是是区别类似的对象，不代表针对对象的特定排序，可以理解地，“第一\第二\第三”在允许的情况下可以互换特定的顺序或先后次序，以使这里描述的本申请实施例能够以除了在这里图示或描述的以外的顺序实施。
81.除非另有定义，本文所使用的所有的技术和科学术语与属于本申请的技术领域的技术人员通常理解的含义相同。本文中所使用的术语只是为了描述本申请实施例的目的，不是旨在限制本申请。
82.对本申请实施例进行进一步详细说明之前，对本申请实施例中涉及的名词和术语进行说明，本申请实施例中涉及的名词和术语适用于如下的解释。
83.1)开放应用程序接口，是服务型网站常见的一种应用，网站的服务商将自己的网站服务封装成一系列，api开放出去，供第三方开发者使用，这种行为称为开放网站的api。
84.2)open id连接服务发现(openid connect discovery)，作用是发现openid connect服务提供方提供的相关服务，比如，授权服务，令牌(token)服务对应的统一资源定位符(uniform resource locator，url)，签名支持的算法等。
85.3)密钥相关的哈希运算消息认证码(hash
‑
based message authentication code，hmac)算法，是一种基于密钥的消息完整性的验证方法，消息接收方可以根据预先约定的密钥有效验证消息的完整性。
86.下面说明本申请实施例提供的认证授权的系统的示例性应用，其中，本申请实施例提供的系统中的客户端可以实施为具有信息验证功能的笔记本电脑，平板电脑，台式计算机，移动设备(例如，个人数字助理，专用消息设备，便携式游戏设备)等各种类型的用户终端。下面，将说明认证授权的系统实施为服务器时示例性应用。
87.图1为本申请实施例认证授权方法的实现流程示意图，如图1所示，应用于授权服务器，结合如图1所示步骤进行说明：
88.步骤s101，获取预设api的定义文件。
89.在一些实施例中，预设api可以是任意一个open api，还可以理解为是指定的open api。api的定义文件，为open api的定义文件，用于对open api的自身属性信息进行描述，包括api对应的http请求方法(http method)和路径(path)等。其中，http请求方法包括：其中，http请求方法包括：查(get)、改(post)和局部更新(patch)等http协议方法。
90.步骤s102，解析定义文件，生成预设api的服务授权项。
91.在一些实施例中，开发人员将定义文件上传到授权服务器之后，授权服务器通过解析定义文件自动生成应用服务授权项；该服务授权项的数量为1个，每一api通过授权服务器解析定义文件，生成一个服务授权项，这样服务授权项和api一一对应。在一些可能的实现方式中，首先，解析定义文件，得到预设api的属性信息。即对定义文件进行解析，可以得到应用接口对应的属性信息。比如，解析定义文件，得到预设api的http请求方法和路径等。然后，确定与属性信息相匹配的域名信息。这里，与属性信息相匹配的域名信息，为部署属性信息时采用的域名，比如，预设api的http请求方法和路径可以表示为<post,/api/v1/user>，其中，post表示http请求方法为改，/api/v1/user表示路径。部署的域名信息可以表示为sen。最后，在属性信息的基础上，添加域名信息，生成服务授权项。其中，授权项的组成为：<域名(domain)，指令(action)，资源(resource)>，即<domain,action,resource>。在解析定义文件所得的属性信息的基础上，添加对应的域名，比如，在<post,/api/v1/user>的基础上，添加域名sen，得到生成的服务授权项为<sen.com,post,/api/v1/user>。如此，实现了解析openapi的定义文件之后，在解析内容的基础上附加上部署对应的域名即可以生成授权项。在本申请实施例中，授权服务器通过解析定义文件，为每一api生成一一对应的授权项，从而保证授权项和api一一对应。比如，轨道交通有三个api，分别为：get https://domain/passengers/{id}、post https://domain//pessages和post https://domain/passengers/search；这三个api分别对应授权项可以表示为：<domain,get,/passengers/{id}>、<domain,post,/passengers>和<domain,post,/passengers/search>。如此，通过解析openapi定义文件，为应用服务的每一个应用服务接口都生成对应的服务授权项，细粒度到单个应用服务接口级别，从而针对不同的客户可以根据服务授权项访问指定的api服务。
92.步骤s103，将服务授权项，加载到预设客户端的标识信息中，得到可授权信息。
93.在一些可能的实现方式中，预设客户端为任意的满足授权条件的客户端。预设客户端的标识信息用于标识用户的身份信息，将授权服务项授予预设客户端的标识信息，从而使得预设客户端的标识信息中携带服务授权项，即得到可授权信息。比如，预设客户端的
序列号。在一些实施例中，首先，针对某一客户端，开发人员在授权服务器中为该预设客户端生成用于唯一标识用户身份信息的标识信息(可表示为accesskey)和用于表示消息签名的签名信息(可表示为secretkey)，在授权服务器中将相关的授权项赋予给该客户端的标识信息，以便于授权服务器基于授权项对预设客户端进行鉴权。如此，将预设api的服务授权项，单独授予某一预设客户端，这样一个客户端仅提供一个服务接口，从而能够实现对客户端的细粒度鉴权。
94.步骤s104，接收api网关发送的待鉴权客户端的待鉴权信息。
95.在一些可能的实现方式中，待鉴权客户端与预设客户端可能相同或不同，待鉴权信息为表示待鉴权客户端所携带的服务授权项的信息，包括：待鉴权客户端的标识信息和统一资源定位符。在待鉴权客户端向api网关发送服务请求的情况下，api网关首先对发送服务请求的客户端进行认证，如果认证通过，api网关再对待鉴权客户端进行鉴权，如果鉴权未通过，将该待鉴权客户端的待鉴权信息发送给授权服务器。
96.步骤s105，基于可授权信息对待鉴权信息进行鉴权，得到待鉴权客户端的鉴权结果。
97.在一些可能的实现方式中，授权服务器通过可授权信息对待鉴权信息进行鉴权，以确定待鉴权客户端是否具有访问该应用接口的权限，即得到鉴权结果。在一个具体例子中，授权服务器通过判断待鉴权信息中是否包括可授权信息中携带的服务授权项，如果待鉴权信息中包括可授权信息中携带的服务授权项，说明待鉴权客户端通过鉴权；如果待鉴权信息中不包括可授权信息中携带的服务授权项，说明待鉴权客户端未通过鉴权，并向api网关反馈鉴权失败信息。
98.在本申请实施例中，对于任一应用服务接口，首先获取该api的定义文件，其次，通过对定义文件进行解析，生成该api的服务授权项；再次，授权服务器将服务授权项，赋予预设客户端的标识信息，得到可授权信息；这样就以更细粒度的方式实现了针对单个api设定服务授权项，将单一的的服务接口独立授权给某个客户端。最后，通过分析可授权信息与待鉴权信息的对应关系，对待鉴权客户端进行鉴权，从而确定出待鉴权客户端是否通过鉴权；如此，在无须对应用系统进行改造放入情况下，即可实现对待鉴权客户端的认证和细粒度授权。
99.在一些实施例中，将解析定义文件得到的服务授权项赋予特定的客户端，从而实现细粒度控制客户端接入api的权限，即步骤s103可以通过以下步骤实现：
100.步骤s131，基于服务授权项，确定授权条件。
101.在一些实施例中，通过分析服务授权项包括的内容和该服务授权项所属的场景，确定出这些服务授权项的授权条件；授权条件用于表征可享受这些服务授权项的基本要求。比如，在轨道交通场景下，以铁路交通为例，服务授权项包括：购票、退票和改签等权项，通过分析这些授权项并结合铁路交通的场景，确定出授权条件为客户端对应的账号信息中乘客个人身份信息未包含于失信名单中。
102.步骤s132，将标识信息满足授权条件的客户端，确定为预设客户端。
103.在一些实施例中，确定授权条件之后，将标识信息满足授权条件的任一客户端，作为预设客户端。以上述例子来说明，将乘客个人身份信息未包含于失信名单的客户端，作为预设客户端。如此，在授权服务器中保证了将服务授权项赋予满足授权条件的客户端，从而
提高了对客户端进行授权的准确度。
104.步骤s133，将服务授权项，加载到标识信息中，得到可授权信息。
105.在本申请实施例中，通过在大量的客户端中确定满足授权条件的预设客户端，将服务授权项赋予这些客户端的标识信息，从而能够将api的服务授权项可单独授权给某个客户端，进而能够实现对作为请求方的客户端的细粒度授权。
106.在一些实施例中，如果api网关的当前缓存信息中不存在待鉴权客户端的授权记录，api网关将待鉴权客户端的待鉴权信息发送给授权服务器，授权服务器基于可授权信息对待鉴权信息进行鉴权，可以通过以下过程实现：
107.第一步，接收api网关在对所述待鉴权客户端进行认证通过的情况下，发送的待鉴权客户端的待鉴权标识信息和统一资源定位符。
108.在一些可能的实现方式中，待鉴权客户端的待鉴权信息，包括：待鉴权标识信息和统一资源定位符。待鉴权标识信息中携带有待鉴权客户端发送请求的协议方法和路径。统一资源定位符的表现形式可以为：http://domain/{path}。api网关先对待鉴权客户端进行认证，如果认证通过，继续采用当前的缓存信息对待鉴权客户端进行鉴权，如果鉴权未通过，将鉴权客户端的待鉴权信息发送给授权服务器。
109.第二步，确定与待鉴权标识信息和统一资源定位符相匹配的目标信息。
110.在一些可能的实现方式中，根据待鉴权标识信息中包括的协议方法和统一资源定位符，查找待鉴权标识信息是否有对应的授权项。在一个具体例子中，如果授权项的表现形式是<domain,action,path>，由于每个待鉴权标识信息会对应多个服务授权项，每一个服务授权项都表示该待鉴权标识信息拥有访问统一资源定位符(即http://domain/{path})的权限，其中，待鉴权标识信息对应的服务请求的方法对应服务授权项中的action，对统一资源定位符进行解析后对应授权项中的domain和path。
111.第三步，在可授权信息中包括目标信息的情况下，确定待鉴权客户端通过鉴权。
112.在一些可能的实现方式中，如果在可授权信息中查找到待鉴权客户端的待鉴权标识信息和统一资源定位符对应的授权项，说明该待鉴权客户端为授权服务器赋予api服务授权项的客户端，即说明该待鉴权客户端具有访问该api的权限，通过鉴权。
113.第四步，在待鉴权信息中不包括目标信息的情况下，确定所述待鉴权客户端未通过鉴权。
114.在一些可能的实现方式中，如果在可授权信息中未查找到待鉴权客户端的待鉴权标识信息和统一资源定位符对应的授权项，说明该待鉴权客户端不是授权服务器赋予api服务授权项的客户端，即说明该待鉴权客户端不具有访问该api的权限，未通过鉴权。
115.在本申请实施例中，如果api网关对待鉴权标识信息进行鉴权之后，未通过鉴权，那么将待鉴权标识信息和url发送到授权服务器进行权限验证，授权服务器根据url和待鉴权标识信息中的协议方法查询是否有对应的服务授权项，如果有则表示鉴权通过。
116.本申请实施例提供一种认证授权系统，该系统包括客户端、api网关、授权服务器和应用服务器，其中，客户端、api网关、授权服务器和应用服务器的交互方式如图2所示，图2为本申请实施例提供的认证授权方法的交互示意图，结合图2所示的步骤进行以下说明：
117.步骤s201，授权服务器获取预设api的定义文件。
118.在一些实施例中，开发人员将预设api的定义文件上传到授权服务器。
119.步骤s202，授权服务器解析定义文件，生成预设api的服务授权项。
120.在一些实施例中，授权服务器通过解析定义文件，获取该api对应的属性信息(比如，api对应的http方法和路径)，然后在属性信息的基础上，附加部署的域名信息，即可自动生成服务授权项。
121.步骤s203，授权服务器将服务授权项，加载到预设客户端的标识信息中，得到可授权信息。
122.在一些实施例中，首先开发人员在授权服务器中为预设客户端生成两个随机字符串，表示用客户端标识信息的accesskey，和表示客户端签名消息的secretkey；然后，授权服务器通过解析openapi定义文件自动生成服务授权项之后，将生成的服务授权项赋予预设客户端的标识信息，比如，赋予预设客户端的accesskey，以使预设客户端的标识信息中携带服务授权项，得到可授权信息。
123.步骤s204，待鉴权客户端向api网关发送服务请求。
124.在一些实施例中，待鉴权客户端通过accesskey或secretkey访问api网关。
125.步骤s205，待鉴权客户端采用预设签名算法对服务请求进行签名，得到第二签名信息，并携带在服务请求中发送给api网关。
126.在一些可能的实现方式中，当待鉴权客户端发起http请求时，待鉴权客户端使用键控哈希算法(hmac
‑
sha1)算法对http请求进行签名，得到第二签名信息，并将第二签名信息存储在http协议中的授权请求消息头(authorization header)中。
127.步骤s206，api网关响应于待鉴权客户端发送的服务请求，确定服务请求的第一签名信息。
128.在一些实施例中，响应于待鉴权客户端发送的服务请求，api网关采用预设签名算法对该服务请求进行签名，得到第一签名信息；其中，预设签名算法为待鉴权客户端对服务请求进行签名时所采用的方法。在一些可能的实现方式中，api网关首先确定出第二签名信息对应的预设签名算法，即确定出待鉴权客户端对服务请求进行签名时所采用的方法，比如，hmac
‑
sha1算法。然后，api网关对服务请求进行拦截，采用预设签名算法对服务请求进行签名，确定服务请求的第一签名信息；比如，api网关采用hmac
‑
sha1算法对待鉴权客户端发起的http请求进行签名，得到第一签名信息。
129.步骤s207，api网关接收待鉴权客户端发送的服务请求的第二签名信息和待鉴权客户端的待鉴权信息。
130.在一些实施例中，api网关对待鉴权客户端发起的服务请求进行拦截，并获取该服务请求的授权请求消息头中携带的第二签名信息，并确定服务请求中携带的待鉴权客户端的待授权标识信息和统一资源定位符，以得到所述待鉴权信息；其中，待鉴权标识信息中携带了待鉴权客户端被赋予的服务授权项，与预设客户端被赋予的服务授权项可能相同或不同。在其他实施例中，待鉴权标识信息中还可能是未携带服务授权项，说明待鉴权客户端未被赋予服务授权项。
131.步骤s208，api网关在第一签名信息与第二签名信息相匹配的情况下，在当前缓存信息中查询待鉴权信息对应的授权记录信息。
132.在一些实施例中，待鉴权客户端发起的服务请求之后，api网关对服务请求进行拦截，然后，通过判断服务请求的第一签名信息与第二签名信息是否相同，对服务请求进行认
证，如果第一签名信息与第二签名信息相同，说明服务请求通过认证，如果第一签名信息与第二签名信息不同，说明服务请求未通过认证，并向待鉴权客户端反馈认证失败信息，比如，返回消息状态码401(消息状态码401表示用户身份认证失败，比如，密码错误)。
133.在一些可能的实现方式中，在待鉴权信息中包括待鉴权客户端的待授权标识信息和统一资源定位符的情况下，步骤s208可以通过以下过程实现：首先，判断第一签名信息与所述第二签名信息是否相同，如果相同，说明第一签名信息与第二签名信息相匹配，并生成认证成功信息；将认证成功信息反馈至待鉴权客户端；如此，就完成了api网关对服务请求的认证过程。然后，确定api网关用于存储鉴权结果的当前缓存信息；最后，在当前缓存信息中，查询待鉴权标识信息的授权记录信息。也就是说，在服务请求通过认证的情况下，api网关继续对服务请求进行鉴权，即通过获取当前缓存信息，在该当前缓存信息中查询是否存在待鉴权信息对应的授权记录信息。
134.步骤s209，在当前缓存信息中不包括授权记录信息的情况下，api网关将待鉴权信息反馈至授权服务器。
135.在一些实施例中，在当前缓存信息中不包括授权记录信息的情况下，api网关将待鉴权信息反馈至授权服务器，以使所述授权服务器对待鉴权信息进行鉴权。在当前缓存信息中不包括授权记录信息的情况下，说明该服务请求未曾被授权，api网关将待鉴权信息发送给授权服务器，以使授权服务器对待鉴权信息进行鉴权。在一些可能的实施例中，在当前缓存信息中不包括授权记录信息的情况下，将所述待授权标识信息和统一资源定位符反馈至所述授权服务器，以使所述授权服务器基于所述待授权标识信息和所述统一资源定位符对所述待授权标识信息进行鉴权。比如，api网关将服务请求所属的待鉴权客户端的accesskey和url发送到授权服务器进行权限验证，授权服务器根据accesskey对应的服务请求的方法和url，查询accesskey是否有对应的授权项，如果有则鉴权通过。
136.步骤s210，授权服务器接收api网关发送的待鉴权客户端的待鉴权信息。
137.在一些实施例中，授权服务器接收api网关发送的待鉴权客户端的待授权标识信息和统一资源定位符，比如，待鉴权客户端的accesskey和url。
138.步骤s211，授权服务器基于可授权信息对待鉴权信息进行鉴权，得到待鉴权客户端的鉴权结果，并将鉴权结果反馈至api网关。
139.在一些实施例中，授权服务器根据待鉴权信息中的url和服务请求所对应的方法，在可授权信息中查询是否存在待鉴权客户端的accesskey对应的服务授权项，实现对待鉴权客户端的鉴权，如果授权信息中存在待鉴权客户端的accesskey对应的服务授权项，说明待鉴权客户端的服务请求通过鉴权，将鉴权成功信息反馈至api网关。如果授权信息中不存在待鉴权客户端的accesskey对应的服务授权项，说明待鉴权客户端的服务请求未通过鉴权，将鉴权失败信息反馈至api网关。
140.步骤s212，api网关接收授权服务器返回的待授权客户端的鉴权结果。
141.在一些实施例中，api网关接收授权服务器返回的待授权客户端的鉴权成功消息，或者api网关接收授权服务器返回的待授权客户端的鉴权失败消息。
142.步骤s213，api网关将鉴权结果记录在当前缓存中，更新当前缓存信息，得到更新的缓存信息。
143.在一些实施例中，api网关接收到鉴权结果之后，对当前缓存信息进行更新，得到
更新的缓存信息，以便于在下一次接收到待鉴权客户端发送的服务请求时，基于更新的缓存信息对该服务请求进行鉴权；这样，由于更新的缓存信息存在该服务请求所属客户端的accesskey和url对应的授权记录，则直接确定该客户端通过鉴权。
144.步骤s214，在鉴权结果表征待鉴权客户端通过鉴权的情况下，api网关在更新的缓存信息中，设定所述待鉴权客户端的权限有效时长。
145.在一些实施例中，如果鉴权结果为鉴权成功信息，那么api网关对鉴权结果的时效性进行设定，并将设定是有效时长保存在更新的缓存信息中；说明该待鉴权客户端在有效时长内，均可访问该api，获取api的服务授权项。
146.在其他实施例中，在鉴权结果表征待鉴权客户端未通过鉴权的情况下，生成鉴权失败信息；api网关将鉴权失败信息反馈至待鉴权客户端。这里，如果鉴权结果为鉴权失败信息，api网关将鉴权失败信息反馈至待鉴权客户端，比如，该鉴权失败信息为消息状态码403(消息状态码403表示服务器已经理解请求但是拒绝执行该请求)，向待鉴权客户端反馈消息状态码403。
147.步骤s215，api网关在有效时长内，将服务请求发送至应用服务器。
148.在一些实施例中，api网关接收到授权服务器反馈的鉴权成功信息后，在该有效时长内，将服务请求发送至应用服务器。
149.步骤s216，应用服务器处理服务请求，得到请求结果，将请求结果反馈给api网关。
150.在一些实施例中，应用服务器处理服务请求，得到请求结果，可以理解为应用服务器对服务请求进行响应，并要包含响应状态码(response status code)和响应体(response body)。其中，响应状态码包括200、400和401等状态码；其中，状态码200表示请求成功，服务器已成功处理了请求，提供了请求的网页；状态码400表示错误请求，服务器不理解请求的语法。响应体为业务处理结果。
151.步骤s217，api网关接收应用服务器返回的处理结果，并将处理结果反馈至待授权客户端。
152.在本申请实施例中，认证授权系统主要包括api网关、授权服务器和应用服务器三部分，首先，通过授权服务器解析openapi3.0定义文件自动生成细粒度服务授权项，然后，通过网关对客户端进行认证，以及通过授权服务器对客户端进行授权，保证了认证和授权服务的过程均独立于产品业务系统，非侵入式集成，对产品服务是透明的。而且将api网关通过缓存对客户端进行鉴权和授权服务器鉴权相结合，能够提高服务效率。
153.下面，将说明本申请实施例在一个实际的应用场景中的示例性应用，以基于openapi3.0规范，实现对服务请求的认证和授权为例，进行说明。
154.在一些实施例中，openapi3.0规范定义了与网络应用程序的设计风格和开发方式(restful)api的语言无关的标准接口，使开发人员和计算机都可以发现和理解服务的功能，而无需访问源代码或者文档。对openapi文件进行正确定义后，用户可以用最少的实现逻辑来理解远程服务并与之交互。
155.在openapi3.0规范中，通过安全方案对象来定义安全相关的属性，定义可以由操作使用的安全方案。其中，openapi3.0规范支持的方案包括：http身份验证，api密钥(作为标头或作为查询参数)，oauth2的通用流程(隐式流程，密码验证流程，授权码流程)以及openid连接发现服务。但是，openapi3.0规范定义并没有严格区分认证和鉴权这两种不同
的功能，只是定义了安全属性，还需要额外的开发工作来实现，这样就无法做到细粒度(比如，单个api)的授权。
156.基于此，本申请实施例提供一种认证授权方法，该方法包含api网关(api gateway)，授权服务器和应用服务器三部分。从服务提供端获取openapi3.0描述定义文件，授权服务器解析openapi3.0定义文件，并且自动生成对应的授权项。管理人员为客户端生成两个随机字符串，标识信息和签名信息并且为标识信息赋予相关的授权项。当用户通过标识信息访问api时，api网关判断标识信息是否有访问相关api的授权项，从而确定是否可以访问该api。该方法可以通过以下过程实现：
157.第一步，对api进行权限定义和对用户端进行授权。
158.在一些可能的实现方式中，首先，开发人员上传openapi定义文件到授权服务器，授权服务器通过解析openapi定义文件自动生成相关的授权项。对openapi3.0定义文件解析后的授权项如图3所示，图3为本申请实施例解析定义文件的界面图，在界面31中，标题栏包括：基本链路(basic link)311、指令(action)312、资源(resource)313、描述(description)314和操作(operate)315；其中，基本链路311包括四个不同的基本链路分别为：https://todo
‑
api
‑
sc.sensetime.com/v2、https://todo
‑
api
‑
sc.sensetime.com/v2、https://todo
‑
api
‑
sc.sensetime.com/v2和https://todo
‑
api
‑
sc.sensetime.com/v2，分别对应的指令312为：get 321、post 322、删(delete)323和增(put)324。操作315包括三个选项：详情(detail)351、编辑(edit)352和删除(delete)353。
159.然后，开发人员在授权服务器中为用户端生成两个随机字符串，标识信息(access key)和密钥(secretkey)，在授权服务器中将相关的授权项赋予标识信息，授权服务器基于授权项对标识信息进行鉴权。这样，一个授权项就对应一个应用服务接口，如图4所示，图4为本申请实施例提供的细粒度授权方式的界面示意图，从图4可以看出，在界面41中呈现了4个授权项，在实际应用中，可以根据需求将其中的部分api接口的访问权限赋予给客户端的accesskey。界面41中包括可用权限42和已授予权限43，其中，可用权限分别为：授权项411：get/todos、授权项412：put/todos/{id}；已授予权限分别为：授权项413：delete/todos/{id}和授权项414：post/todos。这四个授权项中每一授权项对应一个应用服务接口，这样，将应用服务接口对应的授权项赋予客户端之后，在接收到客户端发送的服务请求时，可以基于服务请求的方法和统一资源定位符，确定是哪一个应用服务接口，如此，实现了针对基于每个单一的应用服务接口进行授权。
160.第二步，用户输入访问请求。
161.在一些可能的实现方式中，客户端通过accesskey/secretkey访问api，当发起http请求时，客户端需要对访问请求使用hmac
‑
sha1算法进行签名，并将签名放在authorization header中。
162.第三步，对输入的访问请求进行认证。
163.第四步，对输入的访问请求进行鉴权。
164.第五步，api网关将请求代理转发到应用服务器，并将鉴权结果返回给客户端。
165.上述第三步至第五步的实现过程如图5所示，图5为本申请实施例提供的认证授权过程的交互示意图，结合图5进行以下说明：
166.步骤s501，客户端计算访问签名，向api网关发送http请求。
167.在一些可能的实现方式中，客户端通过accesskey/secretkey访问api，当发起http请求时，客户端对访问请求使用hmac
‑
sha1算法计算访问签名，并将访问签名请求授权消息头中。
168.步骤s502，api网关响应于http请求，对http请求计算签名，并进行用户认证。
169.在一些可能的实现方式中，api对http网关请求进行拦截，通过同样的签名算法对http请求计算签名，如果得到的访问前面与authorization header中携带的访问前面一致，表示认证通过。否则表示认证失败的消息，比如，返回消息状态码401对应的信息，以进入步骤s503。
170.步骤s503，认证失败，api网关向客户端返回状态码401。
171.在一些可能的实现方式中，如果认证失败，向客户端返回状态码401，并结束整个认证鉴权流程。
172.步骤s504，api网关读取缓存信息，对标识信息进行鉴权。
173.在一些可能的实现方式中，api网关查询缓存，确定是否有标识信息和url对应的授权记录，如果有则根据缓存判断是否鉴权通过，否则转到步骤s505。
174.步骤s505，如果鉴权失败，api网关将标识信息和url发送到授权服务器进行权限验证，授权服务器根据url查询标识信息是否有对应的授权项，如果有则鉴权通过，并将鉴权结果反馈给api网关。
175.这里，鉴权失败是指如果api网关的缓存没有对应的授权记录，则api网关无法通过本地缓存进行鉴权。
176.步骤s506，api网关将鉴权结果进行缓存。
177.在一些可能的实现方式中，api网关将鉴权结果记录在缓存中，并且设定失效时间。
178.步骤s507，如果鉴权失败，api网关向客户端反馈表示鉴权失败的消息。
179.在一些可能的实现方式中，如果鉴权失败，api网关向客户端反馈表示鉴权失败的消息状态码403对应的内容，并结束整个认证鉴权流程。
180.步骤s508，如果鉴权成功，api网关将用户请求转发到应用服务器。
181.在一些可能的实现方式中，api网关将用户请求(对应于上述实施例中的服务请求)转发到应用服务器，并将结果返回给客户端。
182.步骤s509，应用服务器对用户请求进行处理，得到请求结果，将请求结果反馈给api网关。
183.步骤s510，api网关将请求结果反馈给客户端。
184.在一个具体例子中，本申请实施例提供的认证授权方法可以应用于轨道交通场景下，以使得轨道交通系统的api服务能够以安全可控的方式提交给用户使用，而且不同的用户可以根据授权项访问指定的api服务。将本申请实施例提供的认证授权方法应用于轨道交通系统的过程如下：
185.首先，轨道交通系统的api服务，接入到云框架系统中。
186.然后，通过云框架系统中的授权服务器对用户发放标识信息和签名信息并进行授权。
187.最后，由云框架系统中的授权服务器完成鉴权。
188.而且将本申请实施例提供的认证授权方法集成在云框架系统的过程只需要2天左右，切实提升了集成效率。
189.在本申请实施例中，通过解析openapi3.0描述定义文件，对api的权限进行细粒度的定义，在授权服务器中将相关api的权限授予给客户端，如此，通过解析openapi3.0定义文件自动生成细粒度授权项。而且认证和授权服务独立于产品业务系统，采用非侵入式集成，对产品服务透明。另外，api网关缓存鉴权和授权服务器鉴权相结合，能够提高服务效率。这样，api网关自动拦截用户请求进行认证和鉴权，能够实现细粒度权限控制效果。业在务端服务无须做任何修改即可使用，即可对不同的客户端按需授权，从而实现了对应用服务透明的认证和鉴权机制，降低了实现api细粒度权限控制带来的改造成本。
190.本申请实施例提供一种授权服务器，图6为本申请实施例授权服务器结构组成示意图，如图6所示，所述授权服务器600包括：
191.第一获取模块601，用于获取预设应用程序接口api的定义文件；
192.第一解析模块602，用于解析所述定义文件，生成所述预设api的服务授权项；
193.第一加载模块603，用于将所述服务授权项，加载到预设客户端的标识信息中，得到可授权信息；
194.第一接收模块604，用于接收api网关发送的待鉴权客户端的待鉴权信息；
195.第一鉴权模块605，用于基于所述可授权信息对所述待鉴权信息进行鉴权，得到所述待鉴权客户端的鉴权结果。
196.在一些实施例中，所述第一解析模块602，包括：
197.第一解析子模块，用于解析所述定义文件，得到所述预设api的属性信息；
198.第一匹配子模块，用于确定与所述属性信息相匹配的域名信息；
199.第一生成子模块，用于在所述属性信息的基础上，添加所述域名信息，生成所述服务授权项。
200.在一些实施例中，所述授权服务器还包括：
201.第二确定模块，用于基于所述服务授权项，确定授权条件；
202.第三确定模块，用于将标识信息满足所述授权条件的客户端，确定为所述预设客户端。
203.在一些实施例中，所述第一接收模块604，还用于：接收所述api网关在对所述待鉴权客户端进行认证通过的情况下，发送的所述待鉴权客户端的待鉴权标识信息和统一资源定位符；
204.对应地，所述第一鉴权模块605，包括：
205.第二确定子模块，用于确定与所述待鉴权标识信息和统一资源定位符相匹配的目标信息；
206.第三确定子模块，用于在所述可授权信息中包括所述目标信息的情况下，确定所述待鉴权客户端通过鉴权，并向所述api网关反馈鉴权成功信息；
207.第一反馈子模块，用于在所述待鉴权信息中不包括所述目标信息的情况下，确定所述待鉴权客户端未通过鉴权，并向所述api网关反馈鉴权失败信息。
208.本申请实施例提供一种api网关，图7为本申请实施例api网关结构组成示意图，如图7所示，所述api网关700包括：
209.第一响应模块701，用于响应于待鉴权客户端发送的服务请求，确定所述服务请求的第一签名信息；
210.第一接收模块702，用于接收所述待鉴权客户端发送的所述服务请求的第二签名信息和所述待鉴权客户端的待鉴权信息；其中，所述第二签名信息为所述待鉴权客户端对所述服务请求进行签名得到的；
211.第一查询模块703，用于在所述第一签名信息与所述第二签名信息相匹配的情况下，在当前缓存信息中查询所述待鉴权信息对应的授权记录信息；
212.第一鉴权模块704，用于在当前缓存信息中不包括所述授权记录信息的情况下，将所述待鉴权信息反馈至授权服务器，以使所述授权服务器对所述待鉴权信息进行鉴权。
213.在一些实施例中，所述api网关还包括：
214.第一匹配模块，用于在所述第一签名信息与所述第二签名信息不匹配的情况下，生成认证失败信息；
215.第一反馈模块，用于将所述认证失败信息，返回所述待鉴权客户端。
216.在一些实施例中，所述api网关还包括：
217.第一确定模块，用于确定所述第二签名信息对应的预设签名算法；
218.对应地，所述第一响应模块701，还用于：对所述服务请求进行拦截，采用所述预设签名算法对所述服务请求进行签名，确定所述服务请求的第一签名信息。
219.在一些实施例中，所述第一接收模块702，包括：
220.第一确定子模块，用于确定所述服务请求的授权请求消息头；
221.第二确定子模块，用于确定所述授权请求消息头中携带的所述第二签名信息；
222.第三确定子模块，用于确定所述服务请求中携带的所述待鉴权客户端的待授权标识信息和统一资源定位符，以得到所述待鉴权信息。
223.在一些实施例中，所述第一查询模块703，包括：
224.第一匹配子模块，用于在所述第一签名信息与所述第二签名信息相同的情况下，确定所述第一签名信息与所述第二签名信息相匹配；
225.第四确定子模块，用于确定所述当前缓存信息；
226.第一查询子模块，用于在所述当前缓存信息中，查询所述待鉴权标识信息的授权记录信息。
227.在一些实施例中，所述第一鉴权模块704，还用于：
228.在所述当前缓存信息中不包括所述授权记录信息的情况下，将所述待授权标识信息和统一资源定位符反馈至所述授权服务器，以使所述授权服务器基于所述待授权标识信息和所述统一资源定位符对所述待授权标识信息进行鉴权。
229.在一些实施例中，所述api网关还包括：
230.第二接收模块，用于接收所述授权服务器返回的所述待授权客户端的鉴权结果；
231.第一更新模块，用于将所述鉴权结果记录在当前缓存中，更新所述当前缓存信息，得到更新的缓存信息。
232.在一些实施例中，所述api网关还包括：
233.第一设定模块，用于在所述鉴权结果表征所述待鉴权客户端通过鉴权的情况下，在所述更新的缓存信息中，设定所述待鉴权客户端的权限有效时长；
234.第一发送模块，用于在所述有效时长内，将所述服务请求发送至应用服务器；
235.第三接收模块，用于接收所述应用服务器返回的所述服务请求的处理结果，并将所述处理结果反馈至所述待授权客户端。
236.在一些实施例中，所述api网关还包括：
237.第一生成模块，用于在所述鉴权结果表征所述待鉴权客户端未通过鉴权的情况下，生成鉴权失败信息；
238.第一反馈模块，用于将所述鉴权失败信息反馈至所述待鉴权客户端。
239.需要说明的是，以上装置实施例的描述，与上述方法实施例的描述是类似的，具有同方法实施例相似的有益效果。对于本申请装置实施例中未披露的技术细节，请参照本申请方法实施例的描述而理解。
240.需要说明的是，本申请实施例中，如果以软件功能模块的形式实现上述的认证授权方法，并作为独立的产品销售或使用时，也可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请实施例的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是终端、服务器等)执行本申请各个实施例所述方法的全部或部分。而前述的存储介质包括：u盘、运动硬盘、只读存储器(read only memory，rom)、磁碟或者光盘等各种可以存储程序代码的介质。这样，本申请实施例不限制于任何特定的硬件和软件结合。
241.对应地，本申请实施例再提供一种计算机程序产品，所述计算机程序产品包括计算机可执行指令，该计算机可执行指令被执行后，能够实现本申请实施例提供的认证授权方法中的步骤。
242.本申请实施例提供一种认证授权系统，如图8所示，认证授权系统800包括：
243.授权服务器600，用于实现上述授权服务器的各个模块；
244.api网关700，用于实现上述api网关的各个模块。
245.以上服务器、网关和存储介质实施例的描述，与上述方法实施例的描述是类似的，具有同相应方法实施例相似的技术描述和有益效果，限于篇幅，可案件上述方法实施例的记载，故在此不再赘述。对于本申请认证授权装置、计算机设备和存储介质实施例中未披露的技术细节，请参照本申请方法实施例的描述而理解。
246.应理解，说明书通篇中提到的“一个实施例”或“一实施例”意味着与实施例有关的特定特征、结构或特性包括在本申请的至少一个实施例中。因此，在整个说明书各处出现的“在一个实施例中”或“在一实施例中”未必一定指相同的实施例。此外，这些特定的特征、结构或特性可以任意适合的方式结合在一个或多个实施例中。应理解，在本申请的各种实施例中，上述各过程的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本申请实施例的实施过程构成任何限定。上述本申请实施例序号仅仅为了描述，不代表实施例的优劣。
247.需要说明的是，在本文中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者装置不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者装置所固有的要素。在没有更多限制的情况下，由语句“包括一个
……”
限定的要素，并不排除在包括该
要素的过程、方法、物品或者装置中还存在另外的相同要素。在本申请所提供的几个实施例中，应该理解到，所揭露的设备和方法，可以通过其它的方式实现。以上所描述的设备实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，如：多个单元或组件可以结合，或可以集成到另一个系统，或一些特征可以忽略，或不执行。另外，所显示或讨论的各组成部分相互之间的耦合、或直接耦合、或通信连接可以是通过一些接口，设备或单元的间接耦合或通信连接，可以是电性的、机械的或其它形式的。
248.上述作为分离部件说明的单元可以是、或也可以不是物理上分开的，作为单元显示的部件可以是、或也可以不是物理单元；既可以位于一个地方，也可以分布到多个网络单元上；可以根据实际的需要选择其中的部分或全部单元来实现本实施例方案的目的。
249.另外，在本申请各实施例中的各功能单元可以全部集成在一个处理单元中，也可以是各单元分别单独作为一个单元，也可以两个或两个以上单元集成在一个单元中；上述集成的单元既可以采用硬件的形式实现，也可以采用硬件加软件功能单元的形式实现。本领域普通技术人员可以理解：实现上述方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成，前述的程序可以存储于计算机可读取存储介质中，该程序在执行时，执行包括上述方法实施例的步骤；而前述的存储介质包括：移动存储设备、只读存储器(read only memory，rom)、磁碟或者光盘等各种可以存储程序代码的介质。
250.或者，本申请上述集成的单元如果以软件功能模块的形式实现并作为独立的产品销售或使用时，也可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请实施例的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机、服务器、或者网络设备等)执行本申请各个实施例所述方法的全部或部分。而前述的存储介质包括：移动存储设备、rom、磁碟或者光盘等各种可以存储程序代码的介质。以上所述，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以所述权利要求的保护范围为准。