应用程序接口调用方法、装置、存储介质及电子设备

技术领域

本申请涉及数据安全领域，尤其涉及一种应用程序接口调用方法、装置、存储介质及电子设备。

背景技术

在企业定制业务中，手机厂商可以根据客户需求，给企业客户的应用程序安装包(Application Package，APK)通过必要的系统应用程序接口(Application ProgrammingInterface，API)调用权限。但是由于手机上安装的系统(例如Android系统)的API不可随意对外开放，只能根据客户需求按需授权，因此需要用证书来进行系统API的授权管理。现有的证书方案，只解决了授权有效期和证书来源问题，手机用户的数据安全无法得到保障。

发明内容

本申请实施例提供了一种应用程序接口调用方法、装置、存储介质及电子设备，可以保障手机用户的数据安全。

第一方面，本申请实施例提供了一种应用程序接口API调用方法，包括：

在应用程序安装包APK中的证书校验通过的情况下，接收所述APK发起的调用目标应用程序接口API的请求；其中，所述请求中携带所述目标API的编号；

响应于所述请求，判断所述目标API的编号是否与所述证书中授权的任意一个API的编号一致；

若所述目标API的编号与所述证书中授权的任意一个API的编号一致，则向所述APK开放所述目标API。

第二方面，本申请实施例提供了一种应用程序接口API调用装置，包括：

接收模块，用于在应用程序安装包APK中的证书校验通过的情况下，接收所述APK发起的调用目标应用程序接口API的请求；其中，所述请求中携带所述目标API的编号；

判断模块，用于响应于所述请求，判断所述目标API的编号是否与所述证书中授权的任意一个API的编号一致；

开放模块，用于若所述目标API的编号与所述证书中授权的任意一个API的编号一致，则向所述APK开放所述目标API。

第三方面，本申请实施例提供了一种计算机存储介质，所述计算机存储介质存储有多条指令，所述指令适于由处理器加载并执行本申请实施例第一方面提供的方法步骤。

第四方面，本申请实施例提供了一种电子设备，包括：处理器和存储器；其中，所述存储器存储有计算机程序，所述计算机程序适于由处理器加载并执行本申请实施例第一方面提供的方法步骤。

本申请一些实施例提供的技术方案带来的有益效果至少包括：

在本申请实施例可以对单个API进行编号，便于对高危API的授权管理。当APK请求调用某高危API时，若该API的编号与授权证书中的允许授权的高危编号一致，则校验通过，向APK开放该API。相比于现有技术中对多个API进行分组管理，然后以分组的形式对API进行批量授权，本申请实施例提供的对高危API进行单个控制的方法，可以保护用户数据的安全。

附图说明

为了更清楚地说明本申请实施例中的技术方案，下面将对实施例中所需使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1为本申请实施例提供的一种API调用系统的架构示意图；

图2为本申请实施例提供的一种API调用方法的流程示意图；

图3为本申请实施例提供的另外一种API调用方法的流程示意图；

图4为本申请实施例提供的另外一种API调用方法的流程示意图；

图5为本申请实施例提供的另外一种API调用方法的流程示意图；

图6为本申请实施例提供的另外一种API调用方法的流程示意图；

图7为本申请实施例提供的一种证书权限校验的流程示意图；

图8为本申请实施例提供的一种API调用装置的结构示意图；

图9为本申请实施例提供的一种电子设备的结构示意图。

具体实施方式

下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本申请相一致的所有实施方式。相反，它们仅是如所附权利要求书中所详述的、本申请的一些方面相一致的装置和方法的例子。

在本申请的描述中，需要理解的是，术语“第一”、“第二”等仅用于描述目的，而不能理解为指示或暗示相对重要性。对于本领域的普通技术人员而言，可以具体情况理解上述术语在本申请中的具体含义。此外，在本申请的描述中，除非另有说明，“多个”是指两个或两个以上。“和/或”，描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。字符“/”一般表示前后关联对象是一种“或”的关系。

首先介绍本申请实施例适用的一种应用场景：

企业A拥有一款企业级APP，该APP可以安装于手机中，用于管理公司的大小事务，例如考勤、人事变动、部门组织管理、任务派发、员工沟通等。为了便于管理企业数据，以及管理员工数据，该APP安装于手机时，可以调用手机的相关权限。企业A可以向供应商申请企业定制服务。企业A可以根据自身需求，申请该APP对应的APK需要的系统API调用权限。可以知道，经过授权的API才能被该APP调用。

图1为本申请实施例提供的一种API调用系统的结构示意图。如图1所示，API调用系统可以包括：电子设备10。电子设备10可搭载操作系统，用于支撑电子设备10实现各种功能。电子设备10中可安装一个或多个应用程序(application，APP)。电子设备10可以为不同的APP开放不同的API，以使该APP具备相应的权限，获取系统数据。例如但不限于获取联系人信息的权限，获取电话权限，获取相册照片的权限等。每个APP对应一个APK，APK中存储有相应的证书，证书可以作为电子设备10对该APP进行鉴权的依据。当该APP请求调用操作系统的某API时，电子设备10可以根据该APP的APK中包含的证书来鉴别该APP是否有调用该API的权限。具体可以是查看证书中授权的API中是否包含该APP请求调用的API。若是，则表明该APP具备调用该API的权限。

