CN114579951A - 业务访问方法、电子设备及存储介质 - Google Patents

Abstract

本申请实施例提供一种业务访问方法、电子设备及存储介质，涉及通信技术领域，该方法包括：接收第二电子设备发送的验证请求，基于第二应用的服务器地址信息进行验证；响应于第二应用的服务器地址信息的验证通过，则基于第二应用权限范围进行权限验证；响应于权限验证通过，向第二电子设备返回验证成功消息，使得第二电子设备允许第三电子设备中的第二应用基于第二应用权限范围进行业务访问。本申请实施例提供的方法，能够对代理应用的权限进行降级，避免由代理应用进行业务访问带来的安全隐患，从而保证用户个人数据的安全。

Description

业务访问方法、电子设备及存储介质

技术领域

本申请实施例涉及通信技术领域，尤其涉及一种业务访问方法、电子设备及存储介质。

背景技术

目前，开放认证(Open Authorization，OAUTH)协议为用户资源的授权提供了一个安全的、开放而又简易的标准。与以往的授权方式不同之处是OAUTH协议的授权不会使第三方触及到用户的帐号信息(如用户名与密码)，即第三方无需使用用户的用户名与密码就可以申请获得该用户资源的授权。其中，OAUTH协议还提供了一种基于网络校验码(Json WebToken，JWT)方式的服务器与服务器之间的鉴权方式。

发明内容

本申请实施例提供了一种业务访问方法、电子设备及存储介质，以提供一种对应用权限降级的方式。

第一方面，本申请实施例提供了一种业务访问方法，应用于第一电子设备，包括：

接收第二电子设备发送的验证请求，其中，验证请求用于对业务访问请求进行验证，业务访问请求由第三电子设备基于第二应用向第二电子设备发起，第二应用由第三电子设备中的第一应用调用，验证请求包括第二应用权限范围及第二应用的服务器地址信息，第二应用权限范围用于标识第二应用的业务访问的权限范围；具体地，该第一电子设备可以是认证服务器，该认证服务器用于对业务访问请求进行验证；该第二电子设备可以是业务服务器，该业务服务器用于对代理应用的访问提供服务；该第三电子设备可以是终端，该终端可以包括手机、平板等移动设备。该第一应用可以是主应用，该第二应用可以是代理应用。

基于第二应用的服务器地址信息进行验证。

响应于第二应用的服务器地址信息的验证通过，基于第二应用权限范围进行权限验证。

响应于权限验证通过，向第二电子设备返回验证成功消息，使得第二电子设备允许第三电子设备中的第二应用基于第二应用权限范围进行业务访问。

本实施例中，通过认证服务器预先给代理应用分配代理权限，以区分主应用的主权限，用户在主应用中调用代理应用发起业务访问请求，业务访问请求中携带代理权限信息，由认证服务器基于该代理权限信息进行权限验证，由此可以使得代理应用的业务权限降级，进而保证用户的个人数据的安全。

其中一种可能的实现方式中，该验证请求还包括第二应用身份信息，接收第二电子设备发送的验证请求之前，还包括：接收第二应用的注册请求，其中，注册请求包括第二应用的服务器地址信息；生成第二应用身份信息及对应的密钥，将第二应用的服务器地址信息与第二应用身份信息进行关联后存储，并将第二应用身份信息及密钥发送给第二应用。具体地，该服务器地址信息可以包括与第二应用对应的服务器地址信息。该身份信息可以是第二应用的身份标识，该身份标识可以是该第二应用的唯一的识别号，用于对该第二应用进行识别。该密钥可以是对称密钥，也可以是非对称密钥，本申请实施例对此不作特殊限定。

本实施例中，通过对第二应用的注册信息进行存储，并给第二应用分配身份信息及密钥，可以对第二应用进行识别和验证。

其中一种可能的实现方式中，基于第二应用的服务器地址信息进行验证包括：基于第二应用身份信息进行查询，获得与第二应用身份信息对应的第二应用的服务器地址信息；将查询获得的第二应用的服务器地址信息与验证请求中的第二应用的服务器地址信息进行比对，以完成对第二应用的服务器地址信息的验证。

本实施例中，通过预先存储服务器地址信息，并将验证请求中的服务器地址信息与预先存储的服务器地址信息进行比对，可以有效的完成服务器地址信息的验证，提高安全性。

其中一种可能的实现方式中，接收第二电子设备发送的验证请求之前，还包括：接收第一应用发送的第二应用权限请求，其中，第二应用权限请求用于获取第二应用权限范围，第二应用权限请求包括第二应用身份信息及第一应用授权凭据，第一应用授权凭据用于标识第一应用的业务访问凭据；具体地，该第二应用权限范围可以包括第二应用的业务访问范围。基于第一应用授权凭据查询获得第一应用的预设权限范围，其中，第一应用的预设权限范围用于标识第一应用的业务访问的权限范围；基于第一应用的预设权限范围查询获取对应的第二应用权限范围，将第二应用权限范围与第二应用身份信息关联后存储，并将第二应用权限范围发送给第一应用。具体地，该第二应用权限范围可以包括第二应用的业务访问范围。接着，将第二应用权限范围发送给第一应用。

本实施例中，通过获取第一应用的业务访问范围，基于该第一应用的业务访问范围查询获得第二应用的业务访问范围，并将该第二应用的业务访问范围发送给第一应用，以使得第一应用在调用第二应用时可以调用该第二应用的业务访问范围，由此可以实现第二应用的权限降级，进而提高安全性。

其中一种可能的实现方式中，基于第二应用权限范围进行权限验证包括：基于第二应用身份信息进行查询，获得与第二应用身份信息对应的第二应用权限范围；将所述查询获得的第二应用权限范围与所述验证请求中的第二应用权限范围进行比对，以完成权限验证。

本实施例中，通过验证请求中的第二应用权限范围与本地存储的第二应用权限范围的比对，以完成对第二应用的代理权限的权限验证，由此可以提高安全性。

其中一种可能的实现方式中，将第二应用身份信息及密钥发送给第二应用之后，还包括：接收第二应用的第二应用授权凭据请求，其中，第二应用授权凭据请求用于获取第二应用授权凭据，第二应用授权凭据用于标识第二应用的业务访问凭据，第二应用授权凭据请求包括第二应用身份信息及密钥；具体地，该第二应用授权凭据请求中携带第二应用的身份信息及对应的密钥，由于该第二应用的身份信息及对应的密钥由第一电子设备分配，通过对第二应用的身份信息及对应的密钥进行验证，可以提高安全性。基于第二应用身份信息进行查询，获得与第二应用身份信息对应的密钥；将查询获得的密钥与第二应用授权凭据请求中的密钥进行比对，响应于查询获得的密钥与第二应用授权凭据请求中的密钥一致，颁发第二应用授权凭据，并将第二应用授权凭据发送给第二应用。具体地，当密钥验证通过后，给第二应用颁发第二应用授权凭据，可以提高安全性。

其中一种可能的实现方式中，验证请求还包括第二应用授权凭据，基于第二应用的服务器地址信息进行验证之前，还包括：查询是否存在与第二应用授权凭据一致的授权凭据，以完成对第二应用授权凭据的验证。具体地，在对第二应用的服务器地址信息进行验证之前，进一步对第二应用授权凭据进行验证，可以提高安全性。

第二方面，本申请实施例提供一种业务访问装置，包括：

接收模块，用于接收第二电子设备发送的验证请求，其中，验证请求用于对业务访问请求进行验证，业务访问请求由第三电子设备基于第二应用向第二电子设备发起，第二应用由第三电子设备中的第一应用调用，验证请求包括第二应用权限范围及第二应用的服务器地址信息，第二应用权限范围用于标识第二应用的业务访问的权限范围；

第一验证模块，用于基于第二应用的服务器地址信息进行验证；

第二验证模块，用于响应于第二应用的服务器地址信息的验证通过，基于第二应用权限范围进行权限验证；

发送模块，用于响应于权限验证通过，向第二电子设备返回验证成功消息，使得第二电子设备允许第三电子设备中的第二应用基于第二应用权限范围进行业务访问。

其中一种可能的实现方式中，验证请求还包括第二应用身份信息，上述装置还包括：

注册模块，用于接收第二应用的注册请求，其中，注册请求包括第二应用的服务器地址信息；生成第二应用身份信息及对应的密钥，将第二应用的服务器地址信息与第二应用身份信息进行关联后存储，并将第二应用身份信息及密钥发送给第二应用。

其中一种可能的实现方式中，上述第一验证模块包括：

第一查询单元，用于基于第二应用身份信息进行查询，获得与第二应用身份信息对应的第二应用的服务器地址信息；

第一验证单元，用于将查询获得的第二应用的服务器地址信息与验证请求中的第二应用的服务器地址信息进行比对，以完成对第二应用的服务器地址信息的验证。

