我们是这样设计对外安全接口的

背景

在日常工作中难免会调用第三方系统的接口，一个项目会有多个服务组合而成，负责各自核心的服务，在接触的项目中他主要以门户服务、核心服务组合而成。

大部分门户服务会调用核心服务。当然如果有支付业务，会调用其他部门的支付服务，这样的话设计一个统一安全的对外接口就极为重要。

并不是谁都可以来调用的服务的。需要使用接口的服务需要在后台开通appId和相应密钥。

数据在传输的过程中是很容易被抓包的，常见的做法对请求的内容做数据加密。

数据在传输的过程中很容易被篡改，常见的做法是利用数据加签发送者产生一段无法伪造的数字串，来保证数据在传输的过程中不被篡改。

本来就是真实的用户，并且开通了appid，但是出现频繁调用接口的情况，这种情况需要给相关appid限流处理，常用的限流算法有令牌桶。

我们项目中AppId机制是由应用+终端组合的，也就是说一个应用会有多个终端。在运营平台里开通相应应用AppId，应用底下添加相应的终端TermId，之后就可以请求我们的服务要带上AppId、TermId。当然添加应用的时候会产生有对应的密钥（随机32位），这个密钥是用来加密+签名的。

运营平台提供运营商、商户入驻。每个商户入驻都会得到一个终端Id。如果是提供给公司其他部门，运营平台会用admin账户提前分配一套一个AppId和TermId给其他部门使用。

相信大家在开发过程中如果有接触调用第三方API的时候会映入对方的SDK，之后调用对方API如下：

我们的做法也是类似。我们有一个专门的项目SDK。该SDK包含加密解密加签验签功能，别人的服务要调用我们的服务，先引入我们的SDK。SDK由TransRequest 、Handler、TransResponse三大部分组成

TransRequest是请求模板，对应的app_id、app_key、term_id、加密类型、签名类型、请求内容、请求方法等。Handler主要是对信息签名加密、请求具体的服务、信息解密验签。请求具体的服务本质还是用HttpClient调用。TransResponse是统一返回模板

加密方式有对称加密和非对称加密

对称加密：对称加密在加密和解密的过程中使用的密钥是相同的，常见的对称加密算法有DES，AES；有点计算速度快。缺点：发送方接收方商定好密钥。

非对称加密：服务端会生成一对密钥，私钥存放在服务端，公钥可以发给任何人使用。优点：安全。缺点：速度慢。

我们采取的是使用密钥进行AES加密。

数据签名我们是将TransRequest里按照key value拼接生成用sm3算法签名的。

1. 调用者引入我们的SDK，有一套请求模板，我们通过运营平台管理AppId、TermId、AppKey，把这些下发给调用者。

2. SDK对信息加密签名去请求我们的服务，服务端在进行解密验证签名进行相应的处理业务返回，返回时候再对信息进行签名加密。

3. SDK对返回的信息在进行解密验签返回给调用者是明文，整个过程中加密验证签名对用户是无感的。