本申请实施例中，电子设备10可以是手机、平板电脑、桌面型、膝上型、笔记本电脑、超级移动个人计算机(Ultra-mobile Personal Computer，UMPC)、手持计算机、上网本、个人数字助理(Personal Digital Assistant，PDA)、可穿戴电子设备、虚拟现实设备等。

其中，该操作系统例如但不限于搭载于移动终端设备(如手机、平板电脑)上的安卓(Android)系统、IOS系统、塞班(Symbian)系统等，该操作系统还可以是搭载于计算机的Windows系统、Linux系统等。本申请实施例对此不作限定。

进一步地，API调用系统除了可以包括电子设备10以外，还可以包括服务器20。其中，服务器20可以是授权方(即供应商)的运维服务器，用于管理客户订单。客户订单内容可以包括授权对应证书的授权设备范围、授权时间等。每个客户订单有一个客户订单编号，每个客户订单编号具有唯一性和确定性。也就是说，根据客户订单编号即可确定其对应的客户订单。

进一步地，API调用系统除了可以包括电子设备10及服务器20以外，还可以包括终端30。其中，终端30可以与服务器20连接，便于客户(企业)向供应商申请企业定制服务。其中，终端30可以是手机、平板电脑、桌面型、膝上型、笔记本电脑、超级移动个人计算机(Ultra-mobile Personal Computer，UMPC)、手持计算机、上网本、个人数字助理(PersonalDigital Assistant，PDA)、可穿戴电子设备、虚拟现实设备等。

接下来结合图1示出的API调用系统的架构，介绍本申请实施例提供的API调用方法。图2示例性示出了本申请实施例提供的一种API调用方法的流程示意图。如图2所示，API调用方法至少可以包括以下几个步骤：

S201：在APK中的证书校验通过的情况下，接收APK发起的调用目标API的请求。

具体地，电子设备系统开机时会进行APK扫描，或者有新的APK安装时，系统会判断APK中是否存在证书，若存在，系统会对证书进行权限校验。只有在证书的权限校验成功的情况下，系统才会允许该APK调用授权的API。

具体地，APK发起的调用目标API的请求可以是在APP开始运行时自动发起的，也可以是用户在使用APP的过程中触发的。例如用户在使用微信的过程中，想要开启扫一扫功能，则需要系统开放摄像头的API，以使微信调用摄像头实现扫一扫功能。

S202：响应于上述请求，判断目标API的编号是否与证书中授权的任意一个API的编号一致。

具体地，通常系统可提供大量的API，例如但不限于500个、1000个等。而现有技术中通过将所有可提供的API进行分组，然后以分组的形式批量授权。例如，系统可提供的API有500个，100个为一组，可分成5组。那么企业在定制业务时，可申请某一组或某几组的API。也就是说，现有的API授权方式为批量授权。而实际上存在部分API涉及到用户隐私，即为安全级别较高的接口，本申请实施例中将其称为高危API，本申请实施例中可以将非高危API称为通用API。对通用API进行分组后可以得到通用API组。对于高危API，本申请实施例中可以对其进行更加精细化的管理，例如可以为每个高危API进行独立的编号，企业在定制业务时，对于高危API可以单独申请，申请通过的高危API的编号可以写入证书中。

表1示例性示出了系统API及其分组或编号的对应关系，如表1所示，系统可提供的API一共有505个，其中有500个API为非高危API，可进行批量授权，100个为一组。另外，有5个为高危API，可进行单独授权，编号从001-005。企业在定制服务时，可申请某一组或某几组的非高危API，还可以申请某一个或某几个高危API。可以知道，分组授权的API没有对应的编号，单个授权的API也没有分组号，故由NA表示。

表1系统API及其分组或编号的对应关系

需要说明的是，本申请实施例中的目标API为前述高危API，具有独立的编号。响应于上述请求，电子设备可以判断目标API的编号是否与证书中授权的任意一个API的编号一致。

S203：若目标API的编号与证书中授权的任意一个API的编号一致，则向APK开放目标API。

具体地，目标API的编号与证书中授权的任意一个API的编号一致，表明目标API已被授权，故该APK有调用该目标API的权限，从而电子设备可向APK开放该目标API。其中，证书中授权的API可以包括一个或多个。

示例性地，以上述表1为例，企业A在申请授权API时，选择了分组为第二组的API及编号为001、003的API，则表明企业A申请的API为API 100-API 199、API500及API 502。证书中可记载的内容即为第二组、001、003。当该企业A对应的APP的APK安装于电子设备时，在APP的使用过程中，APK发起了调用API 500的请求。响应于该请求，电子设备可判断该APK对应的证书中授权的API中是否包含API 500对应的编号001。显然，证书中授权的API的编号中包含001，则表明该APK有权限调用API 500，则电子设备允许APK调用API 500。若在APP的使用过程中，APK发起了调用API 504的请求。响应于该请求，电子设备可判断该APK对应的证书中授权的API中是否包含API 504对应的编号005。显然，证书中授权的API的编号中不包含005，则表明该APK无权限调用API 504，则电子设备不允许APK调用API 500。

