一种应用程序编程接口API权限管理方法与装置与流程

本申请涉及计算机技术领域，尤其涉及一种API权限管理方法与装置。

背景技术：

实际应用中，一些应用(Application，APP)开发者为了使得自己开发的APP能够得到用户更多的关注和使用，便将自己开发的APP植入到目前使用量较大的本地APP中。其中，可将植入的APP称为寄生APP，将本地APP称为宿主APP。例如，如图1a所示，图1a所显示的界面为宿主APP的用户界面，该用户界面中的“XX打车”这一图标对应的APP为寄生APP。若用户点击该图标，该寄生APP便会显示出“XX打车”这一寄生APP的用户界面，供用户使用。

其中，寄生APP的正常运行，依赖于宿主APP中的容器应用程序编程接口(Application Programming Interface，API)。当用户点击寄生APP的用户界面中的某一控件后，寄生APP便调用容器中相应的API，来完成相应的操作。沿用上例，如图1b所示的用户界面为“XX打车”这一寄生APP的用户界面。该界面中包含出发地点输入框、目的地点输入框、定位出发地点控件以及确定控件。若用户点击了定位出发地点这一控件，“XX打车”这一寄生APP便会调用容器中相应的API，以使得寄生APP能够调用设备中的全球定位系统(Global Positioning System，GPS)来定位当前设备所在的地理位置，在定位成功后，“XX打车”这一寄生APP便将定位出的出发地点显示在出发地点输入框中，此时的用户界面如图1c所示。

现有技术中，有的宿主APP的开发者不对宿主APP容器中的API的调用设置任何限制，即只要寄生APP向宿主APP发起API调用请求，宿主APP便允许调用相应的API。但是这可能会造成宿主APP的运行环境不安全。沿用上例，若用户通过“XX打车”这一寄生APP打到了出租车，并且成功到达了目的地后，那么该寄生APP便会弹出付款页面。假设需付车费15元，则该寄生APP便会调用宿主APP的容器中相应的API，以告知宿主APP应支付15元。但是在寄生APP向宿主APP发送API调用请求的过程中，若黑客恶意篡改了API调用请求中的内容，将收款方篡改成了其他人，就会造成财产损失。

为了解决上述不安全问题，现有技术中，宿主APP可对其容器中的API进行鉴权管理，只有通过了鉴权，宿主APP才会允许寄生APP调用容器中的API。

具体的，寄生APP将API调用请求中的内容用私钥进行加密，并将加密后得到的密文内容以及明文均发给宿主APP，宿主APP将该些内容发送给服务器。服务器接收到密文内容和明文后，采用本地保存的公钥进行验签，若通过，则服务器向宿主APP返回允许调用的通知，宿主APP便允许寄生APP调用容器中的API，否则，服务器向宿主APP返回拒绝调用的通知，宿主APP便拒绝寄生APP调用容器中的API。

虽然上述方法可以保证宿主APP运行环境的安全性，但是，每次寄生APP调用宿主APP容器中的API时，宿主APP均会向服务器发起鉴权，导致网络资源耗费较大。

技术实现要素：

本申请实施例提供一种API权限管理方法与装置，用以解决现有技术中API权限管理方法存在的耗费网络资源较大的问题。

本申请实施例采用下述技术方案：

一种应用程序编程接口API权限管理方法，包括：

第一应用APP接收第二APP发送的API调用请求；其中，所述第二APP是植入到第一APP中的寄生APP；

根据所述API调用请求，确定所述第二APP所要调用的API的安全等级；

根据所述安全等级，判断是否需要对所述第二APP进行鉴权；

若是，则将所述API调用请求发送给服务器，以使得服务器根据所述API调用请求对所述第二APP进行鉴权，并根据所述服务器返回的鉴权结果允许或拒绝所述第二APP调用所述API；

否则，允许所述第二APP调用所述API。

一种应用程序编程接口API权限管理方法，包括：

第二应用APP确定所要调用的API的安全等级；