其中一种可能的实现方式中，上述装置还包括：

代理权限分配模块，用于接收第一应用发送的第二应用权限请求，其中，第二应用权限请求用于获取第二应用权限范围，第二应用权限范围包括第二应用身份信息及第一应用授权凭据，第一应用授权凭据用于标识第一应用的业务访问凭据；基于第一应用授权凭据查询获得第一应用的预设权限范围，其中，第一应用的预设权限范围用于标识第一应用的业务访问的权限范围；基于第一应用的预设权限范围查询获取对应的第二应用权限范围，将第二应用权限范围与第二应用身份信息关联后存储；并将第二应用权限范围发送给第一应用。

其中一种可能的实现方式中，上述第二验证模块包括：

第二查询单元，用于基于第二应用身份信息进行查询，获得与第二应用身份信息对应的第二应用权限范围；

第二验证单元，用于将查询获得的第二应用权限范围与验证请求中的第二应用权限范围进行比对，以完成权限验证。

其中一种可能的实现方式中，上述装置还包括：

代理凭据分配模块，用于接收第二应用的第二应用授权凭据请求，其中，第二应用授权凭据请求用于获取第二应用授权凭据，第二应用授权凭据用于标识第二应用的业务访问凭据，第二应用授权凭据请求包括第二应用身份信息及密钥；基于第二应用身份信息识进行查询，获得与第二应用身份信息对应的密钥；将查询获得的密钥与第二应用授权凭据请求中的密钥进行比对，响应于查询获得的密钥与第二授权凭据请求中的密钥一致，颁发第二应用授权凭据，并将第二应用授权凭据发送给第二应用。

其中一种可能的实现方式中，上述装置还包括：

第三验证模块，用于查询是否存在与第二应用授权凭据一致的授权凭据，以完成对第二应用授权凭据的验证。

第三方面，本申请实施例提供一种第一电子设备，包括：

存储器，上述存储器用于存储计算机程序代码，上述计算机程序代码包括指令，当上述第一电子设备从上述存储器中读取上述指令，以使得上述第一电子设备执行以下步骤：

接收第二电子设备发送的验证请求，其中，验证请求用于对业务访问请求进行验证，业务访问请求由第三电子设备基于第二应用向第二电子设备发起，第二应用由第三电子设备中的第一应用调用，验证请求包括第二应用权限范围及第二应用的服务器地址信息，第二应用权限范围用于标识第二应用的业务访问的权限范围；

基于第二应用的服务器地址信息进行验证；

响应于第二应用的服务器地址信息的验证通过，基于第二应用权限范围进行权限验证；

响应于权限验证通过，向第二电子设备返回验证成功消息，使得第二电子设备允许第三电子设备中的第二应用基于第二应用权限范围进行业务访问。

其中一种可能的实现方式中，验证请求还包括第二应用身份信息，上述指令被上述第一电子设备执行时，使得上述第一电子设备执行接收第二电子设备发送的验证请求的步骤之前，还执行以下步骤：

接收第二应用的注册请求，其中，注册请求包括第二应用的服务器地址信息；

生成第二应用身份信息及对应的密钥，将第二应用的服务器地址信息与第二应用身份信息进行关联后存储，并将第二应用身份信息及密钥发送给第二应用。

其中一种可能的实现方式中，上述指令被上述第一电子设备执行时，使得上述第一电子设备执行基于第二应用的服务器地址信息进行验证的步骤包括：

基于第二应用身份信息进行查询，获得与第二应用身份信息对应的第二应用的服务器地址信息；

将查询获得的第二应用的服务器地址信息与验证请求中的第二应用的服务器地址信息进行比对，以完成对第二应用的服务器地址信息的验证。

其中一种可能的实现方式中，上述指令被上述第一电子设备执行时，使得上述第一电子设备执行接收第二电子设备发送的验证请求的步骤之前，还执行以下步骤：

第一应用发送的第二应用权限请求，其中，第二应用权限请求用于获取第二应用权限范围，第二应用权限范围包括第二应用身份信息及第一应用授权凭据，第一应用授权凭据用于标识第一应用的业务访问凭据；

基于第一应用授权凭据查询获得第一应用的预设权限范围，其中，第一应用的预设权限范围用于标识第一应用的业务访问的权限范围；

基于第一应用的预设权限范围查询获取对应的第二应用权限范围，将第二应用权限范围与第二应用身份信息关联后存储，并将第二应用权限范围发送给第一应用。

其中一种可能的实现方式中，上述指令被上述第一电子设备执行时，使得上述第一电子设备执行基于第二应用权限范围进行权限验证的步骤包括：

基于第二应用身份信息进行查询，获得与第二应用身份信息对应的第二应用权限范围；

将查询获得的第二应用权限范围与验证请求中的第二应用权限范围进行比对，以完成权限验证。

其中一种可能的实现方式中，上述指令被上述第一电子设备执行时，使得上述第一电子设备执行将第二应用身份信息及密钥发送给第二应用的步骤之后，还执行以下步骤：

接收第二应用的第二应用授权凭据请求，其中，第二应用授权凭据请求用于获取第二应用授权凭据，第二应用授权凭据用于标识第二应用的业务访问凭据，第二应用授权凭据请求包括第二应用身份信息及密钥；

基于第二应用身份信息识进行查询，获得与第二应用身份信息对应的密钥；

将查询获得的密钥与第二应用授权凭据请求中的密钥进行比对，响应于查询获得的密钥与第二授权凭据请求中的密钥一致，颁发第二应用授权凭据，并将第二应用授权凭据发送给第二应用。

其中一种可能的实现方式中，验证请求还包括第二应用授权凭据，上述指令被上述第一电子设备执行时，使得上述第一电子设备执行基于第二应用的服务器地址信息进行验证的步骤之前，还执行以下步骤：

查询是否存在与第二应用授权凭据一致的授权凭据，以完成对第二应用授权凭据的验证。

第四方面，本申请实施例提供一种计算机可读存储介质，该计算机可读存储介质中存储有计算机程序，当其在计算机上运行时，使得计算机执行如第一方面所述的方法。

第五方面，本申请实施例提供一种计算机程序，当上述计算机程序被计算机执行时，用于执行第一方面所述的方法。

在一种可能的设计中，第五方面中的程序可以全部或者部分存储在与处理器封装在一起的存储介质上，也可以部分或者全部存储在不与处理器封装在一起的存储器上。

附图说明

图1为本申请实施例提供的应用场景架构示意图；

图2A为本申请实施例提供的一个实施例的终端显示界面示意图；

图2B为本申请实施例提供的另一个实施例的终端显示界面示意图；

图2C为本申请实施例提供的再一个实施例的终端显示界面示意图；

图3为本申请提供的一个实施例的业务访问方法的流程示意图；

图4为本申请提供的一个实施例的业务访问请求的数据包格式示意图；

图5为本申请提供的另一个实施例的业务访问方法的流程示意图；

图6为本申请提供的另一个实施例的业务访问请求的数据包格式示意图；

图7为本申请提供的再一个实施例的业务访问方法的流程示意图；

图8为本申请实施例提供的业务访问装置的结构示意图；

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

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行描述。其中，在本申请实施例的描述中，除非另有说明，“/”表示或的意思，例如，A/B可以表示A或B；本文中的“和/或”仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。

以下，术语“第一”、“第二”仅用于描述目的，而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或者隐含地包括一个或者更多个该特征。在本申请实施例的描述中，除非另有说明，“多个”的含义是两个或两个以上。

用户在终端上打开一个应用程序后，可以通过个人账号进行登录，由此可以授权给该应用程序，以使得该应用程序可以根据用户授权的业务权限获取用户的个人数据。为说明方便，该应用程序以下简称为主应用。当用户通过该主应用调用第三方应用程序(以下简称代理应用)时，示例性的，用户在打开一个主应用(例如，订餐应用程序)后，可以调用代理应用(例如，支付应用程序)进行支付；该代理应用由于和该主应用共享用户授权的业务权限，因此，也可以获取用户的所有个人数据。然而，该代理应用可能仅需部分个人数据即可完成当前的业务，例如，支付应用在支付过程中仅需用户的银行账号等个人信息即可完成支付业务，无需其他个人信息，因此，若所有个人数据都向代理应用开放，由此可能导致用户的个人数据被代理应用泄露，造成安全隐患，给用户带来损失。

本申请实施例提出了一种业务访问方法，以提供一种对代理应用的业务权限进行权限降级的方式，实现在主应用中调用代理应用进行业务访问时，对代理应用的业务权限进行权限降级，由此可以避免由于代理应用具有与主应用相同的业务权限带来的安全隐患，保证用户个人数据的安全，进而可以避免用户的损失。

本申请实施例提供的技术方案可运用于数据处理设备，该数据处理设备可以是服务器，本申请对执行该技术方案的数据处理设备的具体形式不做特殊限制。

