CN104283841A - 对第三方应用进行服务访问控制的方法、装置及系统 - Google Patents

Abstract

本申请实施例公开了对第三方应用进行服务访问控制的方法、装置及系统，所述方法包括：接收到服务访问请求后，判断所述服务访问请求的发送方是否为预置的JS软件开发工具包JSSDK；如果是，则将所述服务访问请求发送到预置的代理服务器，以便所述代理服务器根据所述服务访问请求中携带的信息对所述服务访问请求进行安全性校验，如果校验通过，则将所述服务访问请求重新发送到第一服务器；重新接收到所述服务访问请求后，判断所述服务访问请求的发送方是否为代理服务器；如果是，则根据所述服务访问请求中指定的回传地址返回响应消息。通过本申请实施例，能够提高伪造服务访问请求的难度，提高安全性。

Description

对第三方应用进行服务访问控制的方法、装置及系统

技术领域

本申请涉及第一服务器中的服务访问控制技术领域，特别是涉及对第三方应用进行服务访问控制的方法、装置及系统。

背景技术

在互联网时代，把网站的服务封装成一系列计算机易识别的数据接口，然后开放出去，供第三方开发者使用，这种行为就叫做开放API(ApplicationProgramming Interface，应用程序编程接口)，提供开放API的平台本身就被称为开放平台。通过开放平台，网站不仅能提供对Web网页的简单访问，还可以进行复杂的数据交互，将它们的Web网站转换为与操作系统等价的开发平台。第三方开发者可以基于这些已经存在的、公开的Web网站而开发丰富多彩的应用。

例如，对于某电子商务交易平台而言，就可以面向第三方应用开发者，提供API接口和相关开发环境，这样，第三方软件开发者可通过这些开放API来获取交易平台内的用户信息(卖方和卖方用户信息，私有信息需要授权)、业务对象信息(例如商品的名称、类目、型号、介绍等信息)、业务对象类目信息(全网业务对象的索引及分类明细)、店铺信息、交易明细信息(在取得用户授权的情况下，查询每笔交易的详细情况)、业务对象管理(业务对象的上传、编辑、修改等接口)等信息，并建立相应的电子商务应用。

具体实现时，开放平台向第三方应用开发者提供开放API的方式有多种，例如，SDK本地调用、各种语言的服务器调用、无线手机调用等等。另外还有一种方式是可以将主业务平台(主要用于提供各种具体业务的平台，例如，某电子商务交易平台等)的一些功能以JS组件化的方式开放出去。例如，可以将某主业务平台的购物车、商品详情、收藏夹等功能直接以组件的方式开放给第三方应用开发者，这样，如果某第三方应用中需要添加该主业务平台的“购物车”功能，则直接将购物车功能对应的JS组件代码添加到其开发的应用(例如某第三方网站)中，这样，用户就可以直接从该第三方网站的页面中看到一些商品的详情等信息，并可以直接进行将商品加入到购物车的操作。

但是，在这种以JS组件化的方式开放的实现方式中，由于可能会涉及到主业务平台的核心组件，同时又由于该JS组件直接与对接的用户打交道，因此随之而来的安全问题成为了接下来急需要处理的问题。例如，在第三方应用中使用其添加的各种JS组件对应的功能时，第三方应用需要与开放平台进行交互，期间会涉及到一些请求的发送及响应等等，这就使得整个系统存在被第三方应用通过类似httpclient等方式模拟某功能的风险。例如，某第三方应用在通过某种方式窃取了交互过程中使用的协议及其参数等信息之后，就可以伪造访问请求，来模拟用户登录或者提交表单等操作，从而使得用户在系统中的信息甚至财产等的安全受到威胁。

发明内容

本申请提供了对第三方应用进行服务访问控制的方法、装置及系统，能够提高伪造服务访问请求的难度，提高安全性。

本申请提供了如下方案：

一种对第三方应用进行服务访问控制的方法，所述第三方应用中添加有所述第一服务器中特定功能对应的JS组件，所述方法包括：

接收到服务访问请求后，判断所述服务访问请求的发送方是否为预置的JS软件开发工具包JSSDK；其中，所述JSSDK由第一服务器提供，并由第三方应用中添加的JS组件代码自动将所述JSSDK下载到第三方应用本地；

如果是，则将所述服务访问请求发送到预置的代理服务器，以便所述代理服务器根据所述服务访问请求中携带的信息对所述服务访问请求进行安全性校验，如果校验通过，则将所述服务访问请求重新发送到第一服务器；

重新接收到所述服务访问请求后，判断所述服务访问请求的发送方是否为代理服务器；

如果是，则根据所述服务访问请求中指定的回传地址返回响应消息。

一种对第三方应用进行服务访问控制的方法，所述第三方应用中添加有第一服务器中特定功能对应的JS组件，所述方法包括：

接收第一服务器发送的服务访问请求；所述服务访问请求为第三方应用通过JSSDK发送到第一服务器的服务访问请求；其中，所述JSSDK由第一服务器提供，并由第三方应用中添加的JS组件代码自动将所述JSSDK下载到第三方应用本地；

根据所述服务访问请求中携带的信息对所述服务访问请求进行安全性校验；

如果校验通过，则将所述服务访问请求重新发送到所述第一服务器，以便所述第一服务器根据所述服务访问请求中指定的回传地址返回响应消息。

一种对第三方应用进行服务访问控制的方法，所述第三方应用中添加有第一服务器中特定功能对应的JS组件，所述JS组件的代码自动将第一服务器提供的JSSDK下载到第三方应用本地，所述方法包括由所述JSSDK执行的以下步骤：

监控用户发出的与所述特定功能相关的操作指令；

接收到所述操作指令后，生成服务访问请求；

将所述服务访问请求发送到所述第一服务器，以便所述第一服务器在判断出所述服务访问请求是由JSSDK发出的之后，将所述服务访问请求发送到预置的代理服务器进行安全性校验，并在校验通过后返回响应消息；

接收所述第一服务器返回的响应消息，并提供给所述第三方应用进行处理。