根据确定出的安全等级，向第一APP发送API调用请求，以使得所述第一APP根据所述API调用请求，确定所述API的安全等级，并根据所述安全等级，判断是否需要对所述第二APP进行鉴权，若是，则将所述API调用请求发送给服务器，以使得服务器根据所述API调用请求对所述第二APP进行鉴权，并根据所述服务器返回的鉴权结果允许或拒绝所述第二APP调用所述API；若否，则允许所述第二APP调用所述API，其中，所述第二APP是植入到第一APP中的寄生APP。

一种应用程序编程接口API权限管理装置，包括：

接收模块，第一应用APP接收第二APP发送的API调用请求；其中，所述第二APP是植入到第一APP中的寄生APP；

确定模块，根据所述API调用请求，确定所述第二APP所要调用的API的安全等级；

判断模块，根据所述安全等级，判断是否需要对所述第二APP进行鉴权；

鉴权模块，若所述判断模块判断出需要对所述第二APP进行鉴权，则将所述API调用请求发送给服务器，以使得服务器根据所述API调用请求对所述第二APP进行鉴权，并根据所述服务器返回的鉴权结果允许或拒绝所述第二APP调用所述API；若判断出不需要对所述第二APP进行鉴权，允许所述第二APP调用所述API。

一种应用程序编程接口API权限管理装置，包括：

确定模块，第二应用APP确定所要调用的API的安全等级；

发送模块，根据所述确定模块确定出的安全等级，向第一APP发送API调用请求，以使得所述第一APP根据所述API调用请求，确定所述API的安全等级，并根据所述安全等级，判断是否需要对所述第二APP进行鉴权；若是，则将所述API调用请求发送给服务器，以使得服务器根据所述API调用请求对所述第二APP进行鉴权，并根据所述服务器返回的鉴权结果允许或拒绝所述第二APP调用所述API；若否，则允许所述第二APP调用所述API，其中，所述第二APP是植入到第一APP中的寄生APP。

本申请实施例采用的上述至少一个技术方案能够达到以下有益效果：

当第二APP要调用第一APP中的API时，第一APP对应的服务器并非每次都对第二APP进行鉴权。第一APP在接收到第二APP发送的API调用请求后，会根据该API调用请求中的API的标识，确定该API的安全等级，并根据该安全等级，判断是否需要对该第二APP进行鉴权。若需要对第二APP进行鉴权，便将API调用请求发送给服务器，以便服务器进行鉴权，若不需要对第二APP进行鉴权，便不对第二APP进行鉴权，直接允许调用，可有效节省网络资源。

附图说明

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

图1a为现有技术中宿主APP的用户界面；

图1b为现有技术中寄生APP的用户界面；

图1c为现有技术中寄生APP的定位界面。

图2a为本申请实施例提供的一种API权限管理方法的具体流程示意图；

图2b为本申请实施例提供的当API安全等级为第二等级时的一种API权限管理方法的具体流程示意图；

图2c为本申请实施例提供的第一APP的注入平台的注册页面；

图2d为本申请实施例提供的当API安全等级为第二等级时的另一种API权限管理方法的具体流程示意图；

图2e为本申请实施例提供的当API安全等级为第四等级时的一种API权限管理方法的具体流程示意图；

图3为本申请实施例提供的一种API权限管理装置的示意图；

图4为本申请实施例提供的另一种API权限管理装置的示意图。

具体实施方式

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

以下结合附图，详细说明本申请实施例提供的技术方案。

为了解决了现有技术中的API权限管理方法存在的耗费网络资源较大的问题，本申请实施例提供一种API权限管理方法。

该方法的执行主体，可以但不限于为手机、平板电脑或个人电脑(Personal Computer，PC)等用户终端，或者该些用户终端上运行的APP，或者，还可以是服务器等设备。

该方法的具体流程示意图如图2a所示，包括下述步骤：

步骤11，第二APP确定所要调用的API的安全等级。

其中，第二APP是植入到第一APP中的寄生APP，第一APP为宿主APP。该第二APP可以是由超文本标记语言(HyperText Markup Language，HTML)实现的，也可以是由其他方式实现的，本申请实施例对此不进行任何限定。当第二APP接收到用户的操作指令后，第二APP便会调用第一APP中相应的API，从而完成相应的操作。

