服务提供方H5应用形式的第三方安全接入方法与流程

本发明涉及计算机网络安全验证接入技术，具体涉及服务提供方h5应用形式的第三方安全接入方法及系统。

背景技术：

现有第三方接入服务提供方服务方法大致可以划分为两类：(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应用形式的第三方安全接入方法及系统，其应用时整个h5应用全由服务提供方开发，数据不会泄漏到任何一个第三方，不存在增大第三方app大小和需要重新发版的问题，只需第三方后台配置一个跳转即可，且整个开发成本可控，修改全部接入方一起同步，无感知更新，上线速度快，复用性强，也能做到流控，可以根据密钥归类请求方进行限流和拒绝，先有接入密钥，后有访问密钥，加入随机数、哈希、aes加密算法、公钥私钥加解密等混合增加复杂度，整个方法的破解成本非常高。

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

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

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

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

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

d、服务提供方h5端通过服务提供方网关服务端向服务提供方发起生成访问密钥vt的请求，请求的参数包括接入密钥at，所述接入密钥at用随机数作为key进行加密；

e、收到所述步骤d中生成访问密钥vt的请求后，服务提供方中的服务提供方鉴权端先对生成访问密钥vt的请求进行解密，解密出at并校验at的真伪性，当at为真时，生成访问密钥vt并通过服务提供方网关服务端返回到服务提供方h5端，并使该at作为接入密钥的功能失效；

f、服务提供方h5端用随机数解密出vt，打开并渲染出h5产品页面，开展进行h5产品的各种对外服务；

g、服务提供方h5端通过服务提供方网关服务端，向服务提供方后端发起业务报文请求，业务报文请求的请求参数先用随机数加密，再用vt加密，再用ak加密；

h、收到服务提供方h5端发起的业务报文请求后，服务提供方鉴权端对业务报文请求进行解密，解密出最初的真正的业务报文参数，用此业务报文参数向服务提供方后端发起业务请求，返回请求回来的数据，该返回报文用vt加密回传给服务提供方h5端；

i、服务提供方h5端收到返回的报文用vt解密报文并渲染返回的数据。

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

安全方面参考了oauth2.0的机制，先有接入密钥，后有访问密钥，加入随机数、哈希、aes加密算法、公钥私钥加解密等混合增加复杂度，每次请求加密加签，解密密钥不走请求，即使抓包也没用，拿不到vt，需破解加固加壳后的三方app，并对三方安卓app的webview进行activity导出，ios平台下你只能反编译整个app，重写所有模块，服务提供方h5端js文件压缩混淆，前后端分离，还有网络层面的https加密和防csrf攻击，整个方法的破解成本非常高。

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

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

进一步的，服务提供方h5应用形式的第三方安全接入方法，所述步骤b中的接入密钥at包括服务提供方网关服务端的非对称加密的公钥ak，服务提供方鉴权端存下该非对称加密的私钥sk。

进一步的，服务提供方h5应用形式的第三方安全接入方法，所述步骤d中服务提供方h5端通过服务提供方网关服务端向服务提供方发起生成访问密钥vt的请求，所述请求的请求参数包括服务提供方网关服务端的非对称加密的公钥ak和接入密钥at。

进一步的，服务提供方h5应用形式的第三方安全接入方法，所述请求参数中的接入密钥at用随机数作为key加密后，所述请求再使用服务提供方网关服务端的非对称加密的公钥ak加密。

进一步的，服务提供方h5应用形式的第三方安全接入方法，所述步骤e中收到生成访问密钥vt的请求后，服务提供方中的服务提供方鉴权端对生成访问密钥vt的请求进行解密的具体过程为：服务提供方鉴权端收到所述步骤d中的请求后，使用服务提供方网关服务端的非对称加密的公钥ak对应的私钥sk解密请求，再用解密出的随机数为key解密出at。

进一步的，服务提供方h5应用形式的第三方安全接入方法，所述步骤e中服务提供方鉴权端将生成的访问密钥vt与之前生成at请求时的第三方在服务提供方的注册账户siteid、服务提供方h5端的账户appid、第三方的客户的三方账户userid进行对应存储。

进一步的，服务提供方h5应用形式的第三方安全接入方法，所述步骤g中的业务报文请求还包括参数ak、第三方在服务提供方的注册账户siteid、服务提供方h5端的账户appid和第三方的客户的三方账户userid。

进一步的，服务提供方h5应用形式的第三方安全接入方法，所述步骤h中收到服务提供方h5端发起的业务报文请求后，服务提供方鉴权端对业务报文请求进行解密的具体过程为：先使用服务提供方网关服务端的非对称加密的公钥ak对应的私钥sk解密请求的业务报文，然后根据第三方在服务提供方的注册账户siteid、服务提供方h5端的账户appid、第三方的客户的三方账户userid路由到对应的vt，用vt解密，再用解密出的随机数解密出最初的真正的业务报文参数。

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

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

2、本发明修改全部接入方一起同步，无感知更新，上线速度快，复用性强，也能做到流控，可以根据密钥归类请求方进行限流和拒绝。

3、本发明先有接入密钥，后有访问密钥，加入随机数、哈希、aes加密算法、公钥私钥加解密等混合增加复杂度，整个方法的破解成本非常高，提高加密的安全性。

附图说明

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

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

图2为本发明中的h5服务对外输出时序图。

具体实施方式

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

实施例

如图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中；

d、服务提供方h5端通过服务提供方网关服务端向服务提供方发起生成访问密钥vt(visittoken，简称vt)的请求，请求的参数包括接入密钥at，所述接入密钥at用随机数作为key进行加密；

e、收到所述步骤d中生成访问密钥vt的请求后，服务提供方中的服务提供方鉴权端先对生成访问密钥vt的请求进行解密，解密出at并校验at的真伪性，当at为真时，生成访问密钥vt并通过服务提供方网关服务端返回到服务提供方h5端，并使该at作为接入密钥的功能失效；

f、服务提供方h5端用随机数解密出vt，打开并渲染出h5产品页面，开展进行h5产品的各种对外服务；

g、服务提供方h5端通过服务提供方网关服务端，向服务提供方后端发起业务报文请求，业务报文请求的请求参数先用随机数加密，再用vt加密，再用ak加密；

h、收到服务提供方h5端发起的业务报文请求后，服务提供方鉴权端对业务报文请求进行解密，解密出最初的真正的业务报文参数，用此业务报文参数向服务提供方后端发起业务请求，返回请求回来的数据，该返回报文用vt加密回传给服务提供方h5端；

i、服务提供方h5端收到返回的报文用vt解密报文并渲染返回的数据。

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

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

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

所述步骤d中服务提供方h5端通过服务提供方网关服务端向服务提供方发起生成访问密钥vt的请求，所述请求的请求参数包括服务提供方网关服务端的非对称加密的公钥ak和接入密钥at。所述请求参数中的接入密钥at用随机数作为key加密后，所述请求再使用服务提供方网关服务端的非对称加密的公钥ak加密。

所述步骤e中收到生成访问密钥vt的请求后，服务提供方中的服务提供方鉴权端对生成访问密钥vt的请求进行解密的具体过程为：服务提供方鉴权端收到所述步骤d中的请求后，使用服务提供方网关服务端的非对称加密的公钥ak对应的私钥sk解密请求，再用解密出的随机数为key解密出at。

所述步骤e中服务提供方鉴权端将生成的访问密钥vt与之前生成at请求时的第三方在服务提供方的注册账户siteid、服务提供方h5端的账户appid、第三方的客户的三方账户userid进行对应存储。

所述步骤g中的业务报文请求还包括参数ak、第三方在服务提供方的注册账户siteid、服务提供方h5端的账户appid和第三方的客户的三方账户userid。

所述步骤h中收到服务提供方h5端发起的业务报文请求后，服务提供方鉴权端对业务报文请求进行解密的具体过程为：先使用服务提供方网关服务端的非对称加密的公钥ak对应的私钥sk解密请求的业务报文，然后根据第三方在服务提供方的注册账户siteid、服务提供方h5端的账户appid、第三方的客户的三方账户userid路由到对应的vt，用vt解密，再用解密出的随机数解密出最初的真正的业务报文参数。

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

安全方面参考了oauth2.0的机制，先有接入密钥，后有访问密钥，加入随机数、哈希、aes加密算法、公钥私钥加解密等混合增加复杂度，每次请求加密加签，解密密钥不走请求，即使抓包也没用，拿不到vt，需破解加固加壳后的三方app，并对三方安卓app的webview进行activity导出，ios平台下你只能反编译整个app，重写所有模块，服务提供方h5端js文件压缩混淆，前后端分离，还有网络层面的https加密和防csrf攻击，整个方法的破解成本非常高。

本发明中at一次性消费，生成vt后即失效；服务提供方h5端缓存在三方app的webview的sessionstorage中的所有数据全部用at为key加密后再缓存。服务提供方服务方式为前后端分离方式部署，隔离前端和后端，前端产品以spa的方式输出，单独服务器使用pm2做服务器内核负载均衡，达到高响应和快速渲染，有条件还可以做部分不常改且公共的静态资源cdn部署，使用户体验更加迅速流畅。

本发明与现有技术相比，应用时整个h5应用全由服务提供方开发，数据不会泄漏到任何一个第三方，不存在增大第三方app大小和需要重新发版的问题，只需第三方后台配置一个跳转即可，且整个开发成本可控。本发明修改全部接入方一起同步，无感知更新，上线速度快，复用性强，也能做到流控，可以根据密钥归类请求方进行限流和拒绝。本发明先有接入密钥，后有访问密钥，加入随机数、哈希、aes加密算法、公钥私钥加解密等混合增加复杂度，整个方法的破解成本非常高，提高加密的安全性。

有些银行理财产品对外输出，必须开该行的二类户，注册流程、开户流程、对外输出的某产品，在该行开放平台上拼装出整个业务流程，对外输出使用该方法，规避了开发成本高，接入方接入复杂，增加接入方应用大小，敏感数据不可控等问题，既保证了对外输出的合规风险，也与产品的快速开放上线的灵活性不冲突，解决了一直以来银行风控合规的偏保守风格和互联网产品快速迭代响应的激进风格的对立。

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