接口签名-CSDN博客

转自https://www.cnblogs.com/Aluosen/p/11391725.html

一、不进行验证的方式

api查询接口：

app调用：http://api.test.com/getproducts?参数1=value1…

如上，这种方式简单粗暴，通过调用getproducts方法即可获取产品列表信息了，但是这样的方式会存在很严重的安全性问题，没有进行任何的验证，大家都可以通过这个方法获取到产品列表，导致产品信息泄露。
那么，如何验证调用者身份呢？如何防止参数被篡改呢？

二、MD5参数签名的方式

我们对api查询产品接口进行优化：

1.给app分配对应的key、secret
2.Sign签名，调用API 时需要对请求参数进行签名验证，签名方式如下：

a. 按照请求参数名称将所有请求参数按照字母先后顺序排序得到：keyvaluekeyvalue…keyvalue
字符串如：将arong=1,mrong=2,crong=3 排序为：arong=1, crong=3,mrong=2
然后将参数名和参数值进行拼接得到参数字符串：arong1crong3mrong2。

b. 将secret加在参数字符串的头部后进行MD5加密 ,加密后的字符串需大写。即得到签名Sign

新api接口代码:

app调用：http://api.test.com/getproducts?key=app_key&sign=BCC7C71CF93F9CDBDB88671B701D8A35&参数1=value1&参数2=value2…

注：secret 仅作加密使用, 为了保证数据安全请不要在请求参数中使用。

如上，优化后的请求多了key和sign参数，这样请求的时候就需要合法的key和正确签名sign才可以获取产品数据。这样就解决了身份验证和防止参数篡改问题，如果请求参数被人拿走，没事，他们永远也拿不到secret,因为secret是不传递的。再也无法伪造合法的请求。

但是…这样就够了吗？细心的同学可能会发现，如果我获取了你完整的链接，一直使用你的key和sign和一样的参数不就可以正常获取数据了…-_-!是的，仅仅是如上的优化是不够的

请求的唯一性：

为了防止别人重复使用请求参数问题，我们需要保证请求的唯一性，就是对应请求只能使用一次，这样就算别人拿走了请求的完整链接也是无效的。
唯一性的实现：在请求参数中，我们加入时间戳
：timestamp（yyyyMMddHHmmss），同样，时间戳作为请求参数之一，也加入sign算法中进行加密。

新的api接口：

app调用：
http://api.test.com/getproducts?key=app_key&sign=BCC7C71CF93F9CDBDB88671B701D8A35&timestamp=201603261407&参数1=value1&参数2=value2…

如上，我们通过timestamp时间戳用来验证请求是否过期。这样就算被人拿走完整的请求链接也是无效的。

Sign签名安全性分析：

通过上面的案例，我们可以看出，安全的关键在于参与签名的secret，整个过程中secret是不参与通信的，所以只要保证secret不泄露，请求就不会被伪造。

签名设计

对于敏感的api接口，需使用https协议 https是在http超文本传输协议加入SSL层，它在网络间通信是加密的，所以需要加密证书。
https协议需要ca证书，一般需要交费。

签名的设计

原理：用户登录后向服务器提供用户认证信息（如账户和密码），服务器认证完后给客户端返回一个Token令牌，用户再次获取信息时，带上此令牌，如果令牌正取，则返回数据。对于获取Token信息后，访问用户相关接口，客户端请求的url需要带上如下参数：

时间戳：timestamp

Token令牌：token

然后将所有用户请求的参数按照字母排序（包括timestamp，token），然后更具MD5加密（可以加点盐），全部大写，生成sign签名，这就是所说的url签名算法。然后登陆后每次调用用户信息时，带上sign，timestamp，token参数。

例如：原请求https://www.andy.cn/api/user/update/info.shtml?city=北京（post和get都一样，对所有参数排序加密）

加上时间戳和token

https://www.andy.cn/api/user/update/info.shtml?city=北京&timestamp=12445323134&token=wefkfjdskfjewfjkjfdfnc

然后更具url参数生成sign

最终的请求如

https://www.andy.cn/api/user/update/info.shtml?city=北京&timestamp=12445323134&token=wefkfjdskfjewfjkjfdfnc&sign=FDK2434JKJFD334FDF2

其最终的原理是减小明文的暴露次数；保证数据安全的访问。

具体实现如下：

1.api请求客户端想服务器端一次发送用用户认证信息（用户名和密码），服务器端请求到改请求后，验证用户信息是否正确。
如果正确：则返回一个唯一不重复的字符串（一般为UUID），然后在Redis（任意缓存服务器）中维护Token----Uid的用户信息关系，以便其他api对token的校验。
如果错误：则返回错误码。

2.服务器设计一个url请求拦截规则
（1）判断是否包含timestamp，token，sign参数，如果不含有返回错误码。
（2）判断服务器接到请求的时间和参数中的时间戳是否相差很长一段时间（时间自定义如半个小时），如果超过则说明该url已经过期（如果url被盗，他改变了时间戳，但是会导致sign签名不相等）。
（3）判断token是否有效，根据请求过来的token，查询redis缓存中的uid，如果获取不到这说明该token已过期。
（4）根据用户请求的url参数，服务器端按照同样的规则生成sign签名，对比签名看是否相等，相等则放行。（自然url签名也无法100%保证其安全，也可以通过公钥AES对数据和url加密，但这样如果无法确保公钥丢失，所以签名只是很大程度上保证安全）。
（5）此url拦截只需对获取身份认证的url放行（如登陆url），剩余所有的url都需拦截。

3.Token和Uid关系维护
对于用户登录我们需要创建token–uid的关系，用户退出时需要需删除token–uid的关系

总结