如何保证API接口安全？

一、摘要

在实际的业务开发过程中，我们常常会碰到需要与第三方互联网公司进行技术对接，例如支付宝支付对接、微信支付对接、高德地图查询对接等等服务，如果你是一个创业型互联网，大部分可能都是对接别的公司api接口。

当你的公司体量上来了时候，这个时候可能有一些公司开始找你进行技术对接了，转变成由你来提供api接口，那这个时候，我们应该如何设计并保证API接口安全呢?

二、方案介绍

最常用的方案，主要有两种：

• token方案
• 接口签名

1. token方案

其中token方案，是一种在web端使用最广的接口鉴权方案，我记得在之前写过一篇《手把手教你，使用JWT实现单点登录》的文章，里面介绍的比较详细，有兴趣的朋友可以看一下，没了解的也没关系，我们在此简单的介绍一下token方案。

从上图，我们可以很清晰的看到，token 方案的实现主要有以下几个步骤：

• 用户登录成功之后，服务端会给用户生成一个唯一有效的凭证，这个有效值被称为token
• 当用户每次请求其他的业务接口时，需要在请求头部带上token
• 服务端接受到客户端业务接口请求时，会验证token的合法性，如果不合法会提示给客户端;如果合法，才会进入业务处理流程。

在实际使用过程中，当用户登录成功之后，生成的token存放在redis中时是有时效的，一般设置为2个小时，过了2个小时之后会自动失效，这个时候我们就需要重新登录，然后再次获取有效token。

token方案，是目前业务类型的项目当中使用最广的方案，而且实用性非常高，可以很有效的防止黑客们进行抓包、爬取数据。

但是 token 方案也有一些缺点!最明显的就是与第三方公司进行接口对接的时候，当你的接口请求量非常大，这个时候token突然失效了，会有大量的接口请求失败。

这个我深有体会，我记得在很早的时候，跟一家中、大型互联网公司进行联调的时候，他们提供给我的接口对接方案就是token方案，当时我司的流量高峰期时候，请求他们的接口大量报错，原因就是因为token失效了，当token失效时，我们会调用他们刷新token接口，刷新完成之后，在token失效与重新刷新token这个时间间隔期间，就会出现大量的请求失败的日志，因此在实际API对接过程中，我不推荐大家采用token方案。

2. 接口签名

接口签名，顾名思义，就是通过一些签名规则对参数进行签名，然后把签名的信息放入请求头部，服务端收到客户端请求之后，同样的只需要按照已定的规则生产对应的签名串与客户端的签名信息进行对比，如果一致，就进入业务处理流程;如果不通过，就提示签名验证失败。

在接口签名方案中，主要有四个核心参数：

• appid表示应用ID，其中与之匹配的还有appsecret，表示应用密钥，用于数据的签名加密，不同的对接项目分配不同的appid和appsecret，保证数据安全
• timestamp 表示时间戳，当请求的时间戳与服务器中的时间戳，差值在5分钟之内，属于有效请求，不在此范围内，属于无效请求
• nonce 表示临时流水号，用于防止重复提交验证
• signature 表示签名字段，用于判断接口请求是否有效。

其中签名的生成规则，分两个步骤：

第一步：对请求参数进行一次md5加密签名

第二步：对第一步签名结果，再进行一次md5加密签名

参数2加密结果，就是我们要的最终签名串。

接口签名方案，尤其是在接口请求量很大的情况下，依然很稳定。

换句话说，你可以将接口签名看作成对token方案的一种补充。

但是如果想把接口签名方案，推广到前后端对接，答案是：不适合。

因为签名计算非常复杂，其次，就是容易泄漏appsecret!

说了这么多，下面我们就一起来用程序实践一下吧!

二、程序实践

1. token方案

就像上文所说，token方案重点在于，当用户登录成功之后，我们只需要生成好对应的token，然后将其返回给前端，在下次请求业务接口的时候，需要把token带上。

具体的实践，也可以分两种：

• 第一种：采用uuid生成token，然后将token存放在redis中，同时设置有效期2哥小时
• 第二种：采用JWT工具来生成token，这种token是可以跨平台的，天然支持分布式，其实本质也是采用时间戳+密钥，来生成一个token。

下面，我们介绍的是第二种实现方式。

首先，编写一个jwt 工具。

接着，我们在登录的时候，生成一个token，然后返回给客户端。

最后，编写一个统一拦截器，用于验证客户端传入的token是否有效。

在生成token的时候，我们可以将一些基本的用户信息，例如用户ID、用户姓名，存入token中，这样当token鉴权通过之后，我们只需要通过解析里面的信息，即可获取对应的用户ID，可以省下去数据库查询一些基本信息的操作。

同时，使用的过程中，尽量不要存放敏感信息，因为很容易被黑客解析!

2. 接口签名

同样的思路，站在服务端验证的角度，我们可以先编写一个签名拦截器，验证客户端传入的参数是否合法，只要有一项不合法，就提示错误。

具体代码实践如下：

签名工具类SignUtil：

签名计算，可以换成hamc方式进行计算，思路大致一样。

三、小结

上面介绍的token和接口签名方案，对外都可以对提供的接口起到保护作用，防止别人篡改请求，或者模拟请求。

但是缺少对数据自身的安全保护，即请求的参数和返回的数据都是有可能被别人拦截获取的，而这些数据又是明文的，所以只要被拦截，就能获得相应的业务数据。

对于这种情况，推荐大家对请求参数和返回参数进行加密处理，例如RSA、AES等加密工具。

同时，在生产环境，采用https方式进行传输，可以起到很好的安全保护作用!

鸿蒙官方战略合作共建——HarmonyOS技术社区