现结合图1-图7对本申请实施例提供的业务访问方法进行说明。

如图1所示为本申请业务访问方法的应用场景架构图。参考图1，终端100可以分别和业务服务器200及认证服务器300进行通信。业务服务器200用于提供分别与主应用对应的业务(例如，订餐业务，叫车业务等)和代理应用对应的业务(例如，支付业务)，以实现用户通过主应用和代理应用发起的业务访问。认证服务器300可以用于分别对主应用和代理应用进行注册，以及分别对主应用和代理应用的业务权限进行授权和验证。

如图2A所示，终端100的显示界面110可以包含各类主应用111，用户可以在终端100的显示界面110上对主应用111进行操作。例如，用户可以点击终端100的显示界面110上的音乐主应用图标，以打开音乐主应用，由此可以得到如图2B所示的显示界面120，以完成对音乐主应用的业务访问。参考图2B，显示界面120显示的是与音乐主应用对应的页面。其中，在显示界面120中还包括各类代理应用112，用户可以在终端100的显示界面120上对代理应用112进行操作。示例性的，用户可以点击显示界面120中的专辑购买链接，以调用支付接口，由此显示界面120可以跳转至与该专辑购买支付对应的页面(例如，如图2C所示的显示界面130)，在显示界面130中，用户可以通过密码验证或通过指纹验证，以完成本次专辑购买业务。

如图3所示为本申请业务访问方法一个实施例的流程图，包括：

步骤101，代理应用112向认证服务器300发送注册请求。

具体地，代理应用112可以是主应用111中被调用的第三方应用程序，示例性的，该代理应用112可以是被调用的支付应用程序；该代理应用112也可以是其它被调用的第三方应用程序，本申请实施例对此不作特殊限定。其中，主应用111可以是用户在终端100上已安装的应用程序，示例性的，该主应用111可以包括社交应用程序、订餐应用程序、电商应用程序等；该主应用111也可以是其它通过程序安装包安装在终端100上的应用程序，本申请实施例对此不作特殊限定。该终端100可以是手机、平板等具有通信功能的设备。认证服务器300可以是用于对主应用111和代理应用112进行注册、以及对主应用111和代理应用112的业务权限颁发授权凭据及验证的服务器。

代理应用112可以通过注册接口在认证服务器300上进行注册，示例性的，代理应用112可以通过注册接口向认证服务器300发送注册请求。其中，该注册请求可以包括应用类型及服务器地址。该应用类型可以用于标识代理应用112的类型，例如，可以将代理应用112的类型设置为代理应用类型。该服务器地址用于标识代理应用112的服务器的地址，在具体实现时，可以通过服务器IP地址或者域名标识服务器的地址，其中，IP地址的个数可以是一个或多个，本申请对此不作限定。

现以rfc7591协议进行举例，可以对该协议的注册接口进行修改，用于发送上述注册请求，以完成代理应用112在认证服务器300上的注册，得到如下示例代码：

其中，新增字段client_type用于标识应用类型，新增字段source用于标识服务器地址。由此可以完成代理应用112在认证服务器300上的注册，该代理应用112的注册信息可以包括应用类型和服务器地址。

步骤102，认证服务器300基于注册请求生成代理应用112的身份标识及密钥。

具体地，认证服务器300收到代理应用112的注册请求后，可以为该代理应用112分配身份标识及密钥，分配身份标识及密钥的过程具体可参考OAuth2.0协议，在此不再赘述。其中，代理应用身份标识可以用于标识代理应用112的身份，也就是说，代理应用身份标识可以用于对代理应用112进行识别。代理应用密钥可以采用本领域常用的对称或非对称密钥，本申请实施例对此不作特殊限定。

可以理解的是，认证服务器300还可以将代理应用112的身份标识、密钥、服务器地址进行存储，例如，认证服务器300可以将上述代理应用112的身份标识、密钥、服务器地址关联后存储在本地数据库中。

步骤103，认证服务器300将代理应用112的身份标识及密钥返回给代理应用112。

步骤104，主应用111向认证服务器300发送注册请求。

具体地，

主应用111也可以通过注册接口在认证服务器300上进行注册，例如，可以通过rfc7591协议的原注册接口进行注册，代码示例如下：

步骤105，认证服务器300基于注册请求生成主应用111的身份标识及密钥。

具体地，认证服务器300收到主应用111的注册请求后，可以为该主应用111分配身份标识及密钥，分配身份标识及密钥的过程具体可参考OAuth2.0协议，在此不再赘述。其中，主应用身份标识可以用于标识主应用111的身份，也就是说，主应用身份标识可以用于对主应用111进行识别。主应用密钥可以采用本领域常用的对称或非对称密钥，本申请实施例对此不作特殊限定。。

进一步地，认证服务器300还可以将主应用111的身份标识及密钥进行存储，例如，认证服务器300将上述主应用111的身份标识及密钥存储在本地数据库中。

步骤106，认证服务器300将主应用111的身份标识及密钥返回给主应用111。

步骤107，主应用111基于主应用111的身份标识及密钥向认证服务器300发起主授权凭据请求，以获得主授权凭据。

具体地，主授权凭据用于标识主应用111的业务权限。其中，上述主授权凭据请求中包含主应用111的身份标识及密钥。

步骤108，认证服务器300基于主应用111的身份标识及密钥颁发主授权凭据，将该主授权凭据发送给主应用111。

具体地，认证服务器300在收到主应用111的主授权凭据请求后，可以基于授权凭据请求中的主应用111的身份标识及密钥进行验证，示例性的，认证服务器300可以将该主应用111的身份标识及密钥与存储在本地数据库中的与主应用111对应的身份标识及密钥进行比对，若上述比对一致，则验证通过。示例性的，可以基于主授权凭据请求中的主应用111的身份标识在本地数据库中进行查询，获得与该主应用111的身份标识对应的密钥，若主授权凭据请求中的主应用111的密钥与存储在本地数据库中的主应用111的密钥比对一致，则验证通过。此时，认证服务器300可以颁发与该主应用111对应的主授权凭据，并可以将该主授权凭据发送给主应用111。此外，认证服务器300还可以存储该主授权凭据，由此可以使得认证服务器300后续在收到携带该主授权凭据的请求(例如，代理授权凭据请求或业务访问请求)后，可以验证该主授权凭据的合法性，进而可以提高数据传输的安全性。

可以理解的是，为了保证主授权凭据的有效性及安全性，认证服务器300还可以对该主授权凭据设置有效期限，若该主授权凭据超过该有效期限，则该主授权凭据失效。

步骤109，主应用111向认证服务器300请求代理权限。

具体地，代理权限用于标识代理应用112的业务权限的范围。

主应用111可以向认证服务器300发送代理权限请求，以获得代理权限。其中，该代理权限请求可以包括权限类型、代理应用112的身份标识以及主授权凭据。

现以rfc6749协议进行举例，可以对该协议的授权接口进行修改，用于发送代理权限请求，得到如下示例代码：

POST/token HTTP/1.1

Host:server.example.com

Authorization:Bearer czZCaGRSa3F0MzpnWDFmQmF0M2JW

Content-Type:application/x-www-form-urlencoded

grant_type＝authorization_proxy_token&&proxy_client_id＝xxx

其中，字段Authorization中新增Bearer类型，该Bearer类型用于标识主应用111的主授权凭据；字段grant_type新增authorization_proxy_token类型，该authorization_proxy_token类型用于标识代理权限请求中的权限类型为代理权限，新增字段proxy_client_id，字段proxy_client_id用于标识代理应用112的身份标识。

步骤110，认证服务器300基于主应用111的代理权限请求颁发代理权限，将该代理权限发送给主应用111。

具体地，认证服务器300收到主应用111的代理权限请求后，可以验证主授权凭据的合法性。示例性的，认证服务器300可以查询是否存在与代理授权凭据请求中的主授权凭据一致的授权凭据。若存在与代理授权凭据请求中的主授权凭据一致的授权凭据，则可以认为该主授权凭据由认证服务器300颁发，也就是说，该主授权凭据合法，则可以基于该主授权凭据获取与主应用111对应的预设业务权限的范围，并可以基于主应用111的业务权限的范围获得与代理应用112对应的业务权限的范围。示例性的，表1为主应用111的业务权限的范围和代理应用112的业务权限的范围。可以理解的是，该表1可以预先存储在认证服务器300中。

表1

如表1所示，主应用111的业务权限的范围可以包括支持openid.proxy模式、email.proxy模式、profile.proxy模式、push操作及SMS操作；代理应用112的业务权限的范围可以包括支持openid.proxy模式、email.proxy模式及profile.proxy模式，但不支持push操作及sms操作。由上述表1可知，代理应用112的业务权限的范围比主应用111的业务权限的范围少了push操作及sms操作。