本申请实施例可以对单个API进行编号，便于对高危API的授权管理。当APK请求调用某高危API时，若该API的编号与授权证书中的允许授权的高危编号一致，则校验通过，向APK开放该API。相比于现有技术中对多个API进行分组管理，然后以分组的形式对API进行批量授权，本申请实施例提供的对高危API进行单个控制的方法，可以保护用户数据的安全。

图3示例性示出了本申请实施例提供的另外一种API调用方法的流程示意图。如图3所示，API调用方法至少可以包括以下几个步骤：

S301：校验证书的签名密钥是否正确。

具体地，证书的签名密钥可用于校验证书来源的安全性。只有证书记录的密钥与其运行的设备的密钥匹配时，方可表明证书是安全的。

S302：在签名密钥正确的情况下，获取证书的授权生效期及授权有效时长。

具体地，若签名密钥正确，表明证书是安全的。则在签名密钥正确的情况下，电子设备可获取证书的授权生效期及授权有效时长。

可选地，证书的授权生效期及授权有效时长可被记录于运维服务器。电子设备可从运维服务器获取该证书的授权生效期及授权有效时长。

具体地，证书中可以记录客户订单编号，电子设备可以根据客户订单编号到运维服务器上溯源订单进行鉴权。也就是说，电子设备可以根据客户订单编号从运维服务器中查询该客户订单编号对应的该证书的授权生效期及授权有效时长。

可选地，证书的授权生效期及授权有效时长可被记录于证书中。电子设备可直接从证书中获取该证书的授权生效期及授权有效时长可被记录于。

可选地，证书的授权生效期可被记录于运维服务器中，而证书的授权有效时长可被记录于证书中。电子设备可从运维服务器中获取证书的授权生效期，并从证书中获取证书的授权有效时长。

可选地，证书的授权生效期可被记录于证书中，而证书的授权有效时长可被记录于运维服务器中。电子设备可从证书中获取证书的授权生效期，并从运维服务器中获取证书的授权有效时长。

其中，证书的授权生效期即为该证书授权的起始时刻。证书的授权有效时长即为该证书的有效时长。

本申请实施例中，将从运维服务器获取证书的授权生效期及授权有效时长的方式称为线上鉴权，将从证书中获取证书的授权生效期及授权有效时长的方式称为离线鉴权。可以知道，线上鉴权的前提是需要电子设备处于联网状态，而离线鉴权时电子设备无需联网。

S303：根据授权生效期及授权的有效时长确定授权有效时间范围。

具体地，结合授权生效期及授权的有效时长即可确定证书的有效时间范围。

示例性地，证书的授权生效期可以是2020年1月1日08:51:09。证书的授权有效时长可以是1年。那么，该证书的授权有效时间范围即为2020年1月1日08:51:09至2021年1月1日08:51:09。

不限于记录授权生效期及授权的有效时，证书或运维服务器中还可以直接记录证书的授权有效时间范围，本申请实施例对此不作限定。

S304：若当前时刻在授权有效时间范围内，则证书校验通过。

具体地，当前时刻即为电子设备当前的系统时间。如果当前时刻在授权有效时间范围内，表明证书在授权的有效时间内，则证书校验通过。

S305：接收APK发起的调用目标API的请求。

具体地，S305与S201一致，此处不再赘述。

S306：响应于上述请求，判断目标API的编号是否与证书中授权的任意一个API的编号一致。

具体地，S306与S202一致，此处不再赘述。

S307：若目标API的编号与证书中授权的任意一个API的编号一致，则向APK开放目标API。

具体地，S307与S203一致，此处不再赘述。

本申请实施例可以通过证书的有效时间对证书进行权限校验。其中，权限校验的方式有两种：线上鉴权、本地鉴权。通过证书的有效时间对证书进行权限校验可以保证证书的安全性。在证书校验通过后再对API的调用进行鉴权，可以保证电子设备的用户数据的安全。

图4示例性示出了本申请实施例提供的另外一种API调用方法的流程示意图。如图4所示，API调用方法至少可以包括以下几个步骤：

S401：校验证书的签名密钥是否正确。

具体地，S401与S301一致，此处不再赘述。

S402：在签名密钥正确的情况下，验证包含该证书的APK的包名与证书中的授权APK包名是否一致。

具体地，若签名密钥正确，表明证书是安全的。则在签名密钥正确的情况下，电子设备可验证证书包括的授权APK包名与发起请求的APK的包名是否一致。

其中，授权APK包名即为允许调用证书授权范围内API的APK包名。通过APK包名可以锁定该证书适用的APK。

S403：若包含该证书的APK的包名与证书中的授权APK包名一致，验证电子设备的标识与任意一个授权设备的标识是否一致。

具体地，若授权APK包名与发起请求的APK的包名一致，则表明发起请求的APK为该证书适用的APK，则进一步验证电子设备的标识与任意一个授权设备的标识是否一致，从而进一步的锁定该证书适用的电子设备。

