基于第三方的用户与服务方之间的请求加密方法及系统与流程

本发明涉及计算机网络安全验证接入技术，具体涉及基于第三方的用户与服务方之间的请求加密方法及系统。

背景技术：

现有第三方接入服务提供方服务方法大致可以划分为两类：(1)接口接入方法。服务提供方提供接口，第三方通过后台请求服务方接口提交请求和获取返回数据；(2)sdk接入方法。第三方引入服务提供方的sdk加入自有app，请求通过sdk提供的方法去调用服务方接口提交请求和获取返回数据。

接口接入方法由于是由第三方的后台服务发起请求，而不是前台前端代码直接请求，没有在前端暴露服务提供方接口，后端接入有后端约定的加密认证流程，所以对于服务提供方的接口安全是有保证的，即使出现异常情况，服务提供方也可以及时限流或掐断对某个第三方的服务，不至于造成大的损失，是目前比较常用的一种接入方法。但这种接入方法有一个缺陷，因为只提供的接口，只要对于认证通过的第三方发起的请求，无条件返回相应结果，但对第三方并没有约束，第三方可以留存数据建立自己的第二套本地库，也可以对数据进行修饰和修改再返回给前端用户，而服务提供方对这类行为无法控制和识别，有可能给服务提供方带来一定的声誉风险，特别是在金融行业，这类风险在同业竞争和金融合规等方面尤为突出。

例如，某app打着某某银行的名号，提供在线开该行二类户的服务，确实是和某某银行的合作，某某银行为其提供二类户开户接口，但该三方app在请求接口前留存用户注册二类户所提供的敏感信息，如姓名、身份证、手机号、甚至身份证正反面影像资料、手持身份证影像资料等，这些重要信息被三方留存但某某银行是没办法判断的，因为是第三方送过来的信息，至于来之前做了什么某某银行根本无法控制，用户也以为自己的信息给的是某某银行，殊不知自己的这些重要信息也都留给了第三方，后续会带来的风险很难预估，资料如果被第三方泄漏或者利用来做一些违规的事，某某银行就会出现声誉风险。

sdk接入方法分两种，一种是不包含前端页面的sdk，一种是包含前端页面的sdk。

不包含前端页面sdk的接入方法原理是服务提供方提供一个原生sdk加入第三方app，第三方开发前端调用该sdk中的方法进行加密认证流程，通过该sdk提供的通过认证后的接口请求方法请求服务提供方的接口去获取数据，这种形式只是把认证放在了原生端而不是后端，安全上来说必须要反编译破解第三方的app和服务提供方的原生sdk，才能找出服务提供方的接口和加解密认证方法，现在的app一般都是加固加壳了的，所以安全方面还是有较难攻破，但比起接口接入法安全性稍差一些，因为破解反编译一个app的难度比起攻破一个后端服务器的难度来说还是要小一些，该方法也和接口接入法一样存在第三方留存数据和修改数据的风险。

包含前端页面sdk的接入方法原理是服务提供方提供的sdk不但提供了认证和请求方法，还把前端页面一并提供在了sdk中，第三方只需要调起该sdk的一个开始方法，后续的页面和该页面的数据交互全是服务提供方自己的，和第三方完全没有任何关系，最后服务提供方的服务流程完成之后只返回给第三方一个结果而已，这种方式我个人觉得才可以算得上是一种独立的服务提供，这就规避了接口接入法和不包含前端页面sdk的接入方法中三方留存数据和修改数据的风险，因为第三方根本不知道你是怎么交互的，整个过程对于第三方来说是个黑盒，除非第三方去破解反编译服务提供方提供的sdk。该方法第三方接入的时候开发量非常的小，接入起来会比较快，这应该是第三方喜闻乐见的，当然，和不包含前端页面sdk的接入方法一样，如果有人破解反编译第三方的app进而破解服务提供方的sdk，也能找出服务提供方的接口和加解密认证方法。

但目前市面上sdk的接入方式并没有接口接入的方式量大，究其原因，有三点。

第一，很多第三方不大能够接受的是加入sdk会增大自己的app的大小这件事，因为app太大，会直接导致用户不能够及时下载app(苹果appstore超过150m不能流量下载，很多主流的安卓应用市场也有类似设置)，接一家服务加一个sdk，现在的无论哪个app肯定不止接一家服务提供方，如果每家都是sdk接入的方式，这个app的大小肯定不会小，除了平台限制，app太大用户也不愿意花流量和存储空间去下载，这会直接影响到该app的安装率和使用率，影响到它的传播和营销。

