笔者以前在做广告系统时发现对接的大少数平台的广告系统都是以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"，最后经过加密算法对拼接的字符串加密就能生成最终的签名。
每个接口都要写一遍签名逻辑不费事吗?
不须要。关于授权方，可经过过滤器或许阻拦器成功签名验证逻辑;关于调用方，经常使用不同框架有不同的方法，但咱们总能想到方法只写一次性签名逻辑不是吗?