可事先按照各API对第一APP的安全性的影响程度，对第一APP中的API进行安全等级划分，将第一APP中的API划分为至少两种安全等级，并保存各API的标识与安全等级的对应关系。比如，若某一API用于唤起摄像头，那么即使该API被恶意调用，对第一APP的安全性影响也较低，则可将该类API划分为安全等级较低的API；若某一API用于调用第一APP中的支付组件进行支付，那么该API被恶意调用，对第一APP的安全性影响较高，则可将该类API划分为安全等级较高的API。具体的，可以将API划分为下述四种安全等级：Low等级、Normal等级、High等级和Top等级。其中，上述四种安全等级的高低如下排列：Low等级<Normal等级<High等级<Top等级。

上述对第一APP种各API的安全等级的划分可向第二APP公开，即，第二APP植入到第一APP中后，第二APP即可获知第一APP种每个API的标识与安全等级的对应关系。

则相应的，第二APP在需要调用第一APP中的某个API时，根据上述对应关系，即可根据其所要调用的API的标识，确定该API的安全等级。例如，第一APP可直接将API的安全等级写入该API的标识中，即，可按照下述方式对API进行命名：第一APP的标识.安全等级.所要调用的组件或硬件的名称.功用。如XXX.High.camera.scan，XXX为第一APP的标识。则第二APP在调用该API时，根据该API的上述标识，即可确定该API的安全等级是High等级的。

步骤12，第二APP根据确定出的安全等级，向第一APP发送API调用请求。

在本申请实施例中，可预先设置第二APP在调用哪一种安全等级的API时，要向第一APP发送什么样的API调用请求。因此，当第二APP通过上述步骤11确定了其所要调用的API的安全等级后，可根据确定出的API的安全等级，向第一APP发送与该安全等级对应的API调用请求。

需要说明的是，不管第二APP确定出的API的安全等级是什么等级，第二APP向第一APP发送的API调用请求中均包含API的标识，以使第一APP可以获知第二APP所要调用的API。

步骤13，第一APP接收第二APP发送的API调用请求。

需要特别说明的是，由于第二APP是植入第一APP中的寄生APP，因此，第二APP无需通过互联网向第一APP发送API调用请求。

步骤14，第一APP根据所述API调用请求，确定所述第二APP所要调用的API的安全等级。

具体的，第一APP在接收到第二APP发送的API调用请求后，可根据该API调用请求中包含的API的标识，以及第一APP本地保存的各API的标识与安全等级的对应关系，确定该API的安全等级。

步骤15，第一APP根据所述安全等级，判断是否需要对所述第二APP进行鉴权，若是，则执行步骤16，若否，则执行步骤17。

在本申请实施例中，可在第一APP中预先设置不同的安全等级与不同的的鉴权方法的对应关系。在这些安全等级中，至少包括一种安全等级对应的鉴权方法为：无需鉴权。

步骤16，第一APP将所述API调用请求发送给服务器，以使得服务器根据所述API调用请求对所述第二APP进行鉴权，并根据所述服务器返回的鉴权结果允许或拒绝所述第二APP调用所述API。

其中，需要特别说明的是，服务器本地中记录着各API的标识与安全等级的对应关系。并且可以预先设置服务器对不同安全等级的API的调用采用何种鉴权方法。

当服务器在接收到API调用请求后，服务器便根据API调用请求中的API的标识，确定该API的安全等级，并根据该安全等级，采用与该安全等级相匹配的鉴权方法对第二APP进行鉴权。服务器在鉴权结束后，将鉴权结果返回第一APP。第一APP在接收到服务器返回的鉴权通过的结果后，便允许第二APP调用所述API；在接收到服务器返回的鉴权不通过的结果后，第一APP便拒绝第二APP调用所述API。

步骤17，第一APP允许所述第二APP调用所述API。

具体的，第一APP可以向第二APP发送允许调用的通知，告知第二APP可以调用该API，第二APP在接收到该通知后，便调用第一APP中的该API。