第二，发版问题，第三方加入sdk之后，app要更新之后，新的功能才能够开启，要去走一次发版流程，去苹果商店和安卓应用市场去重新上传包，要用户去更新他手机上安装的该app，整个周期很长不可控，流程较繁琐，传播转化率较低，对于用户来说体验也比较差。

第三，很多服务提供方也不愿意用sdk接入法的原因除了第三方不大愿意接受外，还有也是因为开发和维护成本，ios一个版本，android一个版本，维护和开发两个版本的成本也相对较大。

所以，虽然包含前端页面sdk的接入方法看上去很好，但更多服务提供方还是愿意选择相信合作的第三方，也不愿去使用该方法，毕竟服务提供方卖的就是自己的服务，第三方就是他们的客户，一切还是以客户利益为出发点，在安全的前提下，让客户更方便的接入自己的服务。第三方使用接口接入法虽然会有不小的开发量，但能得来数据的留存，自己能掌握数据，一般第三方也是能接受的。

技术实现要素：

本发明解决了现有技术存在的服务提供方服务接入到第三方会有数据泄漏、数据使用不可控、增大第三方app大小、接入周期长流程复杂、开发成本较高的问题，提供基于第三方的用户与服务方之间的请求加密方法及系统，其应用时通过用户请求时的公钥私钥加解密方法，提升加密的安全性。

本发明通过下述技术方案实现：

基于第三方的用户与服务方之间的请求加密方法，包括第三方后端、服务提供方h5端、服务提供方网关服务端，各端交互包括以下步骤：

a、第三方的客户端的用户点击某入口请求进入服务提供方提供的服务应用，并将消息通知到第三方后端；

b、第三方后端通过服务提供方网关服务端，向服务提供方发起生成接入密钥at的请求，服务提供方生成接入密钥at并通过服务提供方网关服务端回传到第三方后端；

c、第三方后端收到加密后的at后，解密at，逆向at得到ak，ak为服务提供方网关服务端的非对称加密的公钥，带着参数at、ak在第三方webview中打开服务提供方h5端的url地址，服务提供方h5端将at、ak暂时存放在第三方app内嵌浏览器的sessionstorage中。

进一步的，基于第三方的用户与服务方之间的请求加密方法，所述步骤b中第三方后端通过服务提供方网关服务端，向服务提供方发起生成接入密钥at的请求，所述请求的传递参数包括第三方在服务提供方的注册账户siteid、服务提供方h5端的账户appid、第三方的客户的三方账户userid。

进一步的，基于第三方的用户与服务方之间的请求加密方法，所述步骤b中服务提供方生成接入密钥at并通过服务提供方网关服务端回传到第三方后端的具体过程为：服务提供方鉴权端解密验签并校验第三方在服务提供方的注册账户siteid和服务提供方h5端的账户appid，然后返回加密后的接入密钥at。

进一步的，基于第三方的用户与服务方之间的请求加密方法，所述接入密钥at可逆。

进一步的，基于第三方的用户与服务方之间的请求加密方法，所述步骤b中的接入密钥at包括服务提供方网关服务端的非对称加密的公钥ak，服务提供方鉴权端存下该非对称加密的私钥sk。

基于第三方的用户与服务方之间的请求加密系统，包括第三方后端、服务提供方h5端、服务提供方网关服务端，其中：

第三方后端，用于接收第三方的客户端的用户点击某入口请求进入服务提供方提供的服务应用的消息，并通过服务提供方网关服务端，向服务提供方发起生成接入密钥at的请求，还用于收到加密后的at后，解密at，逆向at得到ak，并通过参数at、ak在第三方webview中打开服务提供方h5端的url地址；

服务提供方h5端，用于服务提供方生成接入密钥at并通过服务提供方网关服务端回传到第三方后端，还用于将at、ak暂时存放在第三方app内嵌浏览器的sessionstorage中。

进一步的，基于第三方的用户与服务方之间的请求加密系统，所述ak为服务提供方网关服务端的非对称加密的公钥。

本发明与现有技术相比，具有如下的优点和有益效果：