一种对第三方应用进行服务访问控制的系统，所述第三方应用中添加有所述第一服务器中特定功能对应的JS组件，所述系统包括：

第一判断单元，用于接收到服务访问请求后，判断所述服务访问请求的发送方是否为预置的JS软件开发工具包JSSDK；其中，所述JSSDK由第一服务器提供，并由第三方应用中添加的JS组件代码自动将所述JSSDK下载到第三方应用本地；

发送单元，用于如果第一判断单元的判断结果为是，则将所述服务访问请求发送到预置的代理服务器，以便所述代理服务器根据所述服务访问请求中携带的信息对所述服务访问请求进行安全性校验，如果校验通过，则将所述服务访问请求重新发送到第一服务器；

第二判断单元，用于重新接收到所述服务访问请求后，判断所述服务访问请求的发送方是否为代理服务器；

响应单元，用于如果第二判断单元的判断结果为是，则根据所述服务访问请求中指定的回传地址返回响应消息。

一种对第三方应用进行服务访问控制的代理服务器，所述第三方应用中添加有第一服务器中特定功能对应的JS组件，所述代理服务器包括：

请求接收单元，用于接收第一服务器发送的服务访问请求；所述服务访问请求为第三方应用通过JSSDK发送到第一服务器的服务访问请求；其中，所述JSSDK由第一服务器提供，并由第三方应用中添加的JS组件代码自动将所述JSSDK下载到第三方应用本地；

校验单元，用于根据所述服务访问请求中携带的信息对所述服务访问请求进行安全性校验；

请求发送单元，用于如果校验通过，则将所述服务访问请求重新发送到所述第一服务器，以便所述第一服务器根据所述服务访问请求中指定的回传地址返回响应消息。

一种对第三方应用进行服务访问控制的装置，所述第三方应用中添加有第一服务器中特定功能对应的JS组件，所述JS组件的代码自动将第一服务器提供的JSSDK下载到第三方应用本地，所述装置包括：

监控单元，用于监控用户发出的与所述特定功能相关的操作指令；

请求生成单元，用于接收到所述操作指令后，生成服务访问请求；

请求发送单元，用于将所述服务访问请求发送到所述第一服务器，以便所述第一服务器在判断出所述服务访问请求是由JSSDK发出的之后，将所述服务访问请求发送到预置的代理服务器进行安全性校验，并在校验通过后返回响应消息；

响应接收单元，用于接收所述第一服务器返回的响应消息，并提供给所述第三方应用进行处理。

根据本申请提供的具体实施例，本申请公开了以下技术效果：

通过本申请实施例，第三方应用是通过浏览器中集成的JSSDK来发送服务访问请求，这样，如果其他的第三方应用要伪造该服务访问请求，就需要获知浏览器中HTTP协议的所有参数，因此，提高了伪造的难度。对于第一服务器而言，在接收到JSSDK发送的服务访问请求后，还需要发送到代理服务器进行安全性校验，因此，第一服务器只有在重新接收到代理服务器发送的服务访问请求时，才会做出响应，保证了安全性。

其中，还可以对各个第三方应用可以调用的API进行限制，使得一个第三方应用只能调用有限的几个API，这样，即使出现服务访问请求被伪造的情况，也可以使得伪造方只能获取到API权限组内的部分信息，保证用户的大部分信息都是安全的。

当然，实施本申请的任一产品并不一定需要同时达到以上所述的所有优点。

附图说明

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

图1是本申请实施例提供的第一服务器侧方法的流程图；

图2是本申请实施例提供的代理服务器侧方法的流程图；

图3是本申请实施例提供的客户端方法的流程图；

图4是本申请实施例提供的系统的示意图；

图5是本申请实施例提供的代理服务器的示意图；

图6是本申请实施例提供的客户端装置的示意图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员所获得的所有其他实施例，都属于本申请保护的范围。

首先需要说明的是，在本申请实施例中，第一服务器(即开放平台对应的服务器，该第一服务器可以包括一台或多台服务器)同样可以以JS组件的方式将主业务平台的一部分功能开放出去，这样，只要将JS组件的代码添加在第三方应用中，第三方应用就可以实现JS组件对应的功能。当然，在实现具体功能的过程中，第三方应用还需要与第一服务器进行交互，从第一服务器获取一些数据等信息，因此，如何保证交互过程中信息的安全性，就成为需要重点关注的问题。

本申请发明人在实现本申请的过程中发现，现有技术中，之所以会存在被第三方应用通过类似httpclient等方式模拟某功能的风险，一方面原因是在现有技术中，当第三方应用需要与第一服务器进行交互时，是直接通过第三方应用的网页向第一服务器发送请求，这样，只要盗取交互过程中使用的HTTP(Hypertext Transport Protocol，超文本传送协议)协议，第三方应用就可以伪造服务访问请求。因此，在本申请实施例中，为了提高被伪造的概率，并不是直接从网页中发送访问请求，而是通过一个JSSDK(Software DevelopmentKit，软件开发工具包)来发送。其中，JSSDK是由第一服务器提供的一个开发工具包，在某第三方应用添加了第一服务器的某JS组件之后，该JS组件的代码就可以自动从第一服务器将该JSSDK下载到第三方应用本地，在用户使用浏览器等打开第三方应用时，该JSSDK就可以被启动。这样，相当于在浏览器中集成了第一服务器的JSSDK，当用户执行了与该JS组件相关的操作时，如果需要向第一服务器发送服务访问请求，则由浏览器中集成的JSSDK发送，而不是直接从网页发送。也就是说，相当于服务访问请求是由浏览器发送的，这样，如果第三方应用想要伪造服务访问请求，则需要将浏览器相关的HTTP协议中所有的参数都获取到，理论上来讲，一般是不可能做到的，因此，这也就降低了被第三方应用伪造的概率。