由于本申请针对不同安全等级的API设置了不同的鉴权方法，且至少一种安全等级对应的鉴权方法为无需鉴权，这样，可在尽可能的保护第一APP安全的同时，有效的节省网络资源。

下面以第一APP中的API的安全等级为四种安全等级为例，阐述当第二APP分别要调用这四种安全等级的API时，第一APP对第二APP的具体鉴权方法。

(1)当第二APP所要调用的API的安全等级为第一等级时，第二APP将自身所要调用的API的标识携带在API调用请求中，并将该API调用请求发送给所述第一APP。第一APP在接收到该API调用请求后，确定该API调用请求中的API的安全等级为第一等级，则不对第二APP进行鉴权，允许第二APP调用该API。

(2)当第二APP所要调用的API的安全等级为第二等级时，第一APP对第二APP的具体鉴权流程如图2b所示，该流程包含步骤如下：

S101，第二APP将所要调用的API的标识、所述第二APP的标识与所述第二APP的标识对应的令牌携带在所述API调用请求中。

其中，第二APP的标识，为第二APP在第一APP中的身份标识。在第二APP植入到第一APP之前，可以在第一APP对应的植入平台中为第二APP注册账户，若注册成功，便可以将该账户作为第二APP的标识。如图2c所示的页面，为第一APP的植入平台的注册页面。可以在该页面中为第二APP注册账户，在注册成功后，第一APP可以将该账户作为第二APP的标识。随后，便可将与第二APP相关的资料，比如第二APP的名称、第二APP的图标等资料，上传到该平台中，以便将该第二APP的图标或/和名称显示在第一APP的用户界面中。

在第二APP执行S101之前，第二APP可以在第二APP的本地查看是否存在令牌，并且查看该令牌是否过期。

若第二APP本地存在令牌且存在的令牌未过期，则第二APP便可将与第二APP的标识对应的令牌携带在API调用请求中。

若第二APP本地不存在所述令牌或存在的所述令牌过期，则第二APP向服务器发送获取令牌请求，并接收服务器返回的令牌，将接收到的令牌携带在API调用请求中。

其中，向第二APP提供令牌的服务器为第一APP对应的服务器。则第二APP可以通过服务器网关向第一APP对应的服务器发送获取令牌请求，其中，服务器网关用于不同的服务器之间的数据传输。

例如，如图2d所示，图2d中的第二APP首先向第二APP对应的服务器发送获取令牌请求，然后第二APP对应的服务器通过服务器网关向第一APP的服务器发送获取令牌请求。其中，获取令牌请求中包含第二APP的标识，第一APP对应的服务器根据该标识，生成并返回与该标识对应的令牌。第一APP对应的服务器在生成令牌后，可以在该服务器本地保存该令牌，并建立该令牌与相应的第二APP的标识的映射关系。另外，令牌具有一定的有效期，该有效期可以根据实际需求进行设置。该令牌可以在第二APP每发送完毕一次携带令牌的API调用请求后便失效，也可在预设时长之后失效，比如两个小时后失效，本申请实施例对此不进行任何限定。若令牌的有效期为两个小时，那么该令牌中包含该令牌的生成时间，第二APP可以根据该令牌的生成时间，以及设备现在的时间，判断该令牌存在的时间是否超过两小时，若未超过，则该令牌未过期，否则，该令牌已过期。若令牌每隔一段预设时长便失效，第二APP可以在令牌失效后，便立即向服务器发送获取令牌请求，而不是在要发送API调用请求之前，才向服务器发送获取令牌请求。

S102，第二APP将所述API调用请求发送给所述第一APP。

S103，第一APP根据API调用请求，确定所述第二APP所要调用的API的安全等级。

其中，该安全等级为第二等级。

S104，第一APP根据所述安全等级，判断出需要对所述第二APP进行鉴权，并将该API调用请求发送给服务器。

其中，如图2d所示，第一APP可以通过APP网关将API调用请求发送给服务器。APP网关用于APP与服务器之间的数据传输。

S105，服务器根据API调用请求，确定所述第二APP所要调用的API的安全等级。