具体地，授权设备可以是一个或多个。通过情况下，企业定制服务时会定制大量的电子设备，这些电子设备用于安装该企业定制的APP，从而实现企业定制的相关功能。通过验证电子设备的标识与任意一个授权设备的标识是否一致来确定该证书的使用范围及安全性。

其中，设备标识可以用于唯一的确定该设备。即每个设备都具备不同的设备标识。设备标识可以但不限于为国际移动设备身份码(International Mobile EquipmentIdentity，IMEI)、移动设备识别码(Mobile Equipment Identifier，MEID))、通用唯一识别码(Universally Unique Identifier，UUID)等。

可选地，授权的设备标识可以记录在证书中。

可选地，授权的设备标识可以记录在运维服务器中。

具体地，证书中可以记录客户订单编号，电子设备可以根据客户订单编号到运维服务器上溯源订单进行鉴权。也就是说，电子设备可以根据客户订单编号从运维服务器中查询该客户订单编号对应的授权的设备标识。

本申请实施例中，将从运维服务器获取证书的授权的设备标识的方式称为线上鉴权，将从证书中获取证书的授权的设备标识的方式称为离线鉴权。可以知道，线上鉴权的前提是需要电子设备处于联网状态，而离线鉴权时电子设备无需联网。

S404：若电子设备的标识与任意一个授权设备的标识一致，获取证书的授权生效期及授权有效期。

具体地，获取证书的授权生效期及授权有效期可参考S302中的相关描述，此处不再赘述。

S405：根据授权生效期及授权的有效时长确定授权有效时间范围。

具体地，S405与S303一致，此处不再赘述。

S406：若当前时刻在授权有效时间范围内，则证书校验通过。

具体地，S406与S304一致，此处不再赘述。

S407：接收APK发起的调用目标API的请求。

具体地，S305与S201一致，此处不再赘述。

S408：响应于上述请求，判断目标API的编号是否与证书中授权的任意一个API的编号一致。

具体地，S408与S202一致，此处不再赘述。

S409：若目标API的编号与证书中授权的任意一个API的编号一致，则向APK开放目标API。

具体地，S409与S203一致，此处不再赘述。

本申请实施例可以通过APK的包名及设备标识来验证证书的安全性。只有当APK的包名与证书中授权的APK的包名一致，且设备标识与证书中授权的设备标识一致，才表明该证书是安全的。通过锁定APK的包名来对证书进行鉴权，便于用户对APK进行升级，而不用重新申请证书。通过设备标识锁定授权的设备范围，可以保证证书的适用范围及安全性。通过APK的包名及设备标识对证书进行校验通过后再对API调用进行鉴权，可以保证电子设备的用户数据的安全。

图5示例性示出了本申请实施例提供的另外一种API调用方法的流程示意图。如图5所示，API调用方法至少可以包括以下几个步骤：

S501：校验证书的签名密钥是否正确。

具体地，S501与S301一致，此处不再赘述。

S502：在签名密钥正确的情况下，验证包含该证书的APK的哈希值与证书中的授权APK的哈希值是否一致。

可以知道，该发起请求的APK即为包含该证书的APK。可能地，该APK在此时还未发起调用某API的请求，但是本申请实施例中，依然可以将包含该证书的APK看作是发起请求的APK。

具体地，若签名密钥正确，表明证书是安全的。则在签名密钥正确的情况下，电子设备可验证证书包括的授权APK的哈希值与发起请求的APK的哈希值是否一致。

其中，授权APK的哈希值可以用来锁定授权APK，并且锁定该授权APK的版本。也就是说，此证书只能用于APK的哈希值与证书记录中哈希值相同的APK，任何其他APK或者对于对该APK的任何修改(如版本升级)都会导致证书失效。

S503：若包含该证书的APK的哈希值与证书中的授权APK的哈希值一致，获取证书的授权生效期及授权有效期。

具体地，获取证书的授权生效期及授权有效期可参考S302中的相关描述，此处不再赘述。

S504：根据授权生效期及授权的有效时长确定授权有效时间范围。

具体地，S503与S303一致，此处不再赘述。

S505：若当前时刻在授权有效时间范围内，则证书校验通过。

具体地，S505与S304一致，此处不再赘述。

S506：接收APK发起的调用目标API的请求。

具体地，S506与S201一致，此处不再赘述。

S507：响应于上述请求，判断目标API的编号是否与证书中授权的任意一个API的编号一致。

具体地，S507与S202一致，此处不再赘述。

S508：若目标API的编号与证书中授权的任意一个API的编号一致，则向APK开放目标API。

具体地，S508与S203一致，此处不再赘述。

本申请实施例可以通过APK的哈希值来验证证书的安全性。只有当APK的哈希值与证书中授权的APK的哈希值一致，才表明该证书是安全的。通过锁定APK的哈希值来对证书进行鉴权，能更加严格的保证证书的安全性。另外，由于本实施例与图4实施例相比，本申请实施例未绑定设备标识，这样可以不对设备进行强制要求，扩大该APK适用的设备范围，使企业对于该APP的管理更加灵活。通过APK的哈希值对证书进行校验通过后再对API调用进行鉴权，可以保证电子设备的用户数据的安全。