当然，为了进一步保证服务访问请求的安全性，在本申请实施例中，第一服务器在接收到一个服务访问请求之后，如果发现该服务访问请求是JSSDK发送的，则可以首先发送到一个代理服务器进行安全性校验。其中，代理服务器可以是部署在第一服务器侧的一个服务器，其中保存有进行安全性校验时所需的信息。如果安全性校验通过，则代理服务器可以重新将服务访问请求发送到第一服务器，第一服务器在重新接收到服务访问请求后，发现其来源是代理服务器，则证明已经验证通过，因此，直接根据服务访问请求中的回传地址返回响应消息即可。

这样，一方面，由于通过JSSDK发送请求，因此，使得第三方应用伪造服务访问请求的难度增加，另一方面，通过代理服务器对第三方应用的身份等进行进一步的安全性校验，使得第三方应用的服务访问的安全性得到保障。下面就对具体的实现方案进行详细地介绍。

实施例一

在该实施例一中，从第一服务器的角度对本申请的技术方案进行介绍，也即，涉及到的方法中，各步骤的执行主体是第一服务器，该第一服务器仍然以JS组件的方式向第三方应用公开部分功能。参见图1，该方法可以包括以下步骤：

S101：接收到服务访问请求后，判断所述服务访问请求的发送方是否为预置的JS软件开发工具包JSSDK；其中，所述JSSDK由第一服务器提供，并由第三方应用中添加的JS组件代码自动将所述JSSDK下载到第三方应用本地；

首先需要说明的是，如果某第三方应用添加了第一服务器公开的某JS组件，则可以在第三方应用的网页中显示出相应的界面，例如，某第三方网站添加了淘宝网中“购物车”功能对应的JS组件，则用户可以在该第三方网站中查看到淘宝网中的商品信息链接，同时页面中还存在“加入购物车”等操作按钮，用户如果对某商品感兴趣，则可以按下该商品的操作按钮，发出将该商品加入购物车的操作指令。

另一方面，第三方应用中添加了某JS组件之后，该JS组件的代码可以自动从第一服务器中下载JSSDK，相当于在浏览器中集成了JSSDK。该JSSDK就可以对用户的相关操作进行监控，如果发现用户执行与该JS组件相关的某操作(例如前述将某商品加入购物车的操作等)，则可以生成服务访问请求，并向第一服务器进行发送。

其中，在实际应用中，第三方应用一般采用调用第一服务器的API的方式来获取第一服务器的服务信息，因此，具体实现时，JSSDK在生成服务访问请求时，具体可以是确定出需要调用的API，并组装API参数。其中，所谓的组装API参数，是指将用于对服务访问请求进行安全性校验的信息组装到API参数中，以便使得服务访问请求可以携带上这些信息，发送到第一服务器侧进行安全性校验。

具体的用于进行安全性校验的信息可以有多种，例如，其中一种可以是第三方应用的标识信息。这种标识信息是由第一服务器为第三方应用颁发的，具体可以是在第三方应用向第一服务器注册获取JS组件时，为第三方应用颁发具有唯一性的标识信息(一般可以称为APPkey)，这样，第三方应用可以用这种标识信息来区分各个第三方应用。

当然，在实际应用中，还可能存在第三方应用的标识信息被泄露的情况，使得其他的第三方应用使用某第三方应用的标识信息来发送服务访问请求，因此，为了能够校验服务访问请求是否来自合法的第三方应用，第一服务器侧还可以记录下各个第三方应用的refer地址与颁发的标识信息之间的对应关系，由于第三方应用的refer地址具有唯一性，因此，refer地址与标识信息之间具有一一对应的关系；在JSSDK发送服务访问请求时，还可以携带上第三方应用的refer地址这一信息，这样，第一服务器侧在进行安全性校验时，还可以验证refer地址与标识信息之间的对应关系是否正确，如果不正确，则可能是标识信息被其他的第三方应用盗取，因此，就可以丢弃该服务访问请求，避免用户信息受到被泄露等威胁。

另外，除了对第三方应用的身份进行校验外，在实际应用中，还可以判断一个服务访问请求是否是在获得用户授权的情况下发出的，如果是，才会返回响应消息，否则，如果没有经过用户授权，则也可以将该请求丢弃。具体实现时，当用户开始使用某第三方应用中的JS组件对应的功能时，该第三方应用可以首先向第一服务器发起授权请求，相应的，第一服务器就可以返回授权确认界面，该授权确认界面中显示有该第三方应用请求授权的具体操作(例如，查看用户信息等等，在第三方应用在向第一服务器中注册时，可以申请操作权限，第一服务器就是根据第三方应用申请的操作权限生成授权确认界面)，用户在查看到授权确认界面之后，如果允许第三方应用执行这些操作，则可以点击“确认”等标识的按钮，对第三方应用的操作进行授权。第一服务器在接收到用户的确认授权指令后，就可以生成一串加密的字符，并保存，例如保存到cookies中，相当于作为服务访问令牌颁发给第三方应用。这样，JSSDK在发送服务访问请求时，也可以从cookies中读取到该服务访问令牌，并且也可以将其组装在API参数中，携带在服务访问请求中一并发送。这样，在第一服务器侧进行校验时，发现其中携带有第一服务器颁发的服务访问令牌，则可以确定该服务访问请求是在得到了用户授权的情况下发出的，进而才会允许对该服务访问请求返回响应消息。

需要说明的是，在进行一次用户授权并将服务访问令牌保存到cookies中之后，JSSDK每次在发送服务访问请求时，直接到cookies中服务该服务访问令牌即可。但是，在不进行特殊设置的情况下，写入到cookies中的信息会随着浏览器的关闭而删除，因此，可以是在每次重新打开浏览器时，重新执行上述用户授权并生成服务访问令牌的过程。当然，在实际应用中，如果是可信度比较高的第三方应用，也可以不必是在每次打开浏览器时重新进行授权及服务访问令牌的获取，具体可以依实际应用的需要而定。

另外，还可以将用户的账户信息也组装到API参数中，以便携带在服务访问请求中发送到第一服务器进行校验。用户的账户信息可以是在用户登录到主业务平台的情况下，从主业务平台的cookies中读取到的。

