认证机制
验证(Authentication)是为了确定用户是其申明的身份,比如提供账户的密码。不然的话,任何人伪造成其他身份(比如其他用户或者管理员)是非常危险的
主要原理:
- 做一个认证服务，提供一个认证的webapi，用户先访问它获取对应的token
- 用户拿着相应的token以及请求的参数和服务器端提供的签名算法计算出签名后再去访问指定的api
- 服务器端每次接收到请求就获取对应用户的token和请求参数,服务器端再次计算签名和客户端签名做对比,如果验证通过则正常访问相应的api,验证失败则返回具体的失败信息
核心实现：
- 用户请求认证服务GetToken,将TOKEN保存在服务器端缓存中,并返回对应的TOKEN到客户端(该请求不需要进行签名认证）
- 客户端调用服务器端API,需要对请求进行签名认证,签名方式如下
- get请求:按照请求参数名称将所有请求参数按照字母先后顺序排序得到:keyvaluekeyvalue…keyvalue,字符串如:将arong=1,mrong=2,crong=3,排序为:arong=1,crong=3,mrong=2,然后将参数名和参数值进行拼接得到参数字符串：arong1crong3mrong2。post请求:将请求的参数对象序列化为json格式字符串
- 在请求头中添加timespan(时间戳),nonce(随机数),appkey,appsecrect,signature(签名参数)
- 计算本次请求的签名,用timespan+nonc+appkey+appsecrect+token+data(请求参数字符串)得到signStr签名字符串,然后再进行排序和MD5加密得到最终的signature签名字符串,添加到请求头中
- webapi接收到相应的请求,取出请求头中的timespan,nonc,appkey,appsecrect,signature数据,根据timespan判断此次请求是否失效,根据appkey+appsecrect取出相应token判断token是否失效，根据请求类型取出对应的请求参数,然后服务器端按照同样的规则重新计算请求签名,判断和请求头中的signature数据是否相同,如果相同的话则是合法请求,正常返回数据,如果不相同的话,该请求可能被恶意篡改,禁止访问相应的数据,返回相应的错误信息,参与签名的TOKEN,整个过程中TOKEN是不参与通信的,所以只要保证TOKEN不泄露,请求就不会被伪造。然后我们通过timestamp时间戳用来验证请求是否过期,这样就算被人拿走完整的请求链接也是无效的。
- Sign签名的方式能够在一定程度上防止信息被篡改和伪造,保障通信的安全。
版权声明：
本文为智客工坊「楠木大叔」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