图6示例性示出了本申请实施例提供的另外一种API调用方法的流程示意图。如图6所示，API调用方法至少可以包括以下几个步骤：

S601：在满足预设触发条件的情况下，判断APK中是否有证书。

可选地，预设触发条件为电子设备开机。

可选地，预设触发条件为电子设备监听到APK开始安装。

S602：在APK中有证书的情况下，验证证书是否未被篡改。

具体地，证书生成后，可以对证书的整体内容进行加密。在对证书校验时，需要对证书的完整性进行校验。如果证书的内容被篡改过，由于证书的内容做了加密，此时对于证书完整性的校验则无法校验通过，证书授权的内容则无法通过。

S603：若证书未被篡改，则读取证书中的内容。

具体地，若证书完整性校验通过，则表明证书未被篡改，从而表明证书是安全的。进而可以读取证书中的内容。

S604：校验证书的签名密钥是否正确。

具体地，S604与S301一致，此处不再赘述。

S605：在签名密钥正确的情况下，获取证书的授权生效期及授权有效时长。

具体地，S605与S302一致，此处不再赘述。

S606：根据授权生效期及授权的有效时长确定授权有效时间范围。

具体地，S606与S303一致，此处不再赘述。

S607：若当前时刻在授权有效时间范围内，则证书校验通过。

具体地，S607与S304一致，此处不再赘述。

S608：接收APK发起的调用目标API的请求。

具体地，S608与S201一致，此处不再赘述。

S609：响应于上述请求，判断目标API的编号是否与证书中授权的任意一个API的编号一致。

具体地，S609与S202一致，此处不再赘述。

S610：若目标API的编号与证书中授权的任意一个API的编号一致，则向APK开放目标API。

具体地，S610与S203一致，此处不再赘述。

本申请实施例可以先校验证书的完整性，确定证书完整后再对证书的内容进行验证，可以进一步确保证书的安全性，保证电子设备的用户数据的安全。

本申请实施例还提供了一种证书，该证书可以包括以下几项内容：

A)应用包名：授权允许调用证书范围内API的APK包名。

具体地，锁定了APK的包名，即可确保其他APK无法调用API。应用包括具体可用于图3实施例的S402中。

B)LicenceCode：客户订单编号。

具体地，客户订单编号具有唯一性、确定性。此项内容在鉴权时使用。客户订单在授权方的运维服务器中集中管理，订单规定了授权对应证书的授权设备范围、授权时间。LicenceCode具体可用于线上鉴权时从运维服务器获取证书的授权生效期及授权有效时长。LicenceCode还可用于线上鉴权时从运维服务器获取授权设备标识。

C)Permissions:授予的权限分组

具体地，权限分组分为通用API组和高危API组。

具体地，通用API组包含了安全级别较低的所有API，即意味着申请了通用API组后，此证书授予APK可以使用通用API组中的所有API。

具体地，高危API组，指安全级别较高的API。此组授权仅仅表示此证书授予对象(APK)可以去调用高危API接口。

D)Apis：高危API的独立编号。

每一个高危API都有一个独立的编号，客户申请了对应的API后，需要把对应的授权编号记录在这部分内容中。此证书授权的APK只能调用Apis授权的高危API，从而实现单个API的精细化管控。Apis可以用于本申请实施例中对目标API的调用。

E)DeviceID：允许授权APK使用的设备编号。

具体地，允许授权APK使用的设备编号即为该APK适用的设备范围。DeviceID可以用于电子设备通过离线鉴权的方式验证电子设备的标识是否与任意一个授权设备的标识一致。

F)ValidFrom:授权生效期。

具体地，授权生效期即为该证书生效的时刻。ValidFrom可以与ValidTo结合，用于判断证书的授权有效时间范围。

G)ValidTo：授权有效期。

具体地，授权生效期即为该证书授权时长。ValidTo可以与ValidFrom结合，用于判断证书的授权有效时间范围。

具体地，证书的授权有效时间范围可以用于电子设备通过离线鉴权的方式验证当前时刻是否在证书的有效时间范围内。

H)TYPE：证书鉴权类型。

Online：在线鉴权，即证书的授权的有效期和授权设备范围，在授权方的运维服务器上完成，需要联网。

Offline：本地鉴权，又称为离线鉴权。即证书的授权的有效期和授权设备范围在所运行的电子设备上完成，无需联网。

I)ApkHash：证书授权对象APK的哈希值，用来锁定授权APK，即此证书只能用于APK哈希值与证书记录中哈希值相同的APK，任何其他APK或者APK的任何修改，都会导致证书失效。ApkHash可用于图5实施例的S502中。

J)Signature：证书签名密钥。

用来校验证书来源的安全性。只要证书记录的密钥，和所运行设备的密钥匹配时，才表示证书是安全的。

需要说明的是，证书包含的以上内容的顺序或者编号不限于上述列举的顺序或者编号，在具体实现中证书包含的以上内容还可以有其他的顺序或者编号，本申请实施例对此不作限定。

图7示例性示出了本申请实施例提供的另外一种证书权限校验的流程示意图。如图7所示，证书权限校验的流程至少可以包括以下几个步骤：