S102：如果是，则将所述服务访问请求发送到预置的代理服务器，以便所述代理服务器根据所述服务访问请求中携带的信息对所述服务访问请求进行安全性校验，如果校验通过，则将所述服务访问请求重新发送到第一服务器；

在本申请实施例中，对于发送到第一服务器的服务访问请求，第一服务器并不是直接进行安全性校验，而是首先判断服务访问请求的来源，如果发现来自JSSDK，则发送到一个预置的代理服务器进行安全性校验。其中，代理服务器是第一服务器侧设置的一种用于对服务访问请求进行安全性校验的服务器，并且可以有多个，第一服务器中可以预先保存各个代理服务器的IP地址。

代理服务器在接收到服务访问请求后，可以根据其中携带的信息对服务访问请求进行安全性校验。例如，如果服务访问请求中携带有第三方应用的refer地址以及标识信息，则可以判断两者之间的对应关系是否正确。如果其中携带有服务访问令牌，还可以判断该服务访问令牌是否正确，等等。需要说明的是，对于服务访问令牌的校验，也可以在第一服务器中进行。

另外，为了进一步确保安全性，在本申请实施例中，还可以预先为各个第三方应用确定API权限组，并预先保存第三方应用的标识信息与API权限组之间的对应关系，用以表明该第三方应用只具有调用这些API的权限，换言之，对于一个第三方应用而言，其API权限组之外的API，该第三方应用无权调用。因此，代理服务器在接收到服务访问请求后，还可以首先获取到第三方应用的标识信息，并取出该第三方应用的标识信息对应的API权限组，判断当前服务访问请求中请求调用的API是否位于该第三方应用的API权限组中，如果是，并且其他各方面的校验信息也都正确，则可以通过校验。否则，如果当前请求的API没有出现在该第三方应用的API权限组中，则即使其他的校验信息正确，也会将该请求丢弃，或者直接返回请求失败等信息。

也就是说，在本申请实施例中，对于每个第三方应用而言，都仅开放调用一部分API的权限，这样，即使出现服务访问请求被仿造的情况，也会因为只能调用很少一部分API，而使得用户的大部分信息都是安全的。

代理服务器在完成对服务访问请求的安全性校验后，如果校验通过，则可以重新将服务访问请求发送到第一服务器。

S103：重新接收到所述服务访问请求后，判断所述服务访问请求的发送方是否为代理服务器，如果是，执行步骤S104；

在本申请实施例中，对于第一服务器而言，至少会接收到两种服务访问请求，一种是来自JSSDK的服务访问请求，对于这种访问请求，第一服务器会转发到代理服务器进行安全性校验；另一种就是来自代理服务器的服务访问请求，对于这种情况，第一服务器会看作是通过了安全性校验的服务访问请求，因此，会按照请求的内容做出响应。也就是说，无论是JSSDK还是代理服务器，在向第一服务器发送服务访问请求时，使用的第一服务器的URL都是相同的，只不过当发送到第一服务器后，具体的处理逻辑会有所不同，第一服务器会区别对待。

这里需要说明的是，第一服务器在接收到一个服务访问请求后，为了判断其是否来自真实的代理服务器，可以预先设置一个IP地址白名单，白名单中保存有各个代理服务器的IP地址；在接收到一个服务访问请求后，首先提取出发送方的IP地址，然后判断其是否出现在IP地址白名单中，如果是，则证明是来自一个真实可信的代理服务器，否则，仍然可以将接收到的服务访问请求丢弃。

另外需要说明的是，这种使用代理服务器进行安全性校验的方式，还可以实现各个API调用频率的可控性。也就是说，对于一个API而言，如果在短时间内被调用的次数过多，则可能会影响系统的性能，因此，在本申请实施例中，还可以由代理服务器对各个API的调用频率进行统计(例如，每接收到一次调用某API的请求，就对该API的请求次数加一，然后计算在一定时间段内的频率)，如果在接收到调用某个API的请求时，发现调用该API的频率已经超过了某阈值，则可以将该请求丢弃。

S104：根据所述服务访问请求中指定的回传地址返回响应消息。

第一服务器在接收到代理服务器发送的服务访问请求之后，就可以将其作为安全的服务访问请求处理，当然，对于服务访问请求中携带的服务访问令牌等信息可以在第一服务器中进行校验，之后，就可以做出响应消息。其中，服务访问请求中一般会指定回传地址，因此，第一服务器按照该回传地址返回响应消息即可。之后，JSSDK就可以接收到该响应消息，并将其提供给第三方应用进行后续的显示等处理。

也就是说，对于第一服务器而言，其接收到的服务访问请求有两种来源，一直是源自JSSDK，对于这种服务访问请求，需要首先发送到代理服务器进行安全性校验，另一种就是源自代理服务器，对于这种服务访问请求，第一服务器可以作为安全的请求来看待，直接获取到相应的数据并返回响应消息。

总之，在本申请实施例中，第三方应用是通过浏览器中集成的JSSDK来发送服务访问请求，这样，如果其他的第三方应用要伪造该服务访问请求，就需要获知浏览器中HTTP协议的所有参数，因此，提高了伪造的难度。对于第一服务器而言，在接收到JSSDK发送的服务访问请求后，还需要发送到代理服务器进行安全性校验，因此，第一服务器只有在重新接收到代理服务器发送的服务访问请求时，才会做出响应，因此，保证了安全性。其中，还可以对各个第三方应用可以调用的API进行限制，使得一个第三方应用只能调用有限的几个API，这样，即使出现服务访问请求被伪造的情况，也可以使得伪造方只能获取到API权限组内的部分信息，保证用户的大部分信息都是安全的。

需要说明的是，在现有技术中，为了防止其他第三方应用冒名顶替，一般是将第三方应用的标识信息(在第三方应用注册时，由第一服务器提供)、用户的账户信息(用户在第一服务器中注册的账户信息)等组装在API参数中，之后还要利用该第三方应用的私钥进行数字签名，然后再发送到第一服务器，第一服务器在收到带有数字签名的服务访问请求后，先通过签名信息对第三方应用进行身份验证，然后再利用其中携带的信息进行安全性校验。

