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