S701：开机扫描APK或监听到有新的APK安装。

具体地，开机扫描APK或监听到有新的APK安装即可理解为图6实施例S601中提到的触发条件。具体可参考S601的描述，此处不再赘述。

S702：判断APK中是否有证书。若是，执行S703，若否，鉴权失败。

S703：判断证书是否未被篡改。若是，执行S704，若否，鉴权失败。

具体地，S703与S602一致，此处不再赘述。

S704：判断证书中签名密钥和系统签名密钥是否匹配。若是，执行S705，若否，鉴权失败。

具体地，S703与S301一致，此处不再赘述。证书中签名密钥可以通过证书中的第J)项Signature来确定。

S705：判断包含该证书的APK的包名与证书中的授权APK包名是否匹配。若是，执行S706，若否，鉴权失败。

具体地，S703与S402一致，此处不再赘述。证书中的授权APK包名可以通过证书中的第A)项来确定。

S706：判断包含该证书的APK的哈希值与证书中授权APK的哈希值是否匹配。若是，执行S707，若否，鉴权失败。

具体地，S703与S503一致，此处不再赘述。证书中的授权APK的哈希值可以通过证书中的第I)项来确定。

S707：判断是否为离线鉴权。若是，执行S710；若否，执行S708。

具体地，是否为离线鉴权可以通过证书中的第H)项证书鉴权类型(TYPE)来确定。

S708：请求服务器鉴权。

具体地，请求服务器鉴权即为线上鉴权。电子设备可以通过证书中的客户订单编号从服务器中查找该客户订单编号对应的授权生效时间、授权有效时长及授权设备标识等。证书中的客户订单编号可以通过证书中的第B)项来确定。

S709：判断服务器鉴权是否通过。若是，鉴权通过，若否，鉴权失败。

具体地，若电子设备当前时刻在授权有效时间范围内，电子设备的编号与任意一个授权设备标识一致，则服务器鉴权通过。否则，服务器鉴权失败。

其中，授权有效时间范围可由授权生效时间、授权有效时长确定。

S710：判断当前设备ID是否在证书的设备ID列表中。若是，执行S711，若否，鉴权失败。

具体地，若为离线鉴权，证书中可记载授权设备的标识(ID)。授权设备的标识可以通过证书中的第E)项来确定。

具体地，S710可参考S403中关于离线鉴权部分的相关描述，此处不再赘述。

S711：判断当前设备的时间是否在证书有效期内。若是，鉴权通过，若否，鉴权失败。

具体地，若为离线鉴权，证书中可记载证书的授权生效时间、授权有效时长。

具体地，S711可参考S303中关于离线鉴权部分的相关描述，此处不再赘述。授权生效时间即为收钱生效期，可以通过证书中的第F)项来确定。授权有效时长即为授权有效期，可以通过证书中的第G)项来确定。

本申请实施例通过了一种完整的证书权限校验的流程，通过对证书的完整性、密钥、授权的APK的包名、授权的APK的哈希值、授权的设备ID以及授权的证书的有效时间范围等各项内容进行鉴权，在所有的内容鉴权通过的情况下，证书的鉴权才能通过，可以最大限度的保证证书的安全性，从而保证电子设备的用户数据的安全。

可以知道，不限于上述图3-图7中提到的对于证书的校验方式，在具体实现中还可以根据企业用户的需求，从证书包含的第A)项-第J)项中选择其他的校验组合方式对证书进行校验，本申请实施例对于证书的校验方式不作限定。

下述为本申请装置实施例，可以用于执行本申请方法实施例。对于本申请装置实施例中未披露的细节，请参照本申请方法实施例。

请参见图8，其示出了本申请一个示例性实施例提供的API调用装置的结构示意图。该API调用装置可以通过软件、硬件或者两者的结合实现成为电子设备的全部或一部分。API调用装置80可以包括：接收模块810、判断模块820及开放模块830。其中：

接收模块810，用于在应用程序安装包APK中的证书校验通过的情况下，接收所述APK发起的调用目标应用程序接口API的请求；其中，所述请求中携带所述目标API的编号；

判断模块820，用于响应于所述请求，判断所述目标API的编号是否与所述证书中授权的任意一个API的编号一致；

开放模块830，用于若所述目标API的编号与所述证书中授权的任意一个API的编号一致，则向所述APK开放所述目标API。

在一些可能的实施例中，API调用装置80还包括：校验模块，用于在接收模块810接收所述APK发起的调用目标应用程序接口API的请求之前，校验所述证书。

在一些可能的实施例中，所述证书包括签名密钥；

校验模块，包括：

校验单元，用于校验所述证书的所述签名密钥是否正确；

获取单元，用于在所述签名密钥正确的情况下，获取所述证书的授权生效期及授权有效时长；

确定单元，用于根据所述授权生效期及授权有效时长确定授权有效时间范围；

若所述确定单元确定当前时刻在所述授权有效时间范围内，则所述证书校验通过。

在一些可能的实施例中，所述证书还包括鉴权类型，所述鉴权类型为在线鉴权；

所述获取单元，具体用于从服务器获取所述证书的授权生效期及所述授权有效时长。