但是，上述这种安全性校验方式中至少存在以下问题：由于需要对服务访问请求进行数字签名，因此，这就要求在发送一个服务访问请求后，执行写cookies的操作。如果是在本申请实施例中，由于是由JSSDK发送的服务访问请求，因此就需要由JSSDK执行写cookies的操作。但是，在实际应用中，虽然第一服务器一般是主业务平台(例如某电子商务交易平台等等)的一部分，但是第一服务器的cookies与主业务平台的cookies是相互独立的，因此，如果由JSSDK对主业务平台的cookies执行跨应用的写操作，可能会使得cookies存在不安全性。

为了避免JSSDK对主业务平台的cookies执行写操作，在本申请实施例中，可以实行免签名策略，也就是说，JSSDK在组装好服务访问请求后，可以直接向第一服务器发送服务访问请求。对于第一服务器而言，在接收到服务访问请求后，首先判断请求的来源，也就是判断请求的发送者是否为JSSDK，如果是，则将该服务访问请求发送到一个代理服务器进行安全性校验，如果代理服务器校验通过了，再重新将服务访问请求发送给第一服务器。由于代理服务器能够对服务访问请求的安全性进行校验，而第一服务器只信任代理服务器重新发送的服务访问请求，因此，通过这一系列的措施就可以代替数字签名，保证安全性。

实施例二

以上实施例一从第一服务器的角度对本申请实施例提供的技术方案进行了介绍，在本实施例二中，将从代理服务器的角度对本申请实施例提供的技术方案进行介绍。参见图2，代理服务器角度的对第三方应用进行服务访问控制方法，可以包括以下步骤：

S201：接收第一服务器发送的服务访问请求；所述服务访问请求为第三方应用通过JSSDK发送到第一服务器的服务访问请求；其中，所述JSSDK由第一服务器提供，并由第三方应用中添加的JS组件代码自动将所述JSSDK下载到第三方应用本地；

S202：根据所述服务访问请求中携带的信息对所述服务访问请求进行安全性校验；

其中，服务访问请求可以为调用指定API的请求，具体的，可以在服务访问请求中携带有第三方应用的标识信息，此时，具体在进行安全性校验时，可以根据第三方应用的标识信息以及预置的第三方应用与可调用API之间的对应关系，判断该第三方应用是否具有调用当前指定API的权限，如果有，则此项校验通过，否则，就可以将该请求丢弃。

另外，服务访问请求中还可以携带有第三方应用的refer地址，具体在进行安全性校验时，可以根据各个第三方应用的refer地址与标识信息之间的对应关系，判断当前服务访问请求中携带的第三方应用的refer地址及标识信息之间的对应关系是否正确。

S203：如果校验通过，则将所述服务访问请求重新发送到所述第一服务器，以便所述第一服务器根据所述服务访问请求中指定的回传地址返回响应消息。

如果针对某服务访问请求进行的所有校验都通过，则可以重新发送到第一服务器，第一服务器就可以将代理服务器发送的服务器请求作为安全的请求，并按照指定的回传地址返回响应消息即可。

实施例三

该实施例三从JSSDK的角度对本申请实施例提供的技术方案进行介绍。其中，第三方应用中添加有第一服务器中特定功能对应的JS组件，JS组件的代码自动将第一服务器提供的JSSDK下载到第三方应用本地，参见图3，JSSDK角度的对第三方应用进行服务访问控制方法可以包括以下步骤：

S301：监控用户发出的与所述特定功能相关的操作指令；

S302：接收到所述操作指令后，生成服务访问请求；

具体生成服务访问请求时，可以是确定出需要调用的API，并组装API参数，生成调用API的请求。其中，在组装API参数时，可以将用于进行安全性校验的信息组装在API参数中。例如，可以包括第一服务器颁发给第三方应用的标识信息，以便代理服务器根据第三方应用的标识信息以及预置的第三方应用与可调用API之间的对应关系，判断该第三方应用是否具有调用所述指定API的权限。

还可以将第三方应用的refer地址组装到API参数中，以便代理服务器根据各个第三方应用的refer地址与标识信息之间的一一对应关系，判断服务访问请求中携带的第三方应用的refer地址及标识信息之间的对应关系是否正确。

另外，还可以将第一服务器为第三方应用颁发的服务访问令牌组装到API参数中，这样，第一服务器可以根据服务访问令牌确定第三方应用是否是在经过用户允许的情况下发送的所述服务访问请求。

S303：将所述服务访问请求发送到所述第一服务器，以便所述第一服务器在判断出所述服务访问请求是由JSSDK发出的之后，将所述服务访问请求发送到预置的代理服务器进行安全性校验，并在校验通过后返回响应消息；

服务访问请求组装完成之后，无需进行签名，JSSDK就可以根据第一服务器的URL，向第一服务器发送服务访问请求。通过后续发送到代理服务器校验等一系列流程来代替签名过程确保安全性。

S304：接收所述第一服务器返回的响应消息，并提供给所述第三方应用进行处理。

最后，JSSDK可以接收第一服务器返回的响应消息，并提供给第三方应用进行后续的界面显示等处理。

需要说明的是，以上实施例二及实施例三与实施例一相比，仅仅是描述的角度不同，具体的实现方案是相同的，因此，相关的技术细节可以相互参见，这里不再赘述。

为了更好地理解本申请实施例提供的技术方案，下面通过一个具体的例子，对本申请实施例进行介绍。

假设某第三方网站中添加了某电子商务交易平台中的“购物车”功能对应的JS组件，则用户可以在该第三方网站中选择自己喜欢的商品，并进行“加入购物车”操作。

