企业服务内部接口校验方案

场景

咱们作的产品是To B的，那么咱们自身会有一个云运营平台的系统，这个系统包含咱们全部项目的运营管理数据，在一个月前，咱们还不须要想对外提供服务，可是有一天咱们数据被其余团队所须要了，需求就来了？

需求：咱们要作一个接口认证，用来识别对方服务是啥？

小A同窗领到任务开始是很开心的，立马作了好几个方案给领导审阅。

方案大爆炸

1、直接在header头部或者url地址给一个私有token

约定client的token值为12345678，
那么请求的url地址为：
/remote/getApk?token=12345678

服务端接收到token后，进行匹配判断是否合法token，不合法就退出，合法就是后续操做。
复制代码

简单，很是简单，调用方直接拿到这个token写入header头部或者url，在服务端拿到后进行简单匹配逻辑来肯定调用方是否正确，就完事了，从明面上来说，这个已经知足需求了，可是新的问题来了？

若是我这个token被第三方截取怎么办？

答： 上https，安全

没毛病的，https是安全，由于在http协议的基础上增长一层SSL/TLS(能够理解为http是裸奔，SSL/TLS 是盔甲，遮盖住重要的信息)，可是在咱们这小门小户要实现所有https不太可能，并且https对于客户端的调用也不是那么方便，那么接下来又怎么办呢？

2、加上ip白名单

其实这里根本不须要加参数，服务端默认就能够获取客户端的ip，这就保证一点，若是咱们token被劫持，就算给你发，也没啥用，没错，在不少内部系统中，咱们设计接口校验就算基于它来作的，由于这个更简单，基本两边接口彻底不须要改东西，写完就能够调，就一个ip白名单配置。

那有没有可能这个包被别人劫持，而后进行ip代理，而后来请求呢？

3、token做为加密盐值，cs做为双方加密认证

前提：

1. 须要ip白名单
2. 须要为这个调用方产出一个token(salt)

这里约定就不是token了，使用一个双方约定的密码盐值salt=123456

GET /remote/getApk?md5=043c00e6c7ff021e8cc4d394d3264cb5&sign=md5(043c00e6c7ff021e8cc4d394d3264cb5+123456)

sign 计算方式：将咱们请求的参数按key的正序排序，把里面的值进行字符串链接而且加上salt，再进行一个md5计算，固然能够选择其余hash算法，例如sha1等

复制代码

这种方案在服务端，咱们同样实现这一算法，而且最终校验这个sign值是否同样，固然这个方案并不能解决咱们刚刚一开始说不安全的问题，由于网络截取是个很日常的事情。

那么有没有办法截取了用不了呢？

答案是确定的，那咱们在url地址添加一个请求的时间戳

GET /remote/getApk?t=1561969549&md5=043c00e6c7ff021e8cc4d394d3264cb5&sign=md5(043c00e6c7ff021e8cc4d394d3264cb5+1561969549+123456)

sign 计算方式：将咱们请求的参数按key的正序排序，把里面的值进行字符串链接而且加上salt，再进行一个md5计算，固然能够选择其余hash算法，例如sha1等

复制代码

这里是加一个时间戳做为sign的参数，那么能够理解为这个sign值是在特定时间内有效，在服务端接收到请求后，能够优先判断时间戳与服务端时间偏移，若是在一分钟以内，那么这个都是能够请求，超过说明这个已通过期了

若是咱们对于接口请求严格限制，那么咱们每次请求过的sign值不能重复，这个涉及到另外话题：

能够简单说一下：咱们能够将每一个时间戳创建一个桶，每一个桶里面装的就是这些sign值，这些时间戳的过时时间与服务端判断的过时时间一致（若是t字段过时，那么就走不到这一步），就是这么简单哈。

看到这里有同窗确定会问：时间戳不同咋办，客户端与服务端时间戳确定会不同的？

能想到这的同窗，真的很是聪明，由于是真的有这个问题出现，固然不是这个场景，只要是时间区间判断的问题，都要考虑双方时间戳的问题

1. 公司统一使用时间服务器，调用双方同步这个服务器时间。
2. 客户端不定时同步服务端的时间

总结

其实这个方案设计是仅限于咱们企业内部服务相互调用的一个接口设计，刚开始接到任务都会想jwt oauth2.0等方案，后来仔细想一想，咱们压根不须要那么复杂的逻辑来作，由于咱们面向的是服务，不是面向独立个体的用户，固然用jwt和oauth2.0也能够，就是咱们接口的请求调用就变成登陆、校验、鉴权 等方式了。

谢谢各位同窗查阅