[发明专利]基于第三方的用户与服务方之间的请求加密方法及系统

说明书

本发明公开了基于第三方的用户与服务方之间的请求加密方法及系统，包括第三方后端、服务提供方H5端、服务提供方网关服务端，各端交互包括以下步骤：第三方的客户端的用户点击某入口请求进入服务提供方提供的服务应用；第三方后端通过服务提供方网关服务端，向服务提供方发起生成接入密钥AT的请求，服务提供方生成接入密钥AT并通过服务提供方网关服务端回传到第三方后端。本发明解决了现有技术存在的服务提供方服务接入到第三方会有数据泄漏、数据使用不可控、增大第三方APP大小、接入周期长流程复杂、开发成本较高的问题，提供基于第三方的用户与服务方之间的请求加密方法及系统，其应用时通过用户请求时的公钥私钥加解密方法，提升加密的安全性。

技术领域

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

背景技术

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

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

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

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

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