接着，认证服务器300可以基于代理应用112的业务权限的范围生成代理权限，由此可以使得代理应用112的业务权限降级，避免由代理应用112的业务权限超范围导致的安全隐患。

可以理解的是，该代理权限与上述代理权限请求中的代理应用112的身份标识对应。举例来说，假设一个主应用111本次为一个代理应用112(例如，支付应用)请求代理权限，该代理权限请求中携带该代理应用112的身份标识，则认证服务器300在收到上述代理权限请求后，为该代理应用112颁发代理权限。

步骤111，响应于用户访问代理应用112的操作，主应用111调用代理应用112。

具体地，用户可以在终端100上进行操作，以打开主应用111。接着，用户可以在主应用111中进行操作，例如，用户可以点击主应用111中与代理应用112对应的链接，以访问代理应用112。示例性的，用户可以在电商应用中点击支付应用，以访问支付应用，使得用户可以发起支付业务。响应于用户访问代理应用112的操作，当前主应用111调用代理应用112。其中，主应用111在调用代理应用的过程中，可以携带代理权限，由此可以使得该代理应用112使用与该代理权限对应的业务权限，进而可以保证用户的个人数据的安全。

步骤112，代理应用112基于代理权限向业务服务器200发起业务访问请求。

具体地，代理应用112可以通过验证接口向业务服务器200发送业务访问请求，以实现对应的业务操作，例如，发起支付业务。其中，该业务访问请求可以包含代理应用112的身份标识、服务器地址及代理权限。该业务访问请求的发送方式可以通过JWT方式。

现以rfc7523协议进行举例，可以对该协议的凭据验证接口进行修改，用于发送业务访问请求，得到如下示例代码：

POST/token.oauth2 HTTP/1.1

Host:authz.example.net

Content-Type:application/x-www-form-urlencoded

grant_type＝urn％3Aietf％3Aparams％3Aoauth％3Agrant-type％3Ajwt-bearer-with-proxy-token

&assertion＝eyJhbGciOiJFUzI1NiIsImtpZCI6IjE2In0.

eyJpc3Mi[...omitted for brevity...].

J9l-ZhwP[...omitted for brevity...]

其中，grant_type字段新增jwt-bearer-with-proxy-token类型，该jwt-bearer-with-proxy-token类型用于标识业务访问请求中的权限类型为代理权限。

如图4所示为上述业务访问请求的JWT数据包400的示意图。其中，JWT数据包400可以包含头部410及载荷420，头部410包含代理权限字段411、代理应用身份标识字段412及服务器地址字段413，代理权限字段411用于标识代理权限信息421在载荷420中的位置，代理应用身份标识字段412用于标识代理应用身份标识在载荷420中的位置，服务器地址字段413用于标识服务器地址信息在载荷420中的位置。载荷420包含与代理权限字段411对应的代理权限信息321、与代理应用身份标识字段412对应的代理应用身份标识信息422以及与服务器地址字段413对应的服务器地址信息423，其中，权限信息421可以包括代理应用112的业务权限的范围，代理应用身份标识信息422可以包括代理应用411的身份标识，服务器地址信息423可以包括代理应用112的服务器地址(例如，代理应用服务器的IP地址或域名)。

可以理解的是，头部410还可以包含声明字段414，该声明字段414用于标识声明信息424在载荷420中的位置。载荷420还包含与声明字段414对应的声明信息424。其中，声明信息424可以包括JWT签发者(例如，签发该JWT的服务器地址)、签发时间、签发有效时间等声明信息。在一些实施例中，JWT数据包400也可以不包含上述声明信息，本申请实施例对此不作特殊限定。

步骤113，业务服务器200基于业务访问请求调用认证服务器300的认证接口进行验证。

具体地，业务服务器200可以调用认证服务器300的认证接口(例如，OAuth2.0协议的认证接口)，将业务访问请求中的信息转发给认证服务器300，以对该业务访问请求进行验证。示例性的，业务服务器200可以将代理应用112的身份标识、服务器地址及代理权限发送给认证服务器300，以进行验证。

步骤114，认证服务器300对服务器地址进行验证。

具体地，认证服务器300在步骤102中已经存储代理应用112的身份标识与服务器地址的关联关系，因此，该认证服务器300可以根据业务服务器200转发的代理应用112的身份标识查询获得对应的服务器地址，并可以将业务服务器200转发的服务器地址与存储在本地的服务器地址进行比对。

若本地存储的服务器地址中存在与业务服务器200发送的服务器地址一致的服务器地址，则执行步骤116。

若本地存储的服务器地址不存在与业务服务器200发送的服务器地址一致的服务器地址，则执行步骤115。

步骤115，认证服务器300向代理应用112反馈认证失败消息，结束本次业务访问。

步骤116，认证服务器300对代理权限进行权限验证。

具体地，认证服务器300可以基于代理应用112的身份标识获取代理应用112的业务权限的范围。示例性的，认证服务器300可以基于代理应用112的身份标识在表1中进行查询，以获得对应的代理应用112的业务权限的范围。接着，认证服务器300可以将查询获得的代理应用112的业务权限的范围与业务访问请求中与代理权限对应的业务权限的范围进行比对，以完成对代理权限的验证。

若查询获得的代理应用112的业务权限的范围与业务访问请求中与代理权限对应的业务权限的范围一致，则执行步骤118。

若查询获得的代理应用112的业务权限的范围与业务访问请求中与代理权限对应的业务权限的范围不一致，则执行步骤117。

需要说明的是，在判断查询获得的代理应用112的业务权限的范围与业务访问请求中与代理权限对应的业务权限的范围是否一致时，可以判断业务访问请求中与代理权限对应的业务权限的范围是否包含在查询获得的代理应用112的业务权限的范围内，若判断业务访问请求中与代理权限对应的业务权限的范围包含在查询获得的代理应用112的业务权限的范围内，则查询获得的代理应用112的业务权限的范围与业务访问请求中与代理权限对应的业务权限的范围一致；若判断业务访问请求中与代理权限对应的业务权限的范围不包含在查询获得的代理应用112的业务权限的范围内，则查询获得的代理应用112的业务权限的范围与业务访问请求中与代理权限对应的业务权限的范围不一致。此外，也可以判断查询获得的代理应用112的业务权限的范围与业务访问请求中与代理权限对应的业务权限的范围是否相同，若判断业务访问请求中与代理权限对应的业务权限的范围与查询获得的代理应用112的业务权限的范围相同，则查询获得的代理应用112的业务权限的范围与业务访问请求中与代理权限对应中的业务权限的范围一致；若判断业务访问请求中与代理权限对应的业务权限的范围与查询获得的代理应用112的业务权限的范围不相同，则查询获得的代理应用112的业务权限的范围与业务访问请求中与代理权限对应的业务权限的范围不一致。本申请实施例对此不作特殊限定。

步骤117，认证服务器300向代理应用112反馈认证失败消息，结束本次业务访问。

步骤118，认证服务器300向业务服务器200返回验证成功消息，使得业务服务器200允许代理应用112进行业务访问。

步骤119，业务服务器200基于业务访问请求向代理应用112返回业务处理结果。

具体地，业务服务器200收到验证成功消息后，可以基于业务访问请求进行业务处理，示例性的，若本次业务访问请求是支付请求，则业务服务器200可以完成本次的支付任务，并将业务处理结果(例如，支付结果)返回给代理应用112。

本申请实施例中，通过认证服务器预先给代理应用分配代理权限，以区分主应用的主权限，用户在主应用中调用代理应用进行业务访问时，业务访问请求中携带代理权限，由认证服务器基于该代理权限进行权限验证，由此可以使得代理应用的业务权限降级，进而保证用户的个人数据的安全。

接着结合图5和图6对本申请另一个实施例提供的业务访问方法进行说明，如图5所示为本申请业务访问方法另一个实施例的流程图，包括：

步骤201，代理应用112向认证服务器300发送注册请求。

具体地，代理应用112可以是主应用111中被调用的第三方应用程序，示例性的，该代理应用112可以是被调用的支付应用程序；该代理应用112也可以是其它被调用的第三方应用程序，本申请实施例对此不作特殊限定。其中，主应用111可以是用户在终端100上已安装的应用程序，示例性的，该主应用111可以包括社交应用程序、订餐应用程序、电商应用程序等；该主应用111也可以是其它通过程序安装包安装在终端100上的应用程序，本申请实施例对此不作特殊限定。该终端100可以是手机、平板等具有通信功能的设备。认证服务器300可以是用于对主应用111和代理应用112进行注册、以及对主应用111和代理应用112的业务权限颁发授权凭据及验证的服务器。

