笔者以前在做广告系统时发现对接的大多数平台的广告系统都是以token方式授权接口,而且这个token是一直不变的,由广告主提供,可以说这就是裸奔的接口,只不过这种接口对安全性要求不高,这只能防止恶意调用以及验证渠道的身份。
去年笔者写过一个API统一授权平台,为内部服务开放接口给第三方系统调用提供统一的授权管理,除了方便管理接口授权外,没有其它用途,但却要花成本部署。这应该是我做的一个最无意义的项目了。
今天介绍的API授权机制或许也是使用较为广泛的一种API接口授权机制,记得笔者以前做微信支付功能的时候,微信提供的支付接口也使用这种方式:签名。优势:简单、不影响性能、不需要额外成本。
这种授权方法的实现逻辑是,授权方为每个接入平台设置唯一的身份标识(key)以及设置独立密钥,其实也就相当于账号密码。要求接入方系统在每次发起请求都在请求头携带三个参数,分别是身份标识(key)、发起请求的时间戳、以及签名,授权方系统在接收到请求时校验签名,校验通过才放行请求。
校验签名的过程为,从请求头获取key和时间戳,再根据密钥通过相同算法生成签名(调用方与授权方使用相同签名算法),最后对比请求头获取的签名是否相等,如果是则校验成功,否则校验失败。
基于签名算法的授权方法实现过程如下:
授权方:
1.定义签名算法,提供签名生成算法给接入方,并为接入方生成密钥和身份标识;
2.在项目中拦截需要验证签名的接口,从请求头获取时间戳和身份标识,根据密钥和签名算法生成签名,将生成的签名与从请求头获取到的签名比较,如果相同则继续步骤3,否则拒绝请求;
3.请求时效性校验,用当前系统时间戳与从请求头获取到的时间戳比较,如果请求在有效时间范围内则放行请求,否则拒绝并响应签名过期。
接入方:
1.从授权方获取对接文档,并向授权方要密钥和身份标识;
2.根据文档提供的签名生成算法封装签名方法;
3.在发起请求时,将身份标识、当前时间戳、签名写入请求头。
签名生成算法可自定义,如将身份标识(key)、时间戳(timestamp)和密钥拼接在一起后,再采用一种不可逆算法对字符串进行加密生成签名,如MD5算法。规则越复杂就越不容易被破解。
签名加上时间戳有什么好处?
一是为签名添加时效性。授权方系统可根据请求时间戳与系统当前时间戳比较,限定签名只能在一秒内有效,或者五秒内有效。但要求双方系统时间必须正确。
二是安全性,如果黑客拦截了你们系统的请求,然后修改请求再发起请求,这期间肯定是要时间的吧,所以当系统接收到篡改后的请求时,签名的有效期已经过去了。如果改掉请求头传递的时间戳,那么授权方系统生成的签名就与请求头传递的签名不一样了,请求一样无效。
即便你知道授权方(肉鸡)系统的签名规则,如果你不知道密钥,也无法生成有效的签名。并且由于签名采用非对称加密算法,要想通过爆力破解出密钥几乎是不可能完成的事情。
那为什么用时间戳而不用格式化时间字符串呢?
这可能是考虑时区上的兼容吧,不同机房所在时区不同的话,时间就不同,但时间戳都相同。
为发挥这种授权方式的安全性,首先是生成签名的规则必须够复杂,然后是签名的加密算法要不可逆,千万不要使用Base64这种算法,最后是密钥要足够长足够复杂,以确保即便在知道签名生成规则的情况下,也不可能通过暴力破解出密钥。
签名规则指的是生成加密之前的签名字符串的规则,如规则:key+密钥+时间戳+key+密钥。假设key为“app”,密钥为"123",时间戳为"1111111111111",拼接生成的加密前的签名为"app1231111111111111app123",最后通过加密算法对拼接的字符串加密就能生成最终的签名。
每个接口都要写一遍签名逻辑不麻烦吗?
不需要。对于授权方,可通过过滤器或者拦截器完成签名验证逻辑;对于调用方,使用不同框架有不同的方法,但我们总能想到办法只写一次签名逻辑不是吗?
本网站的文章部分内容可能来源于网络和网友发布,仅供大家学习与参考,如有侵权,请联系站长进行删除处理,不代表本网站立场,转载者并注明出处:https://www.jmbhsh.com/baihuo725/31869.html