此时，JSSDK就可以判断该用户是否已经登录到电子商务交易平台，如果尚未登录，则可以跳转至登录界面提示用户进行登录；如果已经登录，则可以从电子商务交易平台的会话参数中读取出一些信息，包括用户的账户信息、第一服务器颁发的服务访问令牌等，将这些信息连同第三方网站的APPkey、refer地址等信息组装到API参数中，并将调用API的请求发送到第一服务器。当然，调用API的请求中还会携带有具体的业务数据，例如用户选择的商品的信息，等等。

第一服务器在收到服务访问请求后，发现是由JSSDK发送来的，则可以将该请求转发给代理服务器。

代理服务器收到服务访问请求后，可以根据其中携带的信息进行安全性校验，包括对第三方网站对应的API权限组、refer地址与APPkey之间的对应关系等信息进行校验，校验通过后，就可以重新将服务访问请求发送到第一服务器。如果校验未通过，则可以返回添加购物车失败的消息。

第一服务器重新接收到服务访问请求后，可以将请求发送方的IP地址与预置的IP地址白名单进行比对，如果出现在IP地址白名单中，则证明是来自代理服务器的服务访问请求，因此，可以作为安全可信的服务访问请求来处理，根据请求中携带的业务信息执行将指定商品加入指定用户购物车的操作，并根据请求中指定的回传地址返回响应消息。

JSSDK将响应消息提供给第三方应用中购物车功能对应的JS组件，进而，可以在第三方网站中显示“添加购物车成功”等信息。

与本申请实施例一提供的对第三方应用进行服务访问控制方法相对应，本申请实施例还提供了一种对第三方应用进行服务访问控制系统，参见图4，该系统可以包括：

第一判断单元401，用于接收到服务访问请求后，判断所述服务访问请求的发送方是否为预置的JS软件开发工具包JSSDK；其中，所述JSSDK由第一服务器提供，并由第三方应用中添加的JS组件代码自动将所述JSSDK下载到第三方应用本地；

发送单元402，用于如果第一判断单元401的判断结果为是，则将所述服务访问请求发送到预置的代理服务器，以便所述代理服务器根据所述服务访问请求中携带的信息对所述服务访问请求进行安全性校验，如果校验通过，则将所述服务访问请求重新发送到第一服务器；

第二判断单元403，用于重新接收到所述服务访问请求后，判断所述服务访问请求的发送方是否为代理服务器；

响应单元404，用于如果第二判断单元403的判断结果为是，则根据所述服务访问请求中指定的回传地址返回响应消息。

其中，所述服务访问请求为调用指定应用程序编程接口API的请求，所述服务访问请求中携带有第三方应用的标识信息；所述标识信息为第一服务器为所述第三方应用颁发的标识信息；相应的，代理服务器可以根据第三方应用的标识信息以及预置的第三方应用与可调用API之间的对应关系，判断该第三方应用是否具有调用所述指定API的权限。

在一种优选的实施方式中，服务访问请求中还可以携带有所述第三方应用的refer地址，所述refer地址与第一服务器颁发的标识信息一一对应；此时，代理服务器还可以根据各个第三方应用的refer地址与标识信息之间的对应关系，判断所述服务访问请求中携带的第三方应用的refer地址及标识信息之间的对应关系是否正确。

具体实现时，第二判断单元403具体可以用于：

判断所述请求的发送方的IP地址是否处于预置的IP地址白名单中；其中，所述预置的IP地址白名单中保存有各个代理服务器的IP地址。

在实际应用中，该系统还可以包括：

授权单元，用于接收第三方应用的授权请求，根据所述第三方应用在注册时申请的权限，生成授权界面，并返回，以便用户根据所述授权界面对所述第三方应用进行授权。

另外，为了便于第一服务器判断一服务访问请求是否为在得到用户允许的情况下发出的，该系统还可以包括：

令牌生成单元，用于在接收到用户的确认授权的消息后，生成服务访问令牌并写到cookies中，以便在所述服务访问请求中携带所述服务访问令牌，所述第一服务器根据所述服务访问令牌确定所述第三方应用是否是在经过用户允许的情况下发送的所述服务访问请求。

其中，在本申请实施例中，所述服务访问请求未经过签名处理，以避免JSSDK对主业务平台的cookies执行写操作。

与本申请实施例二提供的方法相对应，本申请实施例还提供了一种对第三方应用进行服务访问控制的代理服务器，参见图5，该代理服务器可以包括：

请求接收单元501，用于接收第一服务器发送的服务访问请求；所述服务访问请求为第三方应用通过JSSDK发送到第一服务器的服务访问请求；其中，所述JSSDK由第一服务器提供，并由第三方应用中添加的JS组件代码自动将所述JSSDK下载到第三方应用本地；

校验单元502，用于根据所述服务访问请求中携带的信息对所述服务访问请求进行安全性校验；

请求发送单元503，用于如果校验通过，则将所述服务访问请求重新发送到所述第一服务器，以便所述第一服务器根据所述服务访问请求中指定的回传地址返回响应消息。

其中，所述服务访问请求为调用指定应用程序编程接口API的请求，所述服务访问请求中携带有第三方应用的标识信息；所述标识信息为第一服务器为所述第三方应用颁发的标识信息；

所述校验单元502具体可以包括：

第一校验子单元，用于根据所述第三方应用的标识信息以及预置的第三方应用与可调用API之间的对应关系，判断该第三方应用是否具有调用所述指定API的权限。

其中，所述服务访问请求中还可以携带有所述第三方应用的refer地址，所述refer地址与第一服务器颁发的标识信息一一对应；

所述校验单元502还可以包括：

第二校验子单元，用于根据各个第三方应用的refer地址与标识信息之间的对应关系，判断所述服务访问请求中携带的第三方应用的refer地址及标识信息之间的对应关系是否正确。

在实际应用中，代理服务器还可以包括：

调用频率统计单元，用于统计各个API被调用的频率；

控制单元，用于当收到调用某API的请求时，判断该API被调用的频率是否达到预置的阈值，如果是，则将该请求丢弃。

