API授权认证处理方法、装置、电子设备和存储介质与流程

api授权认证处理方法、装置、电子设备和存储介质
技术领域
1.本技术涉及大数据数据访问技术领域，尤其涉及一种api授权认证处理方法、装置、电子设备和存储介质。


背景技术：

2.随着互联网技术发展，提供服务的业务系统越来越多，因此为用户提供的服务也日益增多。相关技术中，通常是应用方与业务系统之间进行对接，当应用方发起调用请求时，业务系统根据请求提供相应的服务。
3.但是，大多服务提供方使用的应用程序编程接口(application programming interface，api)风格不尽相同，应用方与服务提供方之间的对接成本较高。


技术实现要素：

4.本技术提供一种api授权认证处理方法、装置、电子设备和存储介质，以至少在一定程度上解决相关技术中的技术问题之一。本技术的技术方案如下：
5.根据本技术实施例的第一方面，提供一种api授权认证处理方法，可应用于api授权认证平台，该方法包括：
6.接收应用方在调用所述api授权平台的目标api时发送的服务请求，其中，所述服务请求中包括与所述服务请求参数关联的第一数字签名；
7.对所述第一数字签名进行验证；
8.在所述第一数字签名通过验证的情况下，将所述服务请求转发给对应的业务服务器，以获取所述业务服务器返回的所述服务请求对应的服务结果；
9.将服务结果返回给应用方。
10.根据本技术实施例的第二方面，提供一种api授权认证处理装置，包括：
11.接收模块，被配置为接收应用方在调用所述api授权平台的目标api时发送的服务请求，其中，所述服务请求中包括与所述服务请求参数关联的第一数字签名；
12.验证模块，被配置为对所述第一数字签名进行验证；
13.转发模块，被配置为在所述第一数字签名通过验证的情况下，将所述服务请求转发给对应的业务服务器，以获取所述业务服务器返回的所述服务请求对应的服务结果；
14.发送模块，被配置为将服务结果返回给应用方。
15.根据本技术实施例的第三方面，提供一种电子设备，包括：处理器；用于存储所述处理器可执行指令的存储器；其中，所述处理器被配置为执行所述指令，以实现如本技术上述实施例所述的方法。
16.根据本技术实施例的第四方面，提供一种计算机可读存储介质，当所述计算机可读存储介质中的指令由电子设备的处理器执行时，使得电子设备能够执行如本技术上述实施例所述的方法。
17.根据本技术实施例的第五方面，提供一种计算机程序产品，包括：计算机程序，所
述计算机程序被处理器执行时实现如本技术上述实施例所述的方法。
18.本技术的实施例提供的技术方案至少带来以下有益效果：api授权认证平台可以通过对第一数字签名进行验证，实现对应用方的身份进行验证，若验证通过，说明应用方有权限调用目标api，实现了对api授权认证管理，从而应用方可以通过api授权认证平台调用服务提供方的api，降低了应用方与服务提供方之间的对接成本，服务提供方也无需重复实现api访问控制逻辑，减少了服务提供方的处理负担。
19.应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本技术。
附图说明
20.此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本技术的实施例，并与说明书一起用于解释本技术的原理，并不构成对本技术的不当限定。
21.图1是本技术一实施例提供的api授权认证处理方法的流程示意图。
22.图2为本技术实施例提供的应用方、api授权认证平台及业务提供方之间的关系示意图。
23.图3是本技术另一实施例提供的api授权认证处理方法的流程示意图。
24.图4是本技术另一实施例提供的api授权认证处理方法的流程示意图。
25.图5是本技术另一实施例提供的api授权认证处理方法的流程示意图。
26.图6是本技术另一实施例提供的api授权认证处理方法的流程示意图。
27.图7是本技术实施例提供的一交互流程示意图。
28.图8是本技术实施例提供的另一交互流程示意图。
29.图9是本技术实施例提供的另一交互流程示意图。
30.图10是本技术一实施例提供的api授权认证处理装置的结构示意图。
31.图11为本技术一实施例提供的电子设备的结构示意图。
具体实施方式
32.为了使本领域普通人员更好地理解本技术的技术方案，下面将结合附图，对本技术实施例中的技术方案进行清楚、完整地描述。
33.需要说明的是，本技术的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本技术的实施例能够以除了在这里图示或描述的那些以外的顺序实施。以下示例性实施例中所描述的实施方式并不代表与本技术相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本技术的一些方面相一致的装置和方法的例子。
34.本技术技术方案中对数据的获取、存储、使用、处理等均符合国家法律法规的相关规定。
35.随着互联网技术发展，提供服务的业务系统越来越多，因此为用户提供的服务也日益增多。相关技术中，通常是应用方与业务系统之间进行对接，当应用方发起调用请求时，业务系统根据请求提供相应的服务。
36.但是，大多服务提供方所使用的api风格不尽相同，应用方与服务提供方之间的对接成本较高。并且，业务服务系统需要重复实现api访问控制逻辑，比如验证、鉴权等，比较繁琐。基于此，本技术实施例提供了一种api授权认证处理方法。
37.下面参考附图描述本技术实施例的api授权认证处理方法、装置、电子设备和存储介质。图1是本技术一实施例提供的api授权认证处理方法的流程示意图。
38.本技术实施例以该api授权认证处理方法被配置于api授权认证平台中来举例说明，该api授权认证平台可以应用于任一电子设备中，以使该电子设备可以执行api授权认证处理功能。
39.其中，电子设备可以为任一具有计算能力的设备，例如可以为服务器等。
40.本技术的api授权认证平台可以包括api接入平台、用户授权鉴权系统、api后台管理者门户、api监控平台等部分。
41.其中，api接入平台，提供外网https、http2、http等协议转换适配到内网http协议或其他内部协议，安全方面提供认证验签、验签加固、waf、防刷、限流、风控，移动接入优化如ssl加解密异步化、流量管控、异地多活，其他方面提供轻量数据聚合、多租户等。
42.用户授权鉴权系统，可提供对外接口中的权限控制。比如，对合法注册的应用的内部资源交易接口访问生成访问令牌，校验第三方请求附带的访问令牌的合法性，支持用户授权访问用户个人信息。
43.如图1所示，该api授权认证处理方法可以包括以下步骤101-步骤105。
44.步骤101，接收应用方在调用api授权平台的目标api时发送的服务请求。
45.本技术中，服务提供方可以按照统一的接口标准开发api，并在api授权认证平台进行注册发布，由此，api授权认证平台可以集成多个服务提供方的api，应用方可以通过api授权认证平台调用服务提供方的api，从而可以减少应用方与服务提供方之间的对接成本，并且业务服务器也无需重复实现api访问控制逻辑。其中，应用方可以是应用客户端，也可以是应用服务端。
46.本技术中，当某服务提供方申请注册api时，api授权认证平台可以获取api注册请求，其中，注册请求中可以包括待注册api的标识，api授权认证平台可以根据待注册api的标识，查询api数据库，以确定待注册api是否已经注册过。如果api数据库中未包含待注册api的标识，那么可以将待注册api的标识添加到api数据库，如果api数据库中包含待注册api的标识，说明该api已经注册过，那么可以向服务提供方返回api已注册的提示信息。由此，api授权认证平台可以集成服务提供方的api。
47.为了便于理解，下面结合图2进行说明，图2为本技术实施例提供的应用方、api授权认证平台及业务提供方之间的关系示意图。
48.如图2中所示，服务提供方可以采用统一的接口标准开发api并在平台进行注册，其中，服务提供方可以包括手机服务、公有云服务、第三方服务等。
49.服务使用方可以是前端应用，也可以是后端服务，其中，前端应用比如可以是前端pc端、移动app、小程序等可以发起前端调用。服务使用方的前端应用可以通过统一提供的javascript软件开发工具包发起服务请求。服务使用方如果是后端服务，使用java软件开发工具包发起服务请求。
50.本技术中，当应用客户端或应用服务端需要发起服务请求时，可以调用api授权认
证平台的目标api，由此，api授权认证平台可以接收应用方发送的服务请求。
51.比如，用户在某应用客户端进行刷脸认证操作时，该应用客户端需要使用第三方的刷脸认证服务。又如，用户在某浏览器页面进行查询利率公开信息的操作时，该页面需要使用第三方的利率业务服务。
52.本技术中，应用方在向api授权认证平台发送服务请求之前，可以对服务请求参数进行加密，或者对服务请求相关的信息进行加密，生成第一数字签名，应用方向api授权认证平台发送服务请求中可以携带第一数字签名。
53.步骤102，对第一数字签名进行验证。
54.本技术中，api授权认证平台可以根据预设的加解密规则，对第一数字签名进行验证。比如，第一数字签名是用应用方的私钥进行加密的，那么api授权认证平台可以利用与应用方的私钥成对的公钥，对第一数字签名进行验证。
55.本技术中，api授权认证平台对应用方的第一数字签名进行验证，可以确定应用方的身份及在验证身份的基础上再验证传递的明文数据是否被篡改过。
56.步骤103，在第一数字签名验证通过的情况下，将服务请求转发给对应的业务服务器，以获取业务服务器返回的服务请求对应的服务结果。
57.本技术中，如果第一数字签名验证通过，可以认为应用方具有调用目标api的权限，说明服务请求为合法请求，那么api授权认证平台可以将应用方的服务请求转发给对应的业务服务器，业务服务器可以对服务请求进行处理，并返回服务请求对应的服务结果。
58.以图2为例，服务使用方也即应用方发起的请求经过平台的鉴权和寻址，路由到服务提供方的api，从而由服务提供方可以获取服务请求，并对服务请求进行处理。
59.在实际应用中，可能有多个服务提供方提供相同的业务服务，应用方可以指定调用哪个服务提供方的业务服务。本技术中，api授权认证平台在转发服务请求时，如果服务请求中包含统一资源定位符(uniform resource locator，url)，那么可以根据url将服务请求转发给指定的业务服务器。
60.比如，配置了服务为my-service，api path为空，业务服务器的url为http://127.0.0.1:8080/forward-service/，可以将那么服务请求http://{ip}:{port}/proxy/my-service/api-path将转发到http://127.0.0.1:8080/forward-service/api-path。
61.或者，本技术中，也可以根据服务请求所请求的业务服务，确定服务请求的请求路径，从而根据服务请求的请求路径将服务请求转发到对应的业务服务器。比如，服务请求是关于刷脸认证的，那么确定该服务请求的请求路径，从而将服务请求转发给提供刷脸认证服务的业务服务器。
62.可见，本技术中，api授权认证平台可以提供不同类型的转发方式，可以按照请求路径转发，也可以根据url转发到指定的业务服务器，从而可以满足多样化需求。
63.步骤104，将服务结果返回给应用方。
64.本技术中，api授权认证平台可以将服务结果直接返回给应用方，或者为了提高数据的安全性，也可以对服务结果进行加密，将加密后服务结果返回给应用方。
65.本技术实施例中，通过接收应用方在调用api授权平台的目标api时发送的服务请求，并对服务请求中与服务请求参数关联的第一数字签名进行验证，在第一数字签名验证通过的情况下，将服务请求转发给对应的业务服务器，以获取业务服务器返回的服务请求
对应的服务结果，并将服务结果返回给应用方。由此，api授权认证平台可以通过对第一数字签名进行验证，实现对应用方的身份进行验证，若验证通过，说明应用方有权限调用目标api，实现了对api授权认证管理，从而应用方可以通过api授权认证平台调用服务提供方的api，降低了应用方与服务提供方之间的对接成本，服务提供方也无需重复实现api访问控制逻辑，减少了服务提供方的处理负担。
66.图3是本技术另一实施例提供的api授权认证处理方法的流程示意图。
67.如图3所示，该api授权认证处理方法包括：
68.步骤301，接收应用方在调用api授权平台的目标api时发送的服务请求。
69.步骤302，对第一数字签名进行验证。
70.步骤303，在第一数字签名验证通过的情况下，将服务请求转发给对应的业务服务器，以获取业务服务器返回的服务请求对应的服务结果。
71.本技术中，步骤301-步骤303与上述实施例记载的内容类似，故在此不再赘述。
72.步骤304，利用api授权认证平台的第一私钥对服务结果进行加密，得到第二数字签名。
73.为了提高安全性，本技术中，api授权认证平台可以预先生成一对私钥和公钥，api授权认证平台可以利用自身的私钥对服务结果进行加密，以生成第二数字签名。
74.步骤305，将第二数字签名返回给应用方，以使应用方使用第一私钥对应的第一公钥对第二数字签名进行验证。
75.本技术中，api授权认证平台将第二数字签名返回给应用方，也即将数字签名后的服务结果返回给应用方。
76.若应用方为应用客户端，应用客户端可以将第二数字签名发送给应用服务端，应用服务端可以利用预先获取的与第一私钥对应的第一公钥，也即利用api授权认证平台的公钥，对第二数字签名进行验证。若通过验证，说明服务结果是api授权认证平台返回的，应用服务端可以将解密后得到的服务结果返回给应用客户端；如果未通过验证，说明服务结果不是api授权认证平台返回的。
77.若应用方为应用服务端，那么应用服务端可以利用api授权认证平台的第一公钥对第二数字签名进行验证，若验证通过得到解密后的服务结果。
78.本技术中实施例中，在将服务结果返回给应用方时，可以利用api授权认证平台的第一私钥对服务结果进行加密，得到第二数字签名，将第二数字签名返回给应用方，以使应用方获取利用第一私钥对应的第一公钥对第二数字签名验证后的结果。由此，通过对服务结果进行加密得到第二数字签名，将第二数字签名返回给应用方，可以便于应用方对api授权认证平台的身份进行验证，也提高了安全性。
79.图4是本技术另一实施例提供的api授权认证处理方法的流程示意图。如图4所示，该api授权认证处理方法包括步骤401-步骤408。
80.步骤401，接收应用方在调用api授权平台的目标api时发送的服务请求。
81.本技术中，应用方可以是应用客户端，用户在应用客户端使用某项服务时，应用客户端可以将相应的信息发送给应用服务端，应用服务端可以利用应用方的第二私钥对该信息进行加密得到第一数字签名，应用客户端可以根据第一数字签名调用api授权认证平台的目标api，api授权认证平台接收到服务请求，服务请求中可以包括第一数字签名，第一数
字签名是利用应用方的第二私钥加密生成的。
82.本技术中，应用客户端在api授权认证平台注册成功时，api授权认证平台可以在工具界面生成应用方的公私钥，也即第二私钥和第二公钥。
83.步骤402，获取第二私钥对应的第二公钥。
84.本技术中，应用方在获取第二私钥和第二公钥后，可以登录api授权认证平台登记其公钥，由此，api授权认证平台可以获取应用方的第二公钥。
85.步骤403，根据第二公钥，对第一数字签名进行验证。
86.本技术中，api授权认证平台可以利用应用方的第二公钥，对第一数字签名进行解密，得到解密结果，并将解密结果与服务请求中的请求参数进行对比，根据对比结果，确定第一数字签名是否验证通过。如果解密结果与请求参数一致，可以认为第一数字签名验证通过；如果解密结果与请求参数不一致，可以认为第一数字签名未验证通过。
87.步骤404，第一数字签名是否验证通过。如果第一数字签名验证通过，可以执行步骤405，如果第一数字签名未验证通过，可以执行步骤408。
88.步骤405，将服务请求转发给对应的业务服务器，以获取业务服务器返回的服务请求对应的服务结果。
89.本技术中，如果第一数字签名验证通过，可以将服务请求转发给对应的业务服务器。
90.步骤406，利用api授权认证平台的第一私钥对服务结果进行加密，得到第二数字签名。
91.步骤407，将第二数字签名返回给应用方，以使应用方获取利用第一私钥对应的第一公钥对第二数字签名验证后的结果。
92.本技术中，步骤405-步骤407与上述实施例记载的内容类似，故在此不再赘述。
93.步骤408，返回应用方没有权限调用目标api的提示信息。
94.本技术中，如果第一数字签名未验证通过，说明应用方没有权限调用目标api，api授权认证平台可以向应用方返回应用方没有权限调用目标api的提示信息。
95.本技术实施例中，第一数字签名是利用应用方的第二私钥加密生成的，在对第一数字签名进行验证时，可以通过获取第二私钥对应的第二公钥，并根据第二公钥，对第一数字签名进行验证，由此，api授权认证平台可以通过应用方公钥对第一数字签名进行验证，以确定应用方是否有权限调用目标api，也即确定应用方的服务请求是否为合法请求，实现了对api授权认证管理。
96.图5是本技术另一实施例提供的api授权认证处理方法的流程示意图。如图5所示，该api授权认证处理方法包括步骤501-步骤508。
97.步骤501，接收应用方在调用api授权平台的目标api时发送的服务请求。
98.本技术中，应用方可以先在api授权认证平台进行注册，api授权认证平台可以接收应用方的注册请求，其中，注册请求中可以包含应用方的信息，api授权认证平台可以对注册请求进行验证，也即对应用方的信息进行审核验证，在验证通过的情况下，可以向应用方返回第一应用标识(appid)和第一应用密钥(appsecret)。
99.其中，第一应用标识可以唯一标识应用方，第一应用标识可以是根据应用名称和时间通过哈希算法计算得到的。
100.本技术中，应用方可以为应用服务端，应用服务端可以利用应用方的第一应用密钥对服务请求参数进行加密，生成第一数字签名。
101.本技术中，应用方利用第一应用密钥对服务请求参数进行加密时，可以将请求参数按照key＝value的格式和ascii码从小到大排序后拼接得到第一文本，并将第一文本转化成小写后得到第二文本，在第二文本拼接上第一应用密钥得到第三文本；对第三文本进行md5信息摘要算法加密后即得到签名参数sign，也即得到第一数字签名。
102.在得到第一数字签名后，应用方可以将第一数字签名拼接到请求参数后面发送给api授权平台，也即服务请求中可以包括第一数字签名、请求参数等。
103.步骤502，根据服务请求中的第一应用标识，查询应用标识与应用密钥的对应关系，以确定第一应用标识对应的第一应用密钥。
104.本技术中，服务请求中还包括应用方的第一应用标识，api授权认证平台可以根据第一应用标识，查询各应用方的应用标识与应用密钥的对应关系，以确定该应用方的第一标识对应的第一应用密钥。
105.比如，服务请求中包括某应用方的第一应用标识为a，api授权认证平台可以根据第一应用标识a，查询应用标识与应用密钥之间的对应关系，以确定第一应用标识a对应的第一应用密钥。
106.步骤503，利用第一应用密钥对第一数字签名进行验证。
107.本技术中，api授权认证平台可以根据第一应用密钥，采用相同的签名算法对服务请求中的请求参数进行加密，生成得到第三数字签名，如果第一数字签名与第三数字签名一致，可以确定第一数字签名验证通过，如果第一数字签名与第三数字签名不一致，可以确定第一数字签名未验证通过。
108.步骤504，第一数字签名是否验证通过。如果第一数字签名验证通过，执行步骤505，如果第一数字签名未验证通过，可以执行步骤508。
109.步骤505，将服务请求转发给对应的业务服务器，以获取业务服务器返回的服务请求对应的服务结果。
110.步骤506，利用api授权认证平台的第一私钥对服务结果进行加密，得到第二数字签名。
111.步骤507，将第二数字签名返回给应用方，以使应用方获取利用第一私钥对应的第一公钥对第二数字签名验证后的结果。
112.步骤508，返回应用方没有权限调用目标api的提示信息。
113.本技术中，步骤505-步骤508与上述实施例记载的内容类似，故在此不再赘述。
114.本技术实施例中，第一数字签名可以是利用应用方的第一应用密钥加密生成的，在对第一数字签名进行验证时，可以根据服务请求中的第一应用标识，查询应用标识与应用密钥的对应关系，以确定第一应用标识对应的第一应用密钥，并利用第一应用密钥，对服务请求中的请求参数进行加密，生成第三数字签名，根据第三数字签名，对第一数字签名进行验证。由此，api授权认证平台可以通过应用方的应用密钥对第一数字签名进行验证，以确定应用方是否有权限调用目标api，也即确定应用方的服务请求是否为合法请求，实现了对api授权认证管理。
115.图6是本技术另一实施例提供的api授权认证处理方法的流程示意图。如图6所示，
在接收应用方发送的服务请求之前，该api授权认证处理方法还包括步骤601-步骤607。
116.步骤601，获取应用方的api调用请求，其中，调用请求中包括目标api的标识、应用方的第二应用标识及第二应用密钥。
117.本技术中，第二应用标识与上述第一应用标识可以相同，第二应用密钥可以与上述第一应用密钥相同，第二应用标识和第二应用密钥的获取方式也与第一应用标识和第一应用密钥的获取方式类似，故在此不再赘述。
118.本技术中，应用方需要调用第三方业务服务时，可以先向api授权认证平台发送api调用请求，由此，api授权认证平台可以获取应用方的api调用请求。其中，调用请求中可以包括目标api的标识、应用方的第二应用标识、应用方的第二应用密钥等。
119.步骤602，根据第二应用标识和第二应用密钥，应用方是已在api授权认证平台注册。如果应用方已在api授权认证平台注册，可以执行步骤603，如果应用方未在api授权认证平台注册，则执行步骤604。
120.本技术中，可以根据第二应用标识和第二应用密钥，查询应用标识与应用密钥之间的对应关系，如果对应关系中存在第二应用标识和第二应用密钥、且第二应用标识与第二应用密钥对应，可以确定应用方已在api授权认证平台注册，如果对应关系中没有第二应用标识或第二应用密钥，或者第二应用标识与第二应用密钥不对应，可以确定应用方未在api授权认证平台注册。
121.步骤603，根据第二应用标识，查询应用方对应的api列表。
122.本技术中，应用方若api授权认证平台注册成功，可以规定应用方可以调用的api。本技术中，如果应用方已在api授权认证平台注册，那么api授权认证平台可以查询应用方对应的api列表。其中，api列表中包含应用方可以调用的api的标识。
123.步骤604，返回应用方没有权限调用api授权认证平台的api的提示信息。
124.本技术中，如果应用方未在api授权认证平台注册，说明应用方没有权限调用目标api，api授权认证平台可以向应用方返回应用方没有权限调用api授权认证平台的api的提示信息。
125.步骤605，在api列表中是否包含目标api的标识。如果api列表中包含目标api的标识，可以执行步骤606，如果api列表中未包含目标api的标识，执行步骤607。
126.步骤606，允许应用方调用目标api。
127.本技术中，如果api列表中包含目标api的标识，说明应用方可以调用目标api，因此可以允许应用方调用目标api。
128.步骤607，返回应用方没有权限调用目标api的提示信息。
129.本技术中，如果api列表中未包含目标api的标识，说明应用方虽然已经在api授权认证平台注册但没有权限调用目标api，api授权认证平台可以向应用方返回应用方没有权限调用目标api的提示信息。
130.本技术实施例中，在接收应用方发送的服务请求之前，还可以获取应用方的api调用请求，根据调用请求中的第二应用标识和所述第二应用密钥，确定应用方是否在api授权认证平台已注册，如果应用方已在api授权认证平台注册，根据第二应用标识，查询应用方对应的api列表，如果api列表中包含目标api的标识，则允许应用方调用目标api。由此，在接收应用方发送的服务请求之前，可以验证先应用方是否有权限调用目标api，若允许应用
方调用目标api，还可以进一步对服务请求中的数字签名进行验证，进一步提高了安全性。
131.在本技术的一个实施例中，api授权认证平台还可以统计目标时间段内api授权认证平台的接口访问信息，并展示统计的接口访问信息。
132.其中，目标时间段比如可以是每天中一个或多个时间段，本技术对此不作限定。
133.其中，接收访问信息可以包括目标时间段内访问的api有哪些，访问同一api的次数等。
134.本技术中，在展示接口访问信息时，可以文本的形式展示，也可以图标的形式展示，或者是其他形式展示，本技术对此不作限定。
135.本技术实施例中，通过目标时间段内api授权认证平台的接口访问信息，并展示接口访问信息，可以便于观察接口的访问情况。
136.为了便于理解，下面以应用方为应用客户端，刷脸调用为例，结合图7进行说明，图7是本技术实施例提供的一交互流程示意图。
137.其中，上述的api授权认证平台可以包括认证平台客户端和认证平台服务端。
138.如图7所示，该交互流程包括步骤701-步骤711。
139.步骤701，用户发起刷脸调用。
140.步骤702，应用客户端将认证刷脸请求发送给应用服务端。
141.本技术中，应用服务端可以利用应用方私钥，采用rsa算法对刷脸信息进行加密，得到签名后的刷脸信息。
142.步骤703，应用服务端向应用客户端返回签名后的刷脸信息。
143.步骤704，应用客户端调用认证刷脸api。
144.步骤705，认证平台客户端将认证刷脸请求发送给认证平台服务端。
145.步骤706，认证平台服务端完成刷脸调用。
146.本技术中，认证平台服务端可以使用应用方公钥解密数字签名，解密成功表示认证刷脸请求是合法请求。认证平台服务端调用真正的刷脸业务操作，使用认证平台私钥加密刷脸结果。
147.步骤707，认证平台服务端向认证平台客户端返回加密刷脸结果。
148.步骤708，认证平台客户端向应用客户端返回加密刷脸结果。
149.步骤709，应用客户端向应用服务端同步加密的刷脸业务结果。
150.本技术中，应用服务端可以利用认证平台公钥对加密的刷脸结果验证签名，如果确认结果可以使用平台公钥解开，应用服务端返回最终刷脸结果给应用客户端。
151.步骤710，应用服务端向应用客户端返回最终刷脸结果。
152.步骤711，应用客户端显示最终刷脸结果。
153.为了便于理解，下面以应用方为应用服务端，利率查询请求为例，结合图8进行说明，图8是本技术实施例提供的另一交互流程示意图。
154.如图8所示，该交互流程包括步骤801-步骤808。
155.步骤801，用户进行业务操作请求查询利率公开信息。
156.步骤802，应用服务端获取利率公开信息查询请求。
157.本技术中，应用服务端用应用密钥对请求参数进行加密生成数字签名，将数字签名拼接在请求参数后面一同发送给认证平台。
158.步骤803，应用服务端将利率公开信息查询请求发送给认证平台
159.步骤804，认证平台验证签名。
160.本技术中，认证平台采用相同的签名算法，利用应用密钥对请求参数进行加密，得到一个数字签名(也即上述的第三数字签名)，将该数字签名与请求中的数字签名进行对比，以确定请求中的数字签名是否验证通过。
161.步骤805，如果验证通过，认证平台将利率公开信息查询请求转发给利率业务服务器。
162.本技术中，认证平台可以获取利率业务服务器返回的查询结果。
163.步骤806，利率业务服务器将查询结果返回给认证平台；
164.步骤807，认证平台对查询结果用平台私钥加密后返回给应用服务端。
165.步骤808，应用服务端用平台公钥验证签名并返回查询结果
166.步骤809，应用服务端将查询结果返回给应用客户端。
167.为了便于理解，下面以个人信息范围为例，结合图9进行说明，图9是本技术实施例提供的另一交互流程示意图。
168.如图9所示，该交互流程包括步骤901-步骤913。
169.步骤901，用户进行业务操作触发授权。
170.步骤902，应用服务端申请用户授权。
171.其中，申请的授权范围为用户个人信息。
172.步骤903，应用服务端附上应用方的应用标识、应用回调url将用户重定向到官方授权页面，请求地址。
173.步骤904，用户同意授权。
174.本技术中，用户同意授权，授权服务器收到用户请求，验证应用回调url合法性，若应用标识和应用密钥正确，生成授权码。
175.步骤905，授权服务器把授权码重定向到回调url。
176.本技术中，授权服务器把授权码重定向到回调url，应用服务端取到授权码。
177.步骤906，应用服务端向授权服务器请求访问令牌。
178.本技术中，应用服务端根据授权码、应用标识和应用密钥，向授权服务器请求访问令牌，以获取访问令牌。
179.步骤907，认证平台向应用服务端返回访问令牌。
180.本技术中，认证平台验证授权码、应用标识和应用密钥，向应用服务端返回访问令牌。其中，访问令牌的有效时间为30分钟。
181.步骤908，应用服务端向认证平台发送访问用户个人信息请求。
182.本技术中，应用服务端根据访问令牌访问用户个人信息的业务接口。
183.步骤909，认证平台验证访问令牌，并将访问用户个人信息请求转发给资源服务器。
184.步骤910，资源服务器返回个人信息到认证平台。
185.步骤911，认证平台用平台私钥对个人信息进行加密，并返回给应用服务端。
186.步骤912，应用服务端对加密的个人信息用平台私钥解密，并返回给授权页面。
187.步骤913，应用客户端显示个人信息。
188.与上述图1、图3-图6实施例提供的api授权认证处理方法相对应，本技术还提供一种api授权认证处理装置，由于本技术实施例提供的api授权认证处理装置与上述图1、图3-图6实施例提供的api授权认证处理方法相对应，因此在api授权认证处理方法的实施方式也适用于本技术实施例提供的api授权认证处理装置，在本技术实施例中不再详细描述。图10是本技术一实施例提供的api授权认证处理装置的结构示意图。
189.参照图10，该api授权认证处理装置1000可以包括：
190.接收模块1010，被配置为接收应用方在调用所述api授权平台的目标api时发送的服务请求，其中，所述服务请求中包括与所述服务请求参数关联的第一数字签名；
191.验证模块1020，被配置为对所述第一数字签名进行验证；
192.转发模块1030，被配置为在所述第一数字签名通过验证的情况下，将所述服务请求转发给对应的业务服务器，以获取所述业务服务器返回的所述服务请求对应的服务结果；
193.发送模块1040，被配置为将第二数字签名返回给应用方，以使应用方获取利用第一私钥对应的第一公钥对第二数字签名验证后的结果。
194.在本技术实施例一种可能的实现方式中，所述发送模块1040，被配置为：
195.利用所述api授权认证平台的第一私钥对所述服务结果进行加密，得到第二数字签名；
196.将第二数字签名返回给所述应用方，以使应用方获取利用第一私钥对应的第一公钥对第二数字签名验证后的结果。
197.在本技术实施例一种可能的实现方式中，所述第一数字签名是利用所述应用方的第二私钥加密生成的，所述验证模块1020，被配置为：
198.获取所述第二私钥对应的第二公钥；
199.根据所述第二公钥，对所述第一数字签名进行验证。
200.在本技术实施例一种可能的实现方式中，所述第一数字签名是利用所述应用方的第一应用密钥加密生成的，所述验证模块1020，被配置为：
201.根据所述服务请求中的第一应用标识，查询应用标识与应用密钥的对应关系，以确定所述第一应用标识对应的所述第一应用密钥；
202.利用所述第一应用密钥，对所述服务请求中的请求参数进行加密，生成第三数字签名；
203.根据所述第三数字签名，对所述第一数字签名进行验证。
204.在本技术实施例一种可能的实现方式中，所述接收模块1010，还被配置为接收所述应用方发送的注册请求；
205.所述发送模块1040，还被配置为在所述注册请求验证通过的情况下，向所述应用方返回所述第一应用标识和所述第一应用密钥。
206.在本技术实施例一种可能的实现方式中，所述接收模块1010，还被配置为获取所述应用方的api调用请求，其中，所述调用请求中包括所述目标api的标识、所述应用方的第二应用标识及第二应用密钥；
207.该装置还可以包括：
208.确定模块，被配置为根据所述第二应用标识和所述第二应用密钥，确定所述应用
方是已在所述api授权认证平台注册；
209.第一查询模块，被配置为在确定所述应用方已在所述api授权认证平台注册的情况下，根据所述第二应用标识，查询所述应用方对应的api列表；在所述api列表中包含所述目标api的标识的情况下，允许所述应用方调用所述目标api。
210.在本技术实施例一种可能的实现方式中，所述转发模块1030，被配置为：
211.确定所述服务请求对应的请求路径；
212.按照所述请求路径将所述服务请求转发到所述业务服务器。
213.在本技术实施例一种可能的实现方式中，所述转发模块1030，被配置为：
214.在所述服务请求中包括统一资源定位符的情况下，根据所述统一资源定位符，将所述服务请求转发到指定的所述业务服务器。
215.在本技术实施例一种可能的实现方式中，该装置还可以包括：
216.统计模块，被配置为统计目标时间段内所述api授权认证平台的接口访问信息；
217.展示模块，被配置为展示所述接口访问信息。
218.在本技术实施例一种可能的实现方式中，所述接收模块1010，还被配置为获取api注册请求，其中，所述创建请求中包括待注册api的标识；
219.该装置还可以包括：
220.第二查询模块，还配置根据所述待注册api的标识，查询api数据库；
221.添加模块，被配置为在所述api数据库中未包含所述待注册api的标识的情况下，将所述待注册api的标识添加到所述api数据库。
222.本技术实施例中，可以通过对第一数字签名进行验证，实现对应用方的身份进行验证，若验证通过，说明应用方有权限调用目标api，实现了对api授权认证管理，从而应用方可以通过api授权认证平台调用服务提供方的api，降低了应用方与服务提供方之间的对接成本。
223.需要说明的是，应理解以上装置的各个模块的划分仅仅是一种逻辑功能的划分，实际实现时可以全部或部分集成到一个物理实体上，也可以物理上分开。且这些模块可以全部以软件通过处理元件调用的形式实现；也可以全部以硬件的形式实现；还可以部分模块通过处理元件调用软件的形式实现，部分模块通过硬件的形式实现。
224.图11为本技术一实施例提供的电子设备的结构示意图。如图11所示，该电子设备可以包括：收发器1101、处理器1102、存储器1103。
225.处理器1102执行存储器存储的计算机执行指令，使得处理器1102执行上述实施例中的方案。处理器1102可以是通用处理器，包括中央处理器cpu、网络处理器(network processor，np)等；还可以是数字信号处理器dsp、专用集成电路asic、现场可编程门阵列fpga或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。
226.存储器1103通过系统总线与处理器1102连接并完成相互间的通信，存储器1103用于存储计算机程序指令。
227.收发器1101可以用于获取待运行任务和待运行任务的配置信息。
228.系统总线可以是外设部件互连标准(peripheral component interconnect，pci)总线或扩展工业标准结构(extended industry standard architecture，eisa)总线等。系统总线可以分为地址总线、数据总线、控制总线等。为便于表示，图中仅用一条粗线表示，但
并不表示仅有一根总线或一种类型的总线。收发器用于实现数据库访问装置与其他计算机(例如客户端、读写库和只读库)之间的通信。存储器可能包含随机存取存储器(random access memory，ram)，也可能还包括非易失性存储器(non-volatile memory)。
229.本技术实施例提供的api授权认证平台可配置在上述电子设备中。
230.在示例性实施例中，还提供了一种包括指令的计算机可读存储介质，例如包括指令的存储器，上述指令可由电子设备的处理器执行以完成上述任一实施例提出的方法。可选地，计算机可读存储介质可以是rom、随机存取存储器(ram)、cd-rom、磁带、软盘和光数据存储设备等。
231.在示例性实施例中，还提供一种计算机程序产品，包括计算机程序/指令，其特征在于，所述计算机程序/指令被处理器执行时实现上述任一实施例提出的方法。
232.本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本技术的其它实施方案。本技术旨在涵盖本技术的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本技术的一般性原理并包括本技术未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本技术的真正范围和精神由下面的权利要求指出。
233.应当理解的是，本技术并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本技术的范围仅由所附的权利要求来限制。