一个公司需要拓展业务时，内部的业务系统往往需要跟外部系统交互，比如现在用户希望在支付宝或微信上交电费，话费，转账…那么电力公司、运营商、银行就需要跟支付宝和微信打通内部系统与支付宝微信系统之间的网络，提供相关api接口。

像这种对外的api接口往往对安全性有严格要求，本文整理了一下常用的api鉴权方式以及安全措施(如有不当之处，请路过的大佬指正)。

直接把API暴露到互联网上给外部系统是存在安全风险的，因此我们要先对接口调用方做一个用户鉴权，对API权限划分，如果鉴权通过则允许用户调用API。根据不同的场景，鉴权方案也有很多种。

这种方式是指当请求的资源、API Key 和 API Secret匹配时，用户才可以访问对应的资源，一般还会以时间戳等方式来进行请求的时效控制。

其原理为：

为了避免重放攻击，可以加上时间戳参数，服务端验证时，如果时间超过允许范围则验证失败。

需要注意的是，这种模式并不是RBAC，而是ACL访问权限控制。这种方式实现简单，占用的计算资源和网络资源都较少，安全性也可以。但是一般来说每一个api用户都需要分配一对Key和Secret，因此当Key和Secret比较多的时候，服务器会有一定的存储成本 ，而服务端只能通过API Key来区别调用者，API Secret一旦泄密，将造成很大的安全风险。

这种模式适用于大多是的Web API，除非需要在token中承载更多信息或者用户多到影响服务器部署。

Cookie + Session是最传统的API鉴权方式，比如很多网站的登录模块就是靠这种方式实现会话管理。

在服务端会生成一个session来保存会话状态，各个session是通过唯一的session_id来标识的，一次判断请求是哪个客户端发起，session_id存储在客户端的cookie中。

后续的所有请求都会把cookie传到服务器端，服务器端解析cookie后找到对应的session进行判断。 因此这种鉴权方式具有以下特点：

其优点是：

但也有如下缺点：

总的来说，如果是传统的web网站，且同时认证的人数不是足够大（比如只是内部使用）的都可以用这种方式，很多网站依旧采用该方式。

token令牌的机制是用来代替session的鉴权方式，现在很多api的鉴权都是通过token。

token机制是服务器端生成的一串加密串发放给客户端，客户端请求服务器端所有资源时会带上这个Token，由服务器端来校验这个token的合法性。其具有无状态、适合分布式、扩展性好、性能高和安全性好等优点。 常见的token实现有以下几种：

以上是博主总结的一些API鉴权方式。但是在调用API的过程中还需要保证数据在传输过程中的安全性、判断数据是否到达服务器以及服务器如何识别传到服务器的数据是否正确，如何不被攻击。

数据在传输过程中是很容易被抓包的，如果直接传输，比如通过http协议，那么用户传输的数据可以被任何人获取，所以必须对数据加密。

常见的做法对关键字段加密比如用户密码直接通过md5加密；现在主流的做法是使用https协议，在http和tcp之间添加一层加密层(SSL层)，这一层负责数据的加密和解密。

现在主流的加密方式有对称加密和非对称加密。

以上两种方式各有优缺点，而https的实现方式正好是结合了两种加密方式，整合了双方的优点，在安全和性能方面都比较好。

数据在传输过程中经过加密，理论上就算被抓包，就无法对数据进行篡改；但是我们一般加密的部分其实只是在外网，现在很多服务在内网中都需要经过很多服务跳转，如果被攻入内网，则可以在任意节点篡改数据，所以这里的加数据签名可以防止内网中数据被篡改。

数据签名就是由发送者产生一段无法伪造的一段数字串，来保证数据在传输过程中不被篡改。

md5算法是常用的数据签名算法，其原理是将需要提交的数据通过某种方式组合成一个字符串，然后通过md5算法生成一段加密字符串，这段加密字符串就是数据包的签名。为保证安全性，最后的密钥会在客户端和服务端各备一份。

经过如上的加密，加签处理，就算拿到数据也不能看到真实的数据；但是有些攻击者不关心真实的数据，而是直接拿到抓取的数据包做恶意请求，以达到攻击的目的。

我们可以使用时间戳机制，在每次请求的时候加入当前的时间，服务器端会拿到当前时间和消息中的时间相减，看看是否在一个固定的时间范围内，超过时间差的请求就视为非法请求。

如果有用户出现频繁调用接口的情况；这种情况需要给相关用户做限流处理，常用的限流算法包括：令牌桶限流，漏桶限流，计数器限流。

如果此用户进行过很多非法操作，或者说专门有一个中黑系统，经过分析之后直接将此用户列入黑名单，所有请求直接返回错误码。

我们可以给每个用户设置一个状态比如包括：初始化状态，正常状态，中黑状态，关闭状态等等；或者我们直接通过分布式配置中心，直接保存黑名单列表，每次检查是否在列表中即可。

这应该是每个系统都会有的处理机制，只有在数据是合法的情况下才会进行数据处理；每个系统都有自己的验证规则，当然也可能有一些常规性的规则，比如身份证长度和组成，电话号码长度和组成等等。合法性校验包括：常规性校验以及业务校验。

本文大致列举了几种常见的API鉴权机制和安全措施，当然还有其他方式。但是我们除非为了学习，不然不建议为了用某种鉴权方式和安全措施或者用什么新技术新框架而强行使用，应该根据实际需要在这些机制的原理上做修改和组合，毕竟技术是为业务服务的。

如果觉得本文对你有帮助，可以对博主关注，如果平时不怎么看CSDN的关注人动态，可关注下面公众号，不定期分享一些小demo、小项目以及学习心得。

往期文章：