如何保证API接口安全？ _API接口

一、摘要在实际的业务开发过程中，我们常常会碰到需要与第三方互联网公司进行技术对接，例如支付宝支付对接、微信支付对接、高德地图查询对接等等服务，如果你是一个创业型互联网，大部分可能都是对接别的公司api接口。
当你的公司体量上来了时候，这个时候可能有一些公司开始找你进行技术对接了，转变成由你来提供api接口，那这个时候，我们应该如何设计并保证API接口安全呢？
二、方案介绍最常用的方案，主要有两种：

token方案
接口签名

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

文章插图

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

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

在实际使用过程中，当用户登录成功之后，生成的token存放在redis中时是有时效的，一般设置为2个小时，过了2个小时之后会自动失效，这个时候我们就需要重新登录，然后再次获取有效token 。
token方案，是目前业务类型的项目当中使用最广的方案，而且实用性非常高，可以很有效的防止黑客们进行抓包、爬取数据。
但是 token 方案也有一些缺点！最明显的就是与第三方公司进行接口对接的时候，当你的接口请求量非常大，这个时候 token 突然失效了，会有大量的接口请求失败。
这个我深有体会，我记得在很早的时候，跟一家中、大型互联网公司进行联调的时候，他们提供给我的接口对接方案就是token方案，当时我司的流量高峰期时候，请求他们的接口大量报错，原因就是因为token失效了，当token失效时，我们会调用他们刷新token接口，刷新完成之后，在token失效与重新刷新token这个时间间隔期间，就会出现大量的请求失败的日志，因此在实际API对接过程中，我不推荐大家采用 token方案。
2.2、接口签名接口签名，顾名思义，就是通过一些签名规则对参数进行签名，然后把签名的信息放入请求头部，服务端收到客户端请求之后，同样的只需要按照已定的规则生产对应的签名串与客户端的签名信息进行对比，如果一致，就进入业务处理流程；如果不通过，就提示签名验证失败。

文章插图

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

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

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

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

//步骤一String 参数1 = 请求方式 + 请求URL相对地址 + 请求Body字符串;String 参数1加密结果= md5(参数1)

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

//步骤二String 参数2 = appsecret + timestamp + nonce + 参数1加密结果;String 参数2加密结果= md5(参数2)参数2加密结果，就是我们要的最终签名串。
接口签名方案，尤其是在接口请求量很大的情况下，依然很稳定。
换句话说，你可以将接口签名看作成对token方案的一种补充。
但是如果想把接口签名方案，推广到前后端对接，答案是：不适合。
因为签名计算非常复杂，其次，就是容易泄漏appsecret！
说了这么多，下面我们就一起来用程序实践一下吧！
二、程序实践2.1、token方案就像上文所说，token方案重点在于，当用户登录成功之后，我们只需要生成好对应的token，然后将其返回给前端，在下次请求业务接口的时候，需要把token带上。