S106，服务器根据确定出的API的安全等级，确定对第二APP进行与该安全等级相匹配的鉴权操作。

其中，由于该API的安全等级为第二等级，那么服务器根据API调用请求中的第二APP的标识，在服务器本地查找与该第二APP的标识相对应的令牌，并判断查找到的令牌与所述API调用请求中携带的令牌是否相同，若是，则鉴权通过，否则，鉴权不通过。

若服务器接收到的API调用请求中的令牌或第二APP的标识被恶意篡改了，那么，服务器在服务器本地查找与第二APP的标识相对应的令牌，若服务器本地不存在与该第二APP的标识相对应的令牌，或者查找到的与该第二APP的标识相对应的令牌中不包含API调用请求中包含的令牌，再或者该令牌已经过期，则鉴权不通过，从而保护了第一APP的安全。例如，若服务器接收到的API调用请求中的API调用请求中的第二APP的标识被篡改成了第一APP中的其他寄生APP(后称第三APP)的标识，另外令牌被篡改成了该第三APP对应的未过期的令牌，而API的标识未被篡改，那么，服务器在本地查找到第三APP的标识，并查找到该第三APP对应的令牌中包含API调用请求中的令牌，则鉴权通过。即便最终第三APP可调用该API，由于该API的安全等级较低，也不会对第一APP的安全产生较大影响。

S107，服务器返回鉴权结果。

S108，第一APP根据接收到的鉴权结果，允许或拒绝第二APP调用所述API。

(3)当第二APP所要调用的API的安全等级为第三等级时，此时，本申请实施例提供的另一种API权限管理方法的具体流程与图2c所示的流程类似，只是(2)中的S106中提及的服务器对第二APP进行鉴权的过程不同，不同点在于：

服务器在服务器本地查找与该第二APP的标识相对应的令牌，并判断查找到的令牌与所述API调用请求中携带的令牌是否相同之外，服务器还要在服务器本地查找第二APP有权限调用的各API的标识，若查找到的令牌与API调用请求中的令牌相同，且查找到的各API的标识中存在API调用请求中携带的API的标识，则鉴权通过，否则，鉴权不通过。

其中，可以事先将第二APP有权限调用的各API的标识保存在服务器中，便于服务器在该些API的标识查找是否存在API调用请求中携带的API的标识。

需要特别说明的是，只要查找到的令牌与API调用请求中的令牌不相同，或/和查找到的各API的标识中不存在API调用请求中携带的API的标识，便认为鉴权不通过。

这一鉴权方法，要比第二安全等级对应的鉴权方法多一个鉴权步骤，因此比第二安全等级对应的鉴权方法的安全系数要高。

(4)当第二APP所要调用的API的安全等级为第四等级时，此时，本申请实施例提供的API权限管理方法的具体流程如图2e所示，该流程包含步骤如下：

S201，第二APP可以采用私钥将所要调用的API的标识和第二APP的标识进行加密得到密文内容。

除API的标识和第二APP的标识以外，第二APP还可以将请求参数一并进行加密。若第二APP要给某一账户打款，请求参数可以是收款方账户，以及付款的金额等信息。

其中，私钥为事先保存在第二APP中的私钥，该私钥与该第二APP的标识相对应。另外，与该私钥匹配的公钥保存在第一APP对应的服务器中，并且该公钥与该第二APP的标识相对应。私钥可以是第二APP在注册的时候，由第一APP提供的。

S202，第二APP将所述第二APP所要调用的API的标识、所述第二APP的标识、密文内容携带在API调用请求中。

其中，除了将第二APP所要调用的API的标识、所述第二APP的标识携带在API调用请求中外，还可以将请求参数携带在API调用请求中。后文可将第二APP所要调用的API的标识和第二APP的标识以及请求参数等信息称为明文内容。

S203，第二APP将该API调用请求发送给所述第一APP。

S204，第一APP根据API调用请求，确定所述第二APP所要调用的API的安全等级。

其中，该安全等级为第四等级。

S205，第一APP根据所述安全等级，判断出需要对所述第二APP进行鉴权，并将该API调用请求发送给服务器。

