如何保证API接口安全？
发布网友
发布时间：2022-04-20 07:39
共1个回答
热心网友
时间：2023-04-26 09:49
当你的公司体量上来了时候，这个时候可能有一些公司开始找你进行技术对接了，转变成由你来提供api接口，那这个时候，我们应该如何设计并保证API接口安全呢？
最常用的方案，主要有两种：
其中 token 方案，是一种在web端使用最广的接口鉴权方案，我记得在之前写过一篇《手把手教你，使用JWT实现单点登录》的文章，里面介绍的比较详细，有兴趣的朋友可以看一下，没了解的也没关系，我们在此简单的介绍一下 token 方案。
从上图，我们可以很清晰的看到，token 方案的实现主要有以下几个步骤：
在实际使用过程中，当用户登录成功之后，生成的token存放在redis中时是有时效的，一般设置为2个小时，过了2个小时之后会自动失效，这个时候我们就需要重新登录，然后再次获取有效token。
token方案，是目前业务类型的项目当中使用最广的方案，而且实用性非常高，可以很有效的防止黑客们进行抓包、爬取数据。
但是 token 方案也有一些缺点！最明显的就是与第三方公司进行接口对接的时候，当你的接口请求量非常大，这个时候 token 突然失效了，会有大量的接口请求失败。
这个我深有体会，我记得在很早的时候，跟一家中、大型互联网公司进行联调的时候，他们提供给我的接口对接方案就是token方案，当时我司的流量高峰期时候，请求他们的接口大量报错，原因就是因为token失效了，当token失效时，我们会调用他们刷新token接口，刷新完成之后，在token失效与重新刷新token这个时间间隔期间，就会出现大量的请求失败的日志，因此在实际API对接过程中，我不推荐大家采用 token方案。
接口签名，顾名思义，就是通过一些签名规则对参数进行签名，然后把签名的信息放入请求头部，服务端收到客户端请求之后，同样的只需要按照已定的规则生产对应的签名串与客户端的签名信息进行对比，如果一致，就进入业务处理流程；如果不通过，就提示签名验证失败。
在接口签名方案中，主要有四个核心参数：
其中签名的生成规则，分两个步骤：
参数2加密结果，就是我们要的最终签名串。
接口签名方案，尤其是在接口请求量很大的情况下，依然很稳定。
换句话说，你可以将接口签名看作成对token方案的一种补充。
但是如果想把接口签名方案，推广到前后端对接，答案是：不适合。
因为签名计算非常复杂，其次，就是容易泄漏appsecret！
说了这么多，下面我们就一起来用程序实践一下吧！
就像上文所说，token方案重点在于，当用户登录成功之后，我们只需要生成好对应的token，然后将其返回给前端，在下次请求业务接口的时候，需要把token带上。
具体的实践，也可以分两种：
下面，我们介绍的是第二种实现方式。
首先，编写一个jwt 工具。
接着，我们在登录的时候，生成一个token，然后返回给客户端。
最后，编写一个统一*，用于验证客户端传入的token是否有效。
在生成token的时候，我们可以将一些基本的用户信息，例如用户ID、用户姓名，存入token中，这样当token鉴权通过之后，我们只需要通过解析里面的信息，即可获取对应的用户ID，可以省下去数据库查询一些基本信息的操作。
同时，使用的过程中，尽量不要存放敏感信息，因为很容易被黑客解析！
同样的思路，站在服务端验证的角度，我们可以先编写一个签名*，验证客户端传入的参数是否合法，只要有一项不合法，就提示错误。
具体代码实践如下：
签名工具类 SignUtil ：
签名计算，可以换成 hamc 方式进行计算，思路大致一样。
上面介绍的token和接口签名方案，对外都可以对提供的接口起到保护作用，防止别人篡改请求，或者模拟请求。
但是缺少对数据自身的安全保护，即请求的参数和返回的数据都是有可能被别人拦截获取的，而这些数据又是明文的，所以只要被拦截，就能获得相应的业务数据。
对于这种情况，推荐大家对请求参数和返回参数进行加密处理，例如RSA、AES等加密工具。
同时，在生产环境，采用 https 方式进行传输，可以起到很好的安全保护作用！