在一些可能的实施例中，所述证书还包括所述授权生效期及所述授权有效时长。

在一些可能的实施例中，所述证书还包括授权APK包名；

所述获取单元，具体用于：

在所述签名密钥正确的情况下，验证包含所述证书的APK与所述证书中的授权APK包名是否一致；

若包含所述证书的APK与所述授权APK包名一致，获取所述证书的授权生效期及授权有效时长。

在一些可能的实施例中，API调用装置80应用于电子设备，所述证书还包括至少一个授权设备的标识；

获取单元，具体用于：

若所述授权APK包名与发起所述请求的APK的包名一致，验证所述电子设备的标识与任意一个所述授权设备的标识是否一致；

若电子设备的标识与任意一个所述授权设备的标识一致，获取所述证书的授权生效期及授权有效时长。

在一些可能的实施例中，所述证书还包括授权APK的哈希值；

所述获取单元，具体用于：

在所述签名密钥正确的情况下，验证包含所述证书的APK的哈希值与所述授权APK的哈希值是否一致；

若所述证书的APK的哈希值与所述授权APK的哈希值一致，获取所述证书的授权生效期及授权有效时长。

在一些可能的实施例中，校验模块还用于：所述校验所述证书的所述签名密钥是否正确之前，校验所述证书是否未被篡改；

读取模块，用于若所述证书未被篡改，则读取所述证书中的内容。

在一些可能的实施例中，判断模块还用于判断所述APK中是否有证书；

所述校验模块具体用于：在所述APK中有证书的情况下，验证所述证书。

在一些可能的实施例中，API调用装置80应用于电子设备，所述预设触发条件为所述电子设备开机。

在一些可能的实施例中，所述预设触发条件为监听到所述APK开始安装。

在本申请实施例可以对单个API进行编号，便于对高危API的授权管理。当APK请求调用某高危API时，若该API的编号与授权证书中的允许授权的高危编号一致，则校验通过，向APK开放该API。相比于现有技术中对多个API进行分组管理，然后以分组的形式对API进行批量授权，本申请实施例提供的对高危API进行单个控制的方法，可以保护用户数据的安全。

需要说明的是，上述实施例提供的API调用装置在执行API调用方法时，仅以上述各功能模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能模块完成，即将设备的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能。另外，上述实施例提供的API调用装置与API调用方法实施例属于同一构思，其体现实现过程详见方法实施例，这里不再赘述。

上述本申请实施例序号仅仅为了描述，不代表实施例的优劣。

请参见图9，为本申请实施例提供了一种电子设备的结构示意图。如图9所示，所述电子设备90可以包括：至少一个处理器901，至少一个网络接口904，用户接口903，存储器905，至少一个通信总线902。

其中，通信总线902用于实现这些组件之间的连接通信。

其中，用户接口903可以包括显示屏(Display)、摄像头(Camera)，可选用户接口903还可以包括标准的有线接口、无线接口。

其中，网络接口904可选的可以包括标准的有线接口、无线接口(如WI-FI接口)。

其中，处理器901可以包括一个或者多个处理核心。处理器901利用各种借口和线路连接整个电子设备90内的各个部分，通过运行或执行存储在存储器905内的指令、程序、代码集或指令集，以及调用存储在存储器905内的数据，执行电子设备90的各种功能和处理数据。可选的，处理器901可以采用数字信号处理(Digital Signal Processing，DSP)、现场可编程门阵列(Field-Programmable Gate Array，FPGA)、可编程逻辑阵列(ProgrammableLogic Array，PLA)中的至少一种硬件形式来实现。处理器901可集成中央处理器(CentralProcessing Unit，CPU)、图像处理器(Graphics Processing Unit，GPU)和调制解调器等中的一种或几种的组合。其中，CPU主要处理操作系统、用户界面和应用程序等；GPU用于负责显示屏所需要显示的内容的渲染和绘制；调制解调器用于处理无线通信。可以理解的是，上述调制解调器也可以不集成到处理器901中，单独通过一块芯片进行实现。

其中，存储器905可以包括随机存储器(Random Access Memory，RAM)，也可以包括只读存储器(Read-Only Memory)。可选的，该存储器905包括非瞬时性计算机可读介质(non-transitory computer-readable storage medium)。存储器905可用于存储指令、程序、代码、代码集或指令集。存储器905可包括存储程序区和存储数据区，其中，存储程序区可存储用于实现操作系统的指令、用于至少一个功能的指令(比如触控功能、声音播放功能、图像播放功能等)、用于实现上述各个方法实施例的指令等；存储数据区可存储上面各个方法实施例中涉及到的数据等。存储器905可选的还可以是至少一个位于远离前述处理器901的存储装置。如图9所示，作为一种计算机存储介质的存储器905中可以包括操作系统、网络通信模块、用户接口模块以及API调用应用程序。

在图9所示的电子设备90中，用户接口903主要用于为用户提供输入的接口，获取用户输入的数据；而处理器901可以用于调用存储器905中存储的API调用应用程序，并具体执行以下操作：