S206，服务器根据API调用请求，确定所述第二APP所要调用的API的安全等级。

S207，服务器根据确定出的API的安全等级，确定对第二APP进行与该安全等级相匹配的鉴权操作。

服务器根据API调用请求中的第二APP的标识，采用与所述第二APP的标识对应的公钥对密文内容进行验证，并在所述服务器本地查找所述第二APP有权限调用的各API的标识，若验证通过且查找到的各API的标识中存在所述API调用请求中携带的API的标识，则鉴权通过，否则，鉴权不通过。

其中，采用与第二APP的标识对应的公钥对密文内容进行验证，可以是服务器用与第二APP的标识对应的公钥加密第二APP所要调用的API的标识、所述第二APP的标识，若得到的密文内容与接收到的密文内容相同，则验证通过，否则，验证不通过。

需要特别说明的是，只要验证不通过，或/和查找到的各API的标识中不存在API调用请求中携带的API的标识，便认为鉴权不通过。

由于密文内容无法被篡改，因此，即便明文内容被篡改，服务器在用公钥进行验证时，验证也不会通过。只要明文内容被篡改了任何一个细小的内容，该鉴权均不通过。因此该鉴权方法可以保护第一APP的安全，且安全系数要高于第一、第二以及第三等级对应的鉴权方法。

S208，服务器返回鉴权结果。

S209，第一APP根据接收到的鉴权结果，允许或拒绝第二APP调用所述API。

上面详细介绍了在第二APP分别调用四种安全等级的API时，第一APP对第二APP进行的鉴权管理。除了可以将API的安全等级划分为上述四种外，还可以划分为其他至少两种，本申请实施例对此不进行任何限定。

本申请实施例中，还可以通过一种API权限管理装置，来实现本申请实施例提供的方法。该装置的具体示意图如图3所示，主要包括下述装置：

接收模块31，第一应用APP接收第二APP发送的API调用请求；其中，所述第二APP是植入到第一APP中的寄生APP.

确定模块32，根据所述API调用请求，确定所述第二APP所要调用的API的安全等级。

判断模块33，根据所述安全等级，判断是否需要对所述第二APP进行鉴权。

鉴权模块34，若所述判断模块判断出需要对所述第二APP进行鉴权，则将所述API调用请求发送给服务器，以使得服务器根据所述API调用请求对所述第二APP进行鉴权，并根据所述服务器返回的鉴权结果允许或拒绝所述第二APP调用所述API；若所述判断模块判断出不需要对所述第二APP进行鉴权，允许所述第二APP调用所述API。

在一种实施方式中，确定模块32，根据所述API调用请求中包含的第二APP所要调用的API的标识，确定所述第二APP所要调用的API的安全等级。

在一种实施方式中，判断模块33，若所述安全等级为第一等级，则判定不需要对所述第二APP进行鉴权；若所述安全等级不是第一等级，则判定需要对所述第二APP进行鉴权。

在一种实施方式中，当所述安全等级为第二等级时，所述API调用请求中携带所述第二APP所要调用的API的标识、所述第二APP的标识与所述第二APP的标识对应的令牌；则

鉴权模块34，将所述API调用请求发送给服务器，以使得所述服务器根据API调用请求中的第二APP的标识，在所述服务器本地查找与所述第二APP的标识相对应的令牌，并判断查找到的令牌与所述API调用请求中携带的令牌是否相同，若是，则鉴权通过，否则，鉴权不通过。

在一种实施方式中，当所述安全等级为第三等级时，所述API调用请求中携带所述第二APP所要调用的API的标识、所述第二APP的标识与所述第二APP的标识对应的令牌；则

鉴权模块34，将所述API调用请求发送给服务器，以使得所述服务器根据API调用请求中的第二APP的标识，在所述服务器本地查找与所述第二APP的标识相对应的令牌，并在所述服务器本地查找所述第二APP有权限调用的各API的标识，若查找到的令牌与所述API调用请求中的令牌相同，且查找到的各API的标识中存在所述API调用请求中携带的API的标识，则鉴权通过，否则，鉴权不通过。