代理应用112可以通过注册接口在认证服务器300上进行注册，示例性的，代理应用112可以通过注册接口向认证服务器300发送注册请求。其中，该注册请求可以包括应用类型及服务器地址。该应用类型可以用于标识代理应用112的类型，例如，可以将代理应用112的类型设置为代理应用类型。该服务器地址用于标识代理应用112的服务器的地址，在具体实现时，可以通过服务器IP地址或者域名标识代理应用112的服务器的地址，本申请对此不作限定。

步骤202，认证服务器300基于注册请求生成代理应用112的身份标识及密钥。

具体地，认证服务器300收到代理应用112的注册请求后，可以为该代理应用112分配身份标识及密钥，分配身份标识及密钥的过程具体可参考OAuth2.0协议，在此不再赘述。其中，代理应用身份标识可以用于标识代理应用112的身份，也就是说，代理应用身份标识可以用于对代理应用112进行识别。代理应用密钥可以采用本领域常用的对称或非对称密钥，本申请实施例对此不作特殊限定。

可以理解的是，认证服务器300还可以将代理应用112的身份标识、密钥、服务器地址进行存储，例如，认证服务器300可以将上述代理应用112的身份标识、密钥、服务器地址关联后存储在本地数据库中。

步骤203，认证服务器300将代理应用112的身份标识及密钥返回给代理应用112。

步骤204，代理应用112基于代理应用112的身份标识及密钥向认证服务器300请求代理授权凭据。

具体地，该代理授权凭据用于标识代理应用112的业务权限。

步骤205，认证服务器300基于代理应用112的身份标识及密钥颁发代理授权凭据，将该代理授权凭据发送给代理应用112。

具体地，该代理授权凭据可以由认证服务器300颁发，由此可以使得认证服务器300后续收到该代理授权凭据后可以验证该代理授权凭据的合法性。

步骤206，主应用111向认证服务器300发送注册请求。

具体地，主应用111可以通过注册接口在认证服务器300上进行注册，例如，可以通过rfc7591协议的原注册接口进行注册。

步骤207，认证服务器300基于注册请求生成主应用111的身份标识及密钥。

具体地，认证服务器300收到主应用111的注册请求后，可以为该主应用111分配身份标识及密钥，分配身份标识及密钥的过程具体可参考OAuth2.0协议，在此不再赘述。其中，主应用身份标识可以用于标识主应用111的身份，也就是说，主应用身份标识可以用于对主应用111进行识别。主应用密钥可以采用本领域常用的对称或非对称密钥，本申请实施例对此不作特殊限定。

进一步地，认证服务器300还可以将主应用111的身份标识及密钥进行存储，例如，认证服务器300将上述主应用111的身份标识及密钥存储在本地数据库中。

步骤208，认证服务器300将主应用111的身份标识及密钥返回给主应用111。

步骤209，主应用111基于主应用111的身份标识及密钥向认证服务器300请求主授权凭据。

具体地，主授权凭据用于标识主应用111的业务权限。其中，上述主授权凭据请求中包含主应用111的身份标识及密钥。

步骤210，认证服务器300基于主应用111的身份标识及密钥颁发主授权凭据，将该主授权凭据发送给主应用111。

具体地，认证服务器300在收到主应用111的主授权凭据请求后，可以基于授权凭据请求中的主应用111的身份标识及密钥进行验证，示例性的，认证服务器300可以将该主应用111的身份标识及密钥与存储在本地数据库中的与主应用111对应的身份标识及密钥进行比对，若上述比对一致，则验证通过。示例性的，可以基于主授权凭据请求中的主应用111的身份标识在本地数据库中进行查询，获得与该主应用111的身份标识对应的密钥，若主授权凭据请求中的主应用111的密钥与存储在本地数据库中的主应用111的密钥比对一致，则验证通过。此时，认证服务器300可以颁发与该主应用111对应的主授权凭据，并可以将该主授权凭据发送给主应用111。此外，认证服务器300还可以存储该主授权凭据，由此可以使得认证服务器300后续在收到携带该主授权凭据的请求(例如，代理授权凭据请求或业务访问请求)后，可以验证该主授权凭据的合法性，进而可以提高数据传输的安全性。

可以理解的是，为了保证主授权凭据的有效性及安全性，认证服务器300还可以对该主授权凭据设置有效期限，若该主授权凭据超过该有效期限，则该主授权凭据失效。

步骤211，主应用111向认证服务器300请求代理权限。

具体地，代理权限用于标识代理应用112的业务权限的范围。

主应用111可以向认证服务器300发送代理权限请求。其中，该代理权限请求可以包括权限类型、代理应用112的身份标识以及主授权凭据。

步骤212，认证服务器300基于主应用111的请求颁发代理权限，将该代理权限发送给主应用111。

具体地，认证服务器300收到主应用111的代理权限请求后，可以验证主授权凭据的合法性。示例性的，认证服务器300可以查询是否存在与代理授权凭据请求中的主授权凭据一致的授权凭据。若存在与代理授权凭据请求中的主授权凭据一致的授权凭据，则可以认为该主授权凭据由认证服务器300颁发，也就是说，该主授权凭据合法，则可以基于该主授权凭据获取与主应用111对应的业务权限的范围以及与代理应用112对应的业务权限的范围。

接着，认证服务器300可以基于代理应用112的业务权限的范围生成代理权限，由此可以使得代理应用112的业务权限降级，避免由代理应用112的业务权限超范围导致的安全隐患。

可以理解的是，该代理权限与上述代理权限请求中的代理应用112的身份标识对应。举例来说，假设一个主应用111本次为一个代理应用112(例如，支付应用)请求代理权限，该代理权限请求中携带该代理应用112的身份标识，则认证服务器300在收到上述代理权限请求后，为该代理应用112颁发代理权限。

步骤213，响应于用户调用代理应用112的操作，主应用111调用代理应用112。

具体地，用户可以在终端100上进行操作，以打开主应用111。接着，用户可以在主应用111中进行操作，例如，用户可以点击主应用111中与代理应用112对应的链接，以访问代理应用112。示例性的，用户可以在电商应用中点击支付应用，以访问支付应用，使得用户可以发起支付业务。响应于用户访问代理应用112的操作，当前主应用111调用代理应用112。其中，主应用111在调用代理应用的过程中，可以携带代理权限，由此可以使得该代理应用112使用与该代理权限对应的业务权限，进而可以保证用户的个人数据的安全。

步骤214，代理应用112基于代理应用112的身份标识、代理授权凭据、服务器地址及代理权限向业务服务器200发起业务访问请求。

具体地，本步骤214与步骤112的区别在于，上述业务访问请求中除了包含代理应用112的身份标识、服务器地址及代理权限外，还可以包含代理授权凭据。其中，代理权限可以包括代理应用112的业务权限的范围。

图6为业务访问请求的JWT格式的数据包600的示意图。其中，数据包600可以包含头部610及载荷620，头部610包含代理授权凭据字段611、代理权限字段612、代理应用身份标识字段613及服务器地址字段614，代理授权凭据字段611用于标识代理授权凭据信息621在载荷620中的位置，代理权限据字段612用于标识代理权限信息622在载荷620中的位置，代理应用身份标识字段613用于标识代理应用身份标识信息623在载荷620中的位置，服务器地址字段614用于标识服务器地址信息624在载荷620中的位置。载荷620包含与代理授权凭据字段611对应的代理授权凭据信息621、与代理权限字段612对应的代理权限信息622、与代理应用身份标识字段613对应的代理应用身份标识信息623以及与服务器地址字段614对应的服务器地址信息624。其中，代理授权凭据信息611可以包括由认证服务器300给代理应用112颁发的代理授权凭据，代理权限信息622可以包括代理应用112的业务权限的范围，代理应用身份标识信息623可以包括代理应用112的身份标识，服务器地址信息624可以包括代理应用112的服务器地址。

可以理解的是，头部610还可以包含声明字段615，该声明字段615用于标识声明信息625在载荷620中的位置。载荷620还包含与声明字段615对应的声明信息625。其中，声明信息625可以包括JWT签发者(例如，签发该JWT的服务器地址)、签发时间、签发有效时间等声明信息。在一些实施例中，数据包600也可以不包含上述声明信息，本申请实施例对此不作特殊限定。

步骤215，业务服务器200基于业务访问请求调用认证服务器300的认证接口进行验证。

具体地，业务服务器200可以调用认证服务器300的认证接口(例如，OAuth2.0协议的认证接口)，将业务访问请求中的信息发送给认证服务器300，以对该业务访问请求进行验证。示例性的，业务服务器200可以将代理应用112的身份标识、代理应用112的服务器地址、代理授权凭据及代理权限发送给认证服务器300，以进行验证，其中，上述验证可以包括合法性验证和权限验证。

步骤216，认证服务器300对代理授权凭据进行合法性验证。

具体地，认证服务器300可以基于代理授权凭据进行合法性验证。例如，认证服务器300可以查询是否存在与代理授权凭据一致的授权凭据，以确定该代理授权凭据是否由认证服务器300颁发，，由此可以验证该代理授权凭据的合法性。