在应用程序安装包APK中的证书校验通过的情况下，接收所述APK发起的调用目标应用程序接口API的请求；其中，所述请求中携带所述目标API的编号；

响应于所述请求，判断所述目标API的编号是否与所述证书中授权的任意一个API的编号一致；

若所述目标API的编号与所述证书中授权的任意一个API的编号一致，则向所述APK开放所述目标API。

在一些可能的实施例中，处理器901在应用程序安装包APK中的证书校验通过的情况下，接收所述APK发起的调用目标应用程序接口API的请求之前，还用于执行：校验所述证书。

在一些可能的实施例中，所述证书包括签名密钥；

处理器901校验所述证书时，具体执行：

校验所述证书的所述签名密钥是否正确；

在所述签名密钥正确的情况下，获取所述证书的授权生效期及授权有效时长；

根据所述授权生效期及授权有效时长确定授权有效时间范围；

若当前时刻在所述授权有效时间范围内，则所述证书校验通过。

在一些可能的实施例中，所述证书还包括鉴权类型，所述鉴权类型为在线鉴权；

处理器901获取所述证书的授权有效时间范围时，具体执行：从服务器获取所述证书的授权生效期及所述授权有效时长。

在一些可能的实施例中，所述证书还包括所述授权生效期及所述授权有效时长。

在一些可能的实施例中，所述证书还包括授权APK包名；

处理器901在所述签名密钥正确的情况下，获取所述证书的授权生效期及授权有效时长时，具体执行：

在所述签名密钥正确的情况下，验证包含所述证书的APK与所述证书中的授权APK包名是否一致；

若包含所述证书的APK与所述授权APK包名一致，获取所述证书的授权生效期及授权有效时长。

在一些可能的实施例中，所述证书还包括至少一个授权设备的标识；

处理器901执行若包含所述证书的APK与所述授权APK包名一致，获取所述证书的授权生效期及授权有效时长时，具体执行：

若所述授权APK包名与发起所述请求的APK的包名一致，验证所述电子设备的标识与任意一个所述授权设备的标识是否一致；

若电子设备的标识与任意一个所述授权设备的标识一致，获取所述证书的授权生效期及授权有效时长。

在一些可能的实施例中，所述证书还包括授权APK的哈希值；

处理器901执行在所述签名密钥正确的情况下，获取所述证书的授权生效期及授权有效时长时，具体执行：

在所述签名密钥正确的情况下，验证包含所述证书的APK的哈希值与所述授权APK的哈希值是否一致；

若所述证书的APK的哈希值与所述授权APK的哈希值一致，获取所述证书的授权生效期及授权有效时长。

在一些可能的实施例中，处理器901校验所述证书的所述签名密钥是否正确之前，还用于执行：

校验所述证书是否未被篡改；

若所述证书未被篡改，则读取所述证书中的内容。

在一些可能的实施例中，处理器901校验所述证书之前，，还用于执行：

在满足预设触发条件的情况下，判断所述APK中是否有证书；

处理器901校验所述证书时，具体执行：在所述APK中有证书的情况下，验证所述证书。

在一些可能的实施例中，所述预设触发条件为所述电子设备开机。

在一些可能的实施例中，所述预设触发条件为监听到所述APK开始安装。

在本申请实施例可以对单个API进行编号，便于对高危API的授权管理。当APK请求调用某高危API时，若该API的编号与授权证书中的允许授权的高危编号一致，则校验通过，向APK开放该API。相比于现有技术中对多个API进行分组管理，然后以分组的形式对API进行批量授权，本申请实施例提供的对高危API进行单个控制的方法，可以保护用户数据的安全。

本申请实施例还提供了一种计算机可读存储介质，该计算机可读存储介质中存储有指令，当其在计算机或处理器上运行时，使得计算机或处理器执行上述图2-图7所示实施例中的一个或多个步骤。上述API调用装置的各组成模块如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在所述计算机可读取存储介质中。

在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。所述计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行所述计算机程序指令时，全部或部分地产生按照本申请实施例所述的流程或功能。所述计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。所述计算机指令可以存储在计算机可读存储介质中，或者通过所述计算机可读存储介质进行传输。所述计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线(Digital SubscriberLine，DSL))或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。所述计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。所述可用介质可以是磁性介质，(例如，软盘、硬盘、磁带)、光介质(例如，数字多功能光盘(Digital VersatileDisc，DVD))、或者半导体介质(例如，固态硬盘(Solid State Disk，SSD))等。

本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，可以通过计算机程序来指令相关的硬件来完成，该程序可存储于计算机可读取存储介质中，该程序在执行时，可包括如上述各方法的实施例的流程。而前述的存储介质包括：制度存储器(Read Only Memory，ROM)、随机存取存储器(Random Access Memory，RAM)、磁碟或者光盘等各种可存储程序代码的介质。在不冲突的情况下，本实施例和实施方案中的技术特征可以任意组合。

以上所述的实施例仅仅是本申请的优选实施例方式进行描述，并非对本申请的范围进行限定，在不脱离本申请的设计精神的前提下，本领域普通技术人员对本申请的技术方案作出的各种变形及改进，均应落入本申请的权利要求书确定的保护范围内。