在一种实施方式中，当所述安全等级为第四等级时，所述API调用请求中携带所述第二APP所要调用的API的标识、所述第二APP的标识、密文内容；其中，所述密文内容是第二APP采用私钥将所述API的标识和所述第二APP的标识进行加密得到的；则

鉴权模块34，将所述API调用请求发送给服务器，以使得所述服务器根据API调用请求中的第二APP的标识，采用与所述第二APP的标识对应的公钥对所述密文内容进行验证，并在所述服务器本地查找所述第二APP有权限调用的各API的标识，若验证通过且查找到的各API的标识中存在所述API调用请求中携带的API的标识，则鉴权通过，否则，鉴权不通过。

本申请实施例中，还可以通过另一种API权限管理装置，来实现本申请实施例提供的方法。该装置的具体示意图如图4所示，主要包括下述装置：

确定模块41，第二应用APP确定所要调用的API的安全等级。

发送模块42，根据确定模块41确定出的安全等级，向第一APP发送API调用请求，以使得所述第一APP根据所述API调用请求，确定所述API的安全等级，并根据所述安全等级，判断是否需要对所述第二APP进行鉴权；若是，则将所述API调用请求发送给服务器，以使得服务器根据所述API调用请求对所述第二APP进行鉴权，并根据所述服务器返回的鉴权结果允许或拒绝所述第二APP调用所述API；若否，则允许所述第二APP调用所述API，其中，所述第二APP是植入到第一APP中的寄生APP。

在一种实施方式中，确定模块41，根据所要调用的API的标识，确定所述API的安全等级。

在一种实施方式中，发送模块42，当所述确定模块41确定出的所述安全等级为第一等级时，将所述第二APP所要调用的API的标识携带在所述API调用请求中，并将所述API调用请求发送给所述第一APP，以使得所述第一APP在根据所述API请求中的所述API的标识确定出所述API的安全等级为第一等级时，确定不需要鉴权，并允许所述第二APP调用所述API。

在一种实施方式中，发送模块42，当所述确定模块41确定出的所述安全等级为第二等级或第三等级时，将所述第二APP所要调用的API的标识、所述第二APP的标识与所述第二APP的标识对应的令牌携带在所述API调用请求中，并将所述API调用请求发送给所述第一APP，以使得所述第一APP在根据所述API调用请求中的所述API的标识确定出所述API的安全等级为第二等级或第三等级时，将所述API调用请求发送给服务器，以便服务器对所述第二APP进行鉴权。

在一种实施方式中，发送模块42，若所述第二APP本地存在所述令牌且存在的所述令牌未过期，则将与所述第二APP的标识对应的令牌携带在所述API调用请求中；若所述第二APP本地不存在所述令牌或存在的所述令牌过期，则所述第二APP向服务器发送获取令牌请求，接收服务器返回的令牌，将接收到的令牌携带在所述API调用请求中。

在一种实施方式中，发送模块42，当所述确定模块41确定出的所述安全等级为第四等级时，第二APP采用私钥将所述API的标识和所述第二APP的标识进行加密得到密文内容；

将所述第二APP所要调用的API的标识、所述第二APP的标识、密文内容携带在所述API调用请求中，并将所述API调用请求发送给所述第一APP，以使得所述第一APP在根据所述API调用请求中的所述API的标识确定出所述API的安全等级为第四等级时，将所述API调用请求发送给服务器，以便服务器对所述第二APP进行鉴权。

当第二APP要调用第一APP中的API时，第一APP对应的服务器并非每次都对第二APP进行鉴权。第一APP在接收到第二APP发送的API调用请求后，会根据该API调用请求中的API的标识，确定该API的安全等级，并根据该安全等级，判断是否需要对该第二APP进行鉴权。若需要对第二APP进行鉴权，便将API调用请求发送给服务器，以便服务器进行鉴权，若不需要对第二APP进行鉴权，便不对第二APP进行鉴权，直接允许调用，可有效节省网络资源。

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

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

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

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

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

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

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。

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

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

以上所述仅为本申请的实施例而已，并不用于限制本申请。对于本领域技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本申请的权利要求范围之内。