与本申请实施例三提供的方法相对应，本申请实施例还提供了一种对第三方应用进行服务访问控制装置，其中，所述第三方应用中添加有第一服务器中特定功能对应的JS组件，所述JS组件的代码自动将第一服务器提供的JSSDK下载到第三方应用本地，所述装置可以对应于JSSDK，参见图6，该装置具体可以包括：

监控单元601，用于监控用户发出的与所述特定功能相关的操作指令；

请求生成单元602，用于接收到所述操作指令后，生成服务访问请求；

请求发送单元603，用于将所述服务访问请求发送到所述第一服务器，以便所述第一服务器在判断出所述服务访问请求是由JSSDK发出的之后，将所述服务访问请求发送到预置的代理服务器进行安全性校验，并在校验通过后返回响应消息；

响应接收单元604，用于接收所述第一服务器返回的响应消息，并提供给所述第三方应用进行处理。

其中，所述请求生成单元602具体可以用于：

接收到所述操作指令后，确定需要调用的API，并组装API参数，生成调用API的请求。

其中，API参数中包括第一服务器颁发给第三方应用的标识信息，以便代理服务器根据第三方应用的标识信息以及预置的第三方应用与可调用API之间的对应关系，判断该第三方应用是否具有调用所述指定API的权限。

API参数中还可以包括所述第三方应用的refer地址，以便代理服务器根据各个第三方应用的refer地址与标识信息之间的一一对应关系，判断服务访问请求中携带的第三方应用的refer地址及标识信息之间的对应关系是否正确。

另外，API参数中还可以包括第一服务器为所述第三方应用颁发的服务访问令牌，以便第一服务器根据服务访问令牌确定第三方应用是否是在经过用户允许的情况下发送的所述服务访问请求。

总之，在本申请实施例中，第三方应用是通过浏览器中集成的JSSDK来发送服务访问请求，这样，如果其他的第三方应用要伪造该服务访问请求，就需要获知浏览器中HTTP协议的所有参数，因此，提高了伪造的难度。对于第一服务器而言，在接收到JSSDK发送的服务访问请求后，还需要发送到代理服务器进行安全性校验，因此，第一服务器只有在重新接收到代理服务器发送的服务访问请求时，才会做出响应，因此，保证了安全性。其中，还可以对各个第三方应用可以调用的API进行限制，使得一个第三方应用只能调用有限的几个API，这样，即使出现服务访问请求被伪造的情况，也可以使得伪造方只能获取到API权限组内的部分信息，保证用户的大部分信息都是安全的。

通过以上的实施方式的描述可知，本领域的技术人员可以清楚地了解到本申请可借助软件加必需的通用硬件平台的方式来实现。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在存储介质中，如ROM/RAM、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例或者实施例的某些部分所述的方法。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统或系统实施例而言，由于其基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。以上所描述的系统及系统实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

以上对本申请所提供的对第三方应用进行服务访问控制的方法、装置及系统，进行了详细介绍，本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的一般技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处。综上所述，本说明书内容不应理解为对本申请的限制。

Claims (19)

1.一种对第三方应用进行服务访问控制的方法，其特征在于，所述第三方应用中添加有所述第一服务器中特定功能对应的JS组件，所述方法包括：

接收到服务访问请求后，判断所述服务访问请求的发送方是否为预置的JS软件开发工具包JSSDK；其中，所述JSSDK由第一服务器提供，并由第三方应用中添加的JS组件代码自动将所述JSSDK下载到第三方应用本地；

如果是，则将所述服务访问请求发送到预置的代理服务器，以便所述代理服务器根据所述服务访问请求中携带的信息对所述服务访问请求进行安全性校验，如果校验通过，则将所述服务访问请求重新发送到第一服务器；

重新接收到所述服务访问请求后，判断所述服务访问请求的发送方是否为代理服务器；

如果是，则根据所述服务访问请求中指定的回传地址返回响应消息。

2.根据权利要求1所述的方法，其特征在于，所述服务访问请求为调用指定应用程序编程接口API的请求，所述服务访问请求中携带有第三方应用的标识信息；所述标识信息为第一服务器为所述第三方应用颁发的标识信息；

所述代理服务器根据所述服务访问请求中携带的信息对所述服务访问请求进行安全性校验，包括：

所述代理服务器根据所述第三方应用的标识信息以及预置的第三方应用与可调用API之间的对应关系，判断该第三方应用是否具有调用所述指定API的权限。

3.根据权利要求2所述的方法，其特征在于，所述服务访问请求中还携带有所述第三方应用的refer地址，所述refer地址与第一服务器颁发的标识信息一一对应；

所述代理服务器根据所述服务访问请求中携带的信息对所述服务访问请求进行安全性校验，还包括：

根据各个第三方应用的refer地址与标识信息之间的对应关系，判断所述服务访问请求中携带的第三方应用的refer地址及标识信息之间的对应关系是否正确。

4.根据权利要求1所述的方法，其特征在于，所述判断所述请求的发送方是否为代理服务器包括：

判断所述请求的发送方的IP地址是否处于预置的IP地址白名单中；其中，所述预置的IP地址白名单中保存有各个代理服务器的IP地址。

5.根据权利要求1所述的方法，其特征在于，所述方法之前还包括：

接收第三方应用的授权请求，根据所述第三方应用在注册时申请的权限，生成授权界面，并返回，以便用户根据所述授权界面对所述第三方应用进行授权。

6.根据权利要求5所述的方法，其特征在于，还包括：

在接收到用户的确认授权的消息后，生成服务访问令牌并写到cookies中，以便在所述服务访问请求中携带所述服务访问令牌，所述第一服务器根据所述服务访问令牌确定所述第三方应用是否是在经过用户允许的情况下发送的所述服务访问请求。

7.根据权利要求1至6任一项所述的方法，其特征在于，所述服务访问请求未经过签名处理。

8.一种对第三方应用进行服务访问控制的方法，其特征在于，所述第三方应用中添加有第一服务器中特定功能对应的JS组件，所述方法包括：

接收第一服务器发送的服务访问请求；所述服务访问请求为第三方应用通过JSSDK发送到第一服务器的服务访问请求；其中，所述JSSDK由第一服务器提供，并由第三方应用中添加的JS组件代码自动将所述JSSDK下载到第三方应用本地；

根据所述服务访问请求中携带的信息对所述服务访问请求进行安全性校验；

如果校验通过，则将所述服务访问请求重新发送到所述第一服务器，以便所述第一服务器根据所述服务访问请求中指定的回传地址返回响应消息。

9.根据权利要求8所述的方法，其特征在于，所述服务访问请求为调用指定应用程序编程接口API的请求，所述服务访问请求中携带有第三方应用的标识信息；所述标识信息为第一服务器为所述第三方应用颁发的标识信息；

所述根据所述服务访问请求中携带的信息对所述服务访问请求进行安全性校验，包括：

根据所述第三方应用的标识信息以及预置的第三方应用与可调用API之间的对应关系，判断该第三方应用是否具有调用所述指定API的权限。

10.根据权利要求9所述的方法，其特征在于，所述服务访问请求中还携带有所述第三方应用的refer地址，所述refer地址与第一服务器颁发的标识信息一一对应；

所述根据所述服务访问请求中携带的信息对所述服务访问请求进行安全性校验，还包括：

根据各个第三方应用的refer地址与标识信息之间的对应关系，判断所述服务访问请求中携带的第三方应用的refer地址及标识信息之间的对应关系是否正确。

11.根据权利要求9或10任一项所述的方法，其特征在于，还包括：

统计各个API被调用的频率；

当收到调用某API的请求时，判断该API被调用的频率是否达到预置的阈值，如果是，则将该请求丢弃。

12.一种对第三方应用进行服务访问控制的方法，其特征在于，所述第三方应用中添加有第一服务器中特定功能对应的JS组件，所述JS组件的代码自动将第一服务器提供的JSSDK下载到第三方应用本地，所述方法包括由所述JSSDK执行的以下步骤：

监控用户发出的与所述特定功能相关的操作指令；

接收到所述操作指令后，生成服务访问请求；

将所述服务访问请求发送到所述第一服务器，以便所述第一服务器在判断出所述服务访问请求是由JSSDK发出的之后，将所述服务访问请求发送到预置的代理服务器进行安全性校验，并在校验通过后返回响应消息；

接收所述第一服务器返回的响应消息，并提供给所述第三方应用进行处理。

13.根据权利要求12所述的方法，其特征在于，所述接收到所述操作指令后，生成服务访问请求包括：

接收到所述操作指令后，确定需要调用的API，并组装API参数，生成调用API的请求。

14.根据权利要求13所述的方法，其特征在于，所述API参数中包括第一服务器颁发给第三方应用的标识信息，以便所述代理服务器根据所述第三方应用的标识信息以及预置的第三方应用与可调用API之间的对应关系，判断该第三方应用是否具有调用所述指定API的权限。

15.根据权利要求14所述的方法，其特征在于，所述API参数中还包括所述第三方应用的refer地址，以便所述代理服务器根据各个第三方应用的refer地址与标识信息之间的一一对应关系，判断所述服务访问请求中携带的第三方应用的refer地址及标识信息之间的对应关系是否正确。

16.根据权利要求13所述的方法，其特征在于，所述API参数中包括第一服务器为所述第三方应用颁发的服务访问令牌，以便所述第一服务器根据所述服务访问令牌确定所述第三方应用是否是在经过用户允许的情况下发送的所述服务访问请求。

17.一种对第三方应用进行服务访问控制的系统，其特征在于，所述第三方应用中添加有所述第一服务器中特定功能对应的JS组件，所述系统包括：

第一判断单元，用于接收到服务访问请求后，判断所述服务访问请求的发送方是否为预置的JS软件开发工具包JSSDK；其中，所述JSSDK由第一服务器提供，并由第三方应用中添加的JS组件代码自动将所述JSSDK下载到第三方应用本地；

发送单元，用于如果第一判断单元的判断结果为是，则将所述服务访问请求发送到预置的代理服务器，以便所述代理服务器根据所述服务访问请求中携带的信息对所述服务访问请求进行安全性校验，如果校验通过，则将所述服务访问请求重新发送到第一服务器；

第二判断单元，用于重新接收到所述服务访问请求后，判断所述服务访问请求的发送方是否为代理服务器；

响应单元，用于如果第二判断单元的判断结果为是，则根据所述服务访问请求中指定的回传地址返回响应消息。

18.一种对第三方应用进行服务访问控制的代理服务器，其特征在于，所述第三方应用中添加有第一服务器中特定功能对应的JS组件，所述代理服务器包括：

请求接收单元，用于接收第一服务器发送的服务访问请求；所述服务访问请求为第三方应用通过JSSDK发送到第一服务器的服务访问请求；其中，所述JSSDK由第一服务器提供，并由第三方应用中添加的JS组件代码自动将所述JSSDK下载到第三方应用本地；

校验单元，用于根据所述服务访问请求中携带的信息对所述服务访问请求进行安全性校验；

请求发送单元，用于如果校验通过，则将所述服务访问请求重新发送到所述第一服务器，以便所述第一服务器根据所述服务访问请求中指定的回传地址返回响应消息。

19.一种对第三方应用进行服务访问控制的装置，其特征在于，所述第三方应用中添加有第一服务器中特定功能对应的JS组件，所述JS组件的代码自动将第一服务器提供的JSSDK下载到第三方应用本地，所述装置包括：

监控单元，用于监控用户发出的与所述特定功能相关的操作指令；

请求生成单元，用于接收到所述操作指令后，生成服务访问请求；

请求发送单元，用于将所述服务访问请求发送到所述第一服务器，以便所述第一服务器在判断出所述服务访问请求是由JSSDK发出的之后，将所述服务访问请求发送到预置的代理服务器进行安全性校验，并在校验通过后返回响应消息；

响应接收单元，用于接收所述第一服务器返回的响应消息，并提供给所述第三方应用进行处理。