若该代理授权凭据合法，则可以进一步执行步骤218。

若该代理授权凭据非法，则可以进一步执行步骤217。

步骤217，认证服务器300向代理应用112反馈认证失败消息，结束本次业务访问。

步骤218，认证服务器300对服务器地址进行验证。

具体地，认证服务器300在步骤202中已经存储代理应用112的身份标识与服务器地址的关联关系，因此，该认证服务器300可以根据业务服务器200转发的代理应用112的身份标识查询获得对应的服务器地址，并可以将业务服务器200转发的服务器地址与存储在本地的服务器地址进行比对。

若本地存储的服务器地址中存在与业务服务器200发送的服务器地址一致的服务器地址，则执行步骤220。

若本地存储的服务器地址中不存在与业务服务器200发送的服务器地址一致的服务器地址，则执行步骤219。

步骤219，认证服务器300向代理应用112反馈认证失败消息，结束本次业务访问。

步骤220，认证服务器300对代理权限进行权限验证。

具体地，认证服务器300可以基于代理应用112的身份标识获取代理应用112的业务权限的范围。示例性的，认证服务器300可以基于代理应用112的身份标识在表1中进行查询，以获得对应的代理应用112的业务权限的范围。接着，认证服务器300可以将查询获得的代理应用112的业务权限的范围与业务访问请求中与代理权限对应的业务权限的范围进行比对，以完成对代理权限的权限验证。

若查询获得的代理应用112的业务权限的范围与业务访问请求中与代理权限对应的业务权限的范围一致，则执行步骤222。

若查询获得的代理应用112的业务权限的范围与业务访问请求中与代理权限对应的业务权限的范围不一致，则执行步骤221。

步骤221，认证服务器300向代理应用112反馈认证失败消息，结束本次业务访问。

步骤222，认证服务器300向业务服务器200返回验证成功消息，使得业务服务器200允许代理应用112进行业务访问。

步骤223，业务服务器200基于业务访问请求向代理应用112返回业务处理结果。

具体地，业务服务器200收到验证成功消息后，可以基于业务访问请求进行业务处理，示例性的，若本次业务访问请求是支付请求，则业务服务器200可以完成本次的支付任务，并将业务处理结果(例如，支付结果)返回给代理应用112。

本申请实施例中，通过认证服务器预先给代理应用分配代理权限，以区分主应用的主权限，用户在主应用中调用代理应用进行业务访问时，业务访问请求中携带代理权限，由认证服务器基于该代理权限进行权限验证，由此可以使得代理应用的业务权限降级，进而保证用户的个人数据的安全。同时，用户在调用代理应用进行业务访问时，业务访问请求中还携带代理授权凭据，认证服务器在对代理权限进行权限验证前，对该代理授权凭据进行验证，可以提高安全性，进而可以进一步保证用户的个人数据的安全。

接着结合图7对本申请再一个实施例提供的业务访问方法进行说明，如图7所示为本申请业务访问方法再一个实施例的流程图，应用于第一电子设备，包括：

步骤301，第一电子设备接收第二应用发送的注册请求，为第二应用分配身份信息及密钥。

具体地，该第二应用可以是上述代理应用112。该第一电子设备可以是上述认证服务器300。当该第一电子设备收到第二应用的注册请求后，可以生成与该第二应用对应的第二应用身份信息及密钥，将该第二应用的服务器地址信息与第二应用身份信息进行关联后存储，并将该第二应用身份信息及密钥发送给该第二应用；其中，该注册请求中可以包括该第二应用的服务器地址信息，示例性的，该服务器地址信息可以包括服务器地址。

步骤302，第一电子设备接收第二应用发送的第二应用授权凭据请求，向第二应用颁发第二应用授权凭据。

可选地，第一电子设备还可以向第二应用颁发第二应用授权凭据。其中，该第二应用授权凭据用于标识第二应用的业务访问凭据。该第二应用授权凭据请求可以包括第二应用身份标识及密钥。

当第一电子设备收到第二应用发送的第二应用授权凭据请求后，可以获取该第二应用授权凭据请求中的第二应用身份信息及密钥。接着，可以根据第二应用身份信息进行查询，获得与第二应用身份信息对应的密钥。并将该查询获得的密钥与该第二应用授权凭据请求中的密钥进行比对，响应于查询获得的密钥与第二应用授权凭据请求中的密钥一致，颁发第二应用授权凭据，并将该第二应用授权凭据发送给第二应用。

步骤303，第一电子设备接收第一应用发送的第二应用权限请求，将第二应用权限范围发送给第一应用。

具体地，该第一应用可以是上述主应用111。该第二应用权限请求用于获取第二应用权限范围，该第二应用权限范围可以是第二应用的业务访问的权限范围。其中，该第二应用权限请求包括第二应用身份标识及第一应用授权凭据，该第一应用授权凭据用于标识该第一应用的业务访问凭据。因此，第一电子设备可以根据该第一应用授权凭据获取该第一应用的预设权限范围。接着，第一电子设备可以基于该第一应用的预设权限范围查询获取对应的第二应用权限范围，其中，该第二应用权限范围可以是第二应用的业务访问的权限范围。接着，第一电子设备可以将该第二应用权限范围与第二应用身份信息关联后存储，并可以将该第二应用权限范围发送给第一应用。

步骤304，第一电子设备接收第二电子设备发送的验证请求。

具体地，该第二电子设备可以是上述业务服务器200。其中，该验证请求用于对业务访问请求进行验证，该业务访问请求由第三电子设备基于第二应用向第二电子设备发起，该第二应用由上述第三电子设备中的第一应用调用，该验证请求包括第二应用权限范围及第二应用的服务器地址信息。该第三电子设备可以是上述终端100。

步骤305，第一电子设备对第二应用授权凭据进行验证。

可选地，该验证请求中还可以携带第二应用授权凭据，则第一电子设备在收到验证请求后，可以对该第二应用授权凭据进行验证。其中，验证的方式可以通过查询是否存在与第二应用授权凭据一致的授权凭据实现。

步骤306，第一电子设备基于第二应用的服务器地址信息进行验证。

具体地，第一电子设备可以基于第二应用身份信息进行查询，获得与第二应用身份信息对应的第二应用的服务器地址信息；接着，第一电子设备将查询获得的第二应用的服务器地址信息与验证请求中的第二应用的服务器地址信息进行比对，以完成对第二应用的服务器地址信息的验证。

步骤307，响应于第二应用的服务器地址信息的验证通过，第一电子设备基于第二应用权限范围进行权限验证。

具体地，第一电子设备可以基于第二应用身份信息进行查询，获得与第二应用身份信息对应的第二应用权限范围；接着，第一电子设备将查询获得的第二应用权限范围与验证请求中的第二应用权限范围进行比对，以完成权限验证。

步骤308，响应于权限验证通过，第一电子设备向第二电子设备返回验证成功消息，使得第二电子设备允许第三电子设备中的第二应用基于第二应用权限范围进行业务访问。

图8为本申请业务访问装置一个实施例的结构示意图，如图8所示，上述业务访问装置80可以包括：接收模块81、第一验证模块82、第二验证模块83及发送模块84；

接收模块81，用于接收第二电子设备发送的验证请求，其中，验证请求用于对业务访问请求进行验证，业务访问请求由第三电子设备基于第二应用向第二电子设备发起，第二应用由第三电子设备中的第一应用调用，验证请求包括第二应用权限范围及第二应用的服务器地址信息，第二应用权限范围用于标识第二应用的业务访问的权限范围；

第一验证模块82，用于基于第二应用的服务器地址信息进行验证；

第二验证模块83，用于响应于第二应用的服务器地址信息的验证通过，基于第二应用权限范围进行权限验证；

发送模块84，用于响应于权限验证通过，向第二电子设备返回验证成功消息，使得第二电子设备允许第三电子设备中的第二应用基于第二应用权限范围进行业务访问。

在一种可能的实现方式中，验证请求还包括第二应用身份信息，上述装置80还包括：注册模块85；

注册模块85，用于接收第二应用的注册请求，其中，注册请求包括第二应用的服务器地址信息；生成第二应用身份信息及对应的密钥，将第二应用的服务器地址信息与第二应用身份信息进行关联后存储，并将第二应用身份信息及密钥发送给第二应用。

在一种可能的实现方式中，上述第一验证模块82包括：第一查询单元821及第一验证单元822；

第一查询单元821，用于基于第二应用身份信息进行查询，获得与第二应用的身份信息对应的第二应用的服务器地址信息；

第一验证单元822，用于将查询获得的第二应用的服务器地址信息与验证请求中的第二应用的服务器地址信息进行比对，以完成对第二应用的服务器地址信息的验证。

在一种可能的实现方式中，上述装置80还包括：代理权限分配模块86；

代理权限分配模块86，用于接收第一应用发送的第二应用权限请求，其中，第二应用权限请求用于获取第二应用权限范围，第二应用权限范围包括第二应用身份信息及第一应用授权凭据，第一应用授权凭据用于标识第一应用的业务访问凭据；基于第一应用授权凭据查询获得第一应用的预设权限范围，其中，第一应用的预设权限范围用于标识第一应用的业务访问的权限范围；基于第一应用的预设权限范围查询获取对应的第二应用权限范围，将第二应用权限范围与第二应用身份信息关联后存储；并将第二应用权限范围发送给第一应用。

在一种可能的实现方式中，上述第二验证模块83包括：第二查询单元831及第二验证单元832；

第二查询单元831，用于基于第二应用身份信息进行查询，获得与第二应用身份信息对应的第二应用权限范围；

第二验证单元832，用于将查询获得的第二应用权限范围与验证请求中的第二应用权限范围进行比对，以完成权限验证。

在一种可能的实现方式中，上述装置80还包括：代理凭据分配模块87；

代理凭据分配模块87，用于接收第二应用的第二应用授权凭据请求，其中，第二应用授权凭据请求用于获取第二应用授权凭据，第二应用授权凭据用于标识第二应用的业务访问凭据，第二应用授权凭据请求包括第二应用身份信息及密钥；基于第二应用身份信息识进行查询，获得与第二应用身份信息对应的密钥；将查询获得的密钥与第二应用授权凭据请求中的密钥进行比对，响应于查询获得的密钥与第二授权凭据请求中的密钥一致，颁发第二应用授权凭据，并将第二应用授权凭据发送给第二应用。

在一种可能的实现方式中，上述装置80还包括：第三验证模块88；

第三验证模块88，用于查询是否存在与第二应用授权凭据一致的授权凭据，以完成对第二应用授权凭据的验证。

应理解以上图8所示的业务访问装置的各个模块的划分仅仅是一种逻辑功能的划分，实际实现时可以全部或部分集成到一个物理实体上，也可以物理上分开。且这些模块可以全部以软件通过处理元件调用的形式实现；也可以全部以硬件的形式实现；还可以部分模块以软件通过处理元件调用的形式实现，部分模块通过硬件的形式实现。例如，检测模块可以为单独设立的处理元件，也可以集成在电子设备的某一个芯片中实现。其它模块的实现与之类似。此外这些模块全部或部分可以集成在一起，也可以独立实现。在实现过程中，上述方法的各步骤或以上各个模块可以通过处理器元件中的硬件的集成逻辑电路或者软件形式的指令完成。

例如，以上这些模块可以是被配置成实施以上方法的一个或多个集成电路，例如：一个或多个特定集成电路(Application Specific Integrated Circuit；以下简称：ASIC)，或，一个或多个微处理器(Digital Singnal Processor；以下简称：DSP)，或，一个或者多个现场可编程门阵列(Field Programmable Gate Array；以下简称：FPGA)等。再如，这些模块可以集成在一起，以片上***(System-On-a-Chip；以下简称：SOC)的形式实现。

图9为本申请电子设备900一个实施例的结构示意图，其中，认证服务器300可以是上述电子设备900；如图9所示，上述电子设备900可以是数据处理设备，也可以是内置于上述数据处理设备的电路设备。该电子设备900可以用于执行本申请图1-图7所示实施例提供的方法中的功能/步骤。

如图9所示，第一电子设备900以通用计算设备的形式表现。

上述第一电子设备900可以包括：一个或多个处理器910；通信接口920；存储器930；连接不同***组件(包括存储器930和处理器910)的通信总线940，数据库950；以及一个或多个计算机程序。

其中，上述一个或多个计算机程序被存储在上述存储器中，上述一个或多个计算机程序包括指令，当上述指令被上述第一电子设备执行时，使得上述第一电子设备执行以下步骤：

接收第二电子设备发送的验证请求，其中，验证请求用于对业务访问请求进行验证，业务访问请求由第三电子设备基于第二应用向第二电子设备发起，第二应用由第三电子设备中的第一应用调用，验证请求包括第二应用权限范围及第二应用的服务器地址信息，第二应用权限范围用于标识第二应用的业务访问的权限范围；

基于第二应用的服务器地址信息进行验证；

响应于第二应用的服务器地址信息的验证通过，基于第二应用权限范围进行权限验证；

响应于权限验证通过，向第二电子设备返回验证成功消息，使得第二电子设备允许第三电子设备中的第二应用基于第二应用权限范围进行业务访问。

其中一种可能的实现方式中，验证请求还包括第二应用身份信息，上述指令被上述第一电子设备执行时，使得上述第一电子设备执行接收第二电子设备发送的验证请求的步骤之前，还执行以下步骤：

接收第二应用的注册请求，其中，注册请求包括第二应用的服务器地址信息；

生成第二应用身份信息及对应的密钥，将第二应用的服务器地址信息与第二应用身份信息进行关联后存储，并将第二应用身份信息及密钥发送给第二应用。

其中一种可能的实现方式中，上述指令被上述第一电子设备执行时，使得上述第一电子设备执行基于第二应用的服务器地址信息进行验证的步骤包括：

基于第二应用身份信息进行查询，获得与第二应用身份信息对应的第二应用的服务器地址信息；

将查询获得的第二应用的服务器地址信息与验证请求中的第二应用的服务器地址信息进行比对，以完成对第二应用的服务器地址信息的验证。

其中一种可能的实现方式中，上述指令被上述第一电子设备执行时，使得上述第一电子设备执行接收第二电子设备发送的验证请求的步骤之前，还执行以下步骤：

第一应用发送的第二应用权限请求，其中，第二应用权限请求用于获取第二应用权限范围，第二应用权限范围包括第二应用身份信息及第一应用授权凭据，第一应用授权凭据用于标识第一应用的业务访问凭据；

基于第一应用授权凭据查询获得第一应用的预设权限范围，其中，第一应用的预设权限范围用于标识第一应用的业务访问的权限范围；

基于第一应用的预设权限范围查询获取对应的第二应用权限范围，将第二应用权限范围与第二应用身份信息关联后存储，并将第二应用权限范围发送给第一应用。

其中一种可能的实现方式中，上述指令被上述第一电子设备执行时，使得上述第一电子设备执行基于第二应用权限范围进行权限验证的步骤包括：

基于第二应用身份信息进行查询，获得与第二应用身份信息对应的第二应用权限范围；

将查询获得的第二应用权限范围与验证请求中的第二应用权限范围进行比对，以完成权限验证。

其中一种可能的实现方式中，上述指令被上述第一电子设备执行时，使得上述第一电子设备执行将第二应用身份信息及密钥发送给第二应用的步骤之后，还执行以下步骤：

接收第二应用的第二应用授权凭据请求，其中，第二应用授权凭据请求用于获取第二应用授权凭据，第二应用授权凭据用于标识第二应用的业务访问凭据，第二应用授权凭据请求包括第二应用身份信息及密钥；

基于第二应用身份信息识进行查询，获得与第二应用身份信息对应的密钥；

将查询获得的密钥与第二应用授权凭据请求中的密钥进行比对，响应于查询获得的密钥与第二授权凭据请求中的密钥一致，颁发第二应用授权凭据，并将第二应用授权凭据发送给第二应用。

其中一种可能的实现方式中，验证请求还包括第二应用授权凭据，上述指令被上述第一电子设备执行时，使得上述第一电子设备执行基于第二应用的服务器地址信息进行验证的步骤之前，还执行以下步骤：

查询是否存在与第二应用授权凭据一致的授权凭据，以完成对第二应用授权凭据的验证。

可以理解的是，本发明实施例示意的各模块间的接口连接关系，只是示意性说明，并不构成对第一电子设备900的结构限定。在本申请另一些实施例中，第一电子设备900也可以采用上述实施例中不同的接口连接方式，或多种接口连接方式的组合。

可以理解的是，上述电子设备等为了实现上述功能，其包含了执行各个功能相应的硬件结构和/或软件模块。本领域技术人员应该很容易意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，本申请实施例能够以硬件或硬件和计算机软件的结合形式来实现。某个功能究竟以硬件还是计算机软件驱动硬件的方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本发明实施例的范围。

本申请实施例可以根据上述方法示例对上述电子设备等进行功能模块的划分，例如，可以对应各个功能划分各个功能模块，也可以将两个或两个以上的功能集成在一个处理模块中。上述集成的模块既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。需要说明的是，本发明实施例中对模块的划分是示意性的，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式。

通过以上的实施方式的描述，所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，仅以上述各功能模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能模块完成，即将装置的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能。上述描述的***，装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

在本申请实施例各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请实施例的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)或处理器执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：快闪存储器、移动硬盘、只读存储器、随机存取存储器、磁碟或者光盘等各种可以存储程序代码的介质。

以上所述，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何在本申请揭露的技术范围内的变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以所述权利要求的保护范围为准。

Claims (16)

1.一种业务访问方法，应用于第一电子设备，其特征在于，所述方法包括：

接收第二电子设备发送的验证请求，其中，所述验证请求用于对业务访问请求进行验证，所述业务访问请求由第三电子设备基于第二应用向所述第二电子设备发起，所述第二应用由所述第三电子设备中的第一应用调用，所述验证请求包括第二应用权限范围及所述第二应用的服务器地址信息，所述第二应用权限范围用于标识所述第二应用的业务访问的权限范围；

基于所述第二应用的服务器地址信息进行验证；

响应于所述第二应用的服务器地址信息的验证通过，基于所述第二应用权限范围进行权限验证；

响应于权限验证通过，向所述第二电子设备返回验证成功消息，使得所述第二电子设备允许所述第三电子设备中的第二应用基于所述第二应用权限范围进行业务访问。

2.根据权利要求1所述的方法，其特征在于，所述验证请求还包括第二应用身份信息，所述接收第二电子设备发送的验证请求之前，还包括：

接收所述第二应用的注册请求，其中，所述注册请求包括所述第二应用的服务器地址信息；

生成第二应用身份信息及对应的密钥，将所述第二应用的服务器地址信息与所述第二应用身份信息进行关联后存储，并将所述第二应用身份信息及所述密钥发送给所述第二应用。

3.根据权利要求1或2所述的方法，其特征在于，所述基于所述第二应用的服务器地址信息进行验证包括：

基于所述第二应用身份信息进行查询，获得与所述第二应用身份信息对应的第二应用的服务器地址信息；

将所述查询获得的第二应用的服务器地址信息与所述验证请求中的第二应用的服务器地址信息进行比对，以完成对所述第二应用的服务器地址信息的验证。

4.根据权利要求2所述的方法，其特征在于，所述接收第二电子设备发送的验证请求之前，还包括：

接收所述第一应用发送的第二应用权限请求，其中，所第二应用权限请求用于获取第二应用权限范围，所述第二应用权限请求包括所述第二应用身份信息及第一应用授权凭据，所述第一应用授权凭据用于标识所述第一应用的业务访问凭据；

基于所述第一应用授权凭据查询获得所述第一应用的预设权限范围；

基于所述第一应用的预设权限范围，查询获得对应的第二应用权限范围，将所述第二应用权限范围与所述第二应用身份信息关联后存储，并将所述第二应用权限范围发送给所述第一应用。

5.根据权利要求1-4任一项所述的方法，其特征在于，所述基于所述第二应用权限范围进行权限验证包括：

基于所述第二应用身份信息进行查询，获得与所述第二应用身份信息对应的第二应用权限范围；

将所述查询获得的第二应用权限范围与所述验证请求中的第二应用权限范围进行比对，以完成权限验证。

6.根据权利要求2所述的方法，其特征在于，所述将所述第二应用身份信息及所述密钥发送给所述第二应用之后，还包括：

接收所述第二应用发送的第二应用授权凭据请求，其中，所述第二应用授权凭据请求用于获取第二应用授权凭据，所述第二应用授权凭据用于标识所述第二应用的业务访问凭据，所述第二应用授权凭据请求包括所述第二应用身份信息及密钥；

基于所述第二应用身份信息进行查询，获得与所述第二应用身份信息对应的密钥；

将所述查询获得的密钥与所述第二应用授权凭据请求中的密钥进行比对，响应于所述查询获得的密钥与所述第二应用授权凭据请求中的密钥一致，颁发所述第二应用授权凭据，并将所述第二应用授权凭据发送给所述第二应用。

7.根据权利要求6所述的方法，其特征在于，所述验证请求还包括第二应用授权凭据，所述基于所述第二应用的服务器地址信息进行验证之前，还包括：

查询是否存在与所述第二应用授权凭据一致的授权凭据，以完成对所述第二应用授权凭据的验证。

8.一种第一电子设备，其特征在于，包括：存储器，所述存储器用于存储计算机程序代码，所述计算机程序代码包括指令，当所述第一电子设备从所述存储器中读取所述指令，以使得所述第一电子设备执行以下步骤：

接收第二电子设备发送的验证请求，其中，所述验证请求用于对业务访问请求进行验证，所述业务访问请求由第三电子设备基于第二应用向所述第二电子设备发起，所述第二应用由所述第三电子设备中的第一应用调用，所述验证请求包括第二应用权限范围及所述第二应用的服务器地址信息，所述第二应用权限范围用于标识所述第二应用的业务访问的权限范围；

基于所述第二应用的服务器地址信息进行验证；

响应于所述第二应用的服务器地址信息的验证通过，基于所述第二应用权限范围进行权限验证；

响应于权限验证通过，向所述第二电子设备返回验证成功消息，使得所述第二电子设备允许所述第三电子设备中的第二应用基于所述第二应用权限范围进行业务访问。

9.根据权利要求8所述的第一电子设备，其特征在于，所述验证请求还包括第二应用身份信息，所述指令被所述第一电子设备执行时，使得所述第一电子设备执行接收第二电子设备发送的验证请求的步骤之前，还执行以下步骤：

接收所述第二应用的注册请求，其中，所述注册请求包括所述第二应用的服务器地址信息；

生成第二应用身份信息及对应的密钥，将所述第二应用的服务器地址信息与所述第二应用身份信息进行关联后存储，并将所述第二应用身份信息及所述密钥发送给所述第二应用。

10.根据权利要求8或9所述的第一电子设备，其特征在于，所述指令被所述第一电子设备执行时，使得所述第一电子设备执行基于所述第二应用的服务器地址信息进行验证的步骤包括：

基于所述第二应用身份信息进行查询，获得与所述第二应用身份信息对应的第二应用的服务器地址信息；

将所述查询获得的第二应用的服务器地址信息与所述验证请求中的第二应用的服务器地址信息进行比对，以完成对所述第二应用的服务器地址信息的验证。

11.根据权利要求9所述的第一电子设备，其特征在于，所述指令被所述第一电子设备执行时，使得所述第一电子设备执行接收第二电子设备发送的验证请求的步骤之前，还执行以下步骤：

接收所述第一应用发送的第二应用权限请求，其中，所第二应用权限请求用于获取第二应用权限范围，所述第二应用权限请求包括所述第二应用身份信息及第一应用授权凭据，所述第一应用授权凭据用于标识所述第一应用的业务访问凭据；

基于所述第一应用授权凭据查询获得所述第一应用的预设权限范围；

基于所述第一应用的预设权限范围，查询获得对应的第二应用权限范围，将所述第二应用权限范围与所述第二应用身份信息关联后存储，并将所述第二应用权限范围发送给所述第一应用。

12.根据权利要求8-11任一项所述的第一电子设备，其特征在于，所述指令被所述第一电子设备执行时，使得所述第一电子设备执行基于所述第二应用权限范围进行权限验证的步骤包括：

基于所述第二应用身份信息进行查询，获得与所述第二应用身份信息对应的第二应用权限范围；

将所述查询获得的第二应用权限范围与所述验证请求中的第二应用权限范围进行比对，以完成权限验证。

13.根据权利要求9所述的第一电子设备，其特征在于，所述指令被所述第一电子设备执行时，使得所述第一电子设备执行将所述第二应用身份信息及所述密钥发送给所述第二应用的步骤之后，还执行以下步骤：

接收所述第二应用发送的第二应用授权凭据请求，其中，所述第二应用授权凭据请求用于获取第二应用授权凭据，所述第二应用授权凭据用于标识所述第二应用的业务访问凭据，所述第二应用授权凭据请求包括所述第二应用身份信息及密钥；

基于所述第二应用身份信息进行查询，获得与所述第二应用身份信息对应的密钥；

将所述查询获得的密钥与所述第二应用授权凭据请求中的密钥进行比对，响应于所述查询获得的密钥与所述第二应用授权凭据请求中的密钥一致，颁发所述第二应用授权凭据，并将所述第二应用授权凭据发送给所述第二应用。

14.根据权利要求13所述的第一电子设备，其特征在于，所述验证请求还包括第二应用授权凭据，所述指令被所述第一电子设备执行时，使得所述第一电子设备执行基于所述第二应用的服务器地址信息进行验证的步骤之前，还执行以下步骤：

查询是否存在与所述第二应用授权凭据一致的授权凭据，以完成对所述第二应用授权凭据的验证。

15.一种计算机可读存储介质，其特征在于，包括计算机指令，当所述计算机指令在所述第一电子设备上运行时，使得所述第一电子设备执行如权利要求1-7中任一项所述业务访问的方法。

16.一种计算机程序产品，其特征在于，当所述计算机程序产品在计算机上运行时，使得所述计算机执行如权利要求1-7中任一项所述业务访问的方法。

Images