1、本发明通过用户请求时的公钥私钥加解密方法，提升加密的安全性。

2、本发明应用时整个过程全由服务提供方开发，数据不会泄漏到任何一个第三方，不存在增大第三方app大小和需要重新发版的问题，只需第三方后台配置一个跳转即可，且整个开发成本可控。

附图说明

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

图1为本发明结构示意图；

图2为本发明中对外输出时序图。

具体实施方式

为使本发明的目的、技术方案和优点更加清楚明白，下面结合实施例和附图，对本发明作进一步的详细说明，本发明的示意性实施方式及其说明仅用于解释本发明，并不作为对本发明的限定。

实施例1

如图1至图2所示，服务提供方h5应用形式的第三方安全接入方法，包括第三方后端、服务提供方h5端、服务提供方网关服务端、服务提供方鉴权端和服务提供方后端，各端交互包括以下步骤：

a、第三方的客户端的用户点击某入口请求进入服务提供方提供的服务应用，并将消息通知到第三方后端；

b、第三方后端通过服务提供方网关服务端，向服务提供方发起生成接入密钥at的请求(accesstoken，简称at)，服务提供方生成接入密钥at并通过服务提供方网关服务端回传到第三方后端；

c、第三方后端收到加密后的at后，解密at，逆向at得到ak(appkey，简称ak)，ak为服务提供方网关服务端的非对称加密的公钥，带着参数at、ak在第三方webview中打开服务提供方h5端的url地址，服务提供方h5端将at、ak暂时存放在第三方app内嵌浏览器的sessionstorage中。

所述步骤b中第三方后端通过服务提供方网关服务端，向服务提供方发起生成接入密钥at的请求，所述请求的传递参数包括第三方在服务提供方的注册账户siteid、服务提供方h5端的账户appid、第三方的客户的三方账户userid。

所述步骤b中服务提供方生成接入密钥at并通过服务提供方网关服务端回传到第三方后端的具体过程为：服务提供方鉴权端解密验签并校验第三方在服务提供方的注册账户siteid和服务提供方h5端的账户appid，然后返回加密后的接入密钥at。所述接入密钥at可逆。

所述步骤b中的接入密钥at包括服务提供方网关服务端的非对称加密的公钥ak，服务提供方鉴权端存下该非对称加密的私钥sk(secretkey，简称sk)。

本发明克服了前述的现有技术中存在服务提供方服务接入到第三方会有数据泄漏、数据使用不可控、增大第三方app大小、接入周期长流程复杂、开发成本较高的缺陷，整个h5应用全由服务提供方开发，第三方只需要后台发起请求拿一个密钥传给服务提供方的h5首页，其余的流程都与第三方无关，数据不会泄漏到任何一个第三方，由于是h5应用，不存在增大第三方app大小和需要重新发版的问题，只需第三方后台配置一个跳转即可，且整个开发成本可控，开发h5一套即可接入ios、android、h5三端，每次修改全部接入方一起同步，无感知更新，上线速度快，复用性强，也能做到流控，可以根据密钥归类请求方进行限流和拒绝。整个方法的破解成本非常高。

本发明中at一次性消费，生成vt后即失效；服务提供方h5端缓存在三方app的webview的sessionstorage中的所有数据全部用at为key加密后再缓存。

实施例2

基于第三方的用户与服务方之间的请求加密系统，包括第三方后端、服务提供方h5端、服务提供方网关服务端，其中：

第三方后端，用于接收第三方的客户端的用户点击某入口请求进入服务提供方提供的服务应用的消息，并通过服务提供方网关服务端，向服务提供方发起生成接入密钥at的请求，还用于收到加密后的at后，解密at，逆向at得到ak，并通过参数at、ak在第三方webview中打开服务提供方h5端的url地址；

服务提供方h5端，用于服务提供方生成接入密钥at并通过服务提供方网关服务端回传到第三方后端，还用于将at、ak暂时存放在第三方app内嵌浏览器的sessionstorage中。

所述ak为服务提供方网关服务端的非对称加密的公钥。

以上所述的具体实施方式，对本发明的目的、技术方案和有益效果进行了进一步详细说明，所应理解的是，以上所述仅为本发明的具体实施方式而已，并不用于限定本发明的保护范围，凡在本发明的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。