关于Token安全策略的初步思考

前言

若是谈起Token安全策略，无论大家对其研究深不深，但绝对多多少少都对其进行一定的接触。
他也是我们在开发之中，最令开发人员厌烦的一个步骤（ 大家应该都有或多或少莫名其妙被 token 策略 阻挡在程序之外，并且对其根本的原因摸不着头脑 ）。 但是，最要命的便是，即时我们如此讨厌token,但是，没有他们却又不行。

Token 的作用

token的作用是什么呢？大家其实都很清楚，为了安全。那么到底什么保证什么样的安全呢？？

现在就比如，我们面前有一个接口，基本逻辑就是查询一个用户的相关信息等等。

url:xxxx/find/user
#基本逻辑，查询用户id为2的相关信息
{
	user_id:2
}

只需要这样，我们从业务逻辑之上，就已经拿到了我们所需要所有信息
但是呢，从正常的角度来说，我们不希望这个给id为2的用户的接口，被除该用户外的其他人访问下，能得到对应的值。因此，在一般的逻辑下，我们希望这个用户能添加一个只有自己才知道的元素（比如说密码），这样其他人就不能进行正常的访问

url:xxxx/find/user
#基本逻辑，查询用户id为2的相关信息
{
	user_id:2,
	password:"123456"
}

这样的话，因为密码只有自己知道，所以其他的用户无法正常进行访问。

但是，后面出现了黑客技术，黑客技术能通过一些特殊的技术（不过一般情况，更多的都是内鬼干的），来拦截http请求，并且得知http请求之中的属性值。恰恰，密码又是十分重要的一个属性值，因此我们，必须要进行对密码的加密，这样即使对方能拦截的到请求，但是，却无法得到有意义的信息。这样，token就诞生了。

url:xxxx/find/user
#基本逻辑，查询用户id为2的相关信息
{
	user_id:2,
	token:"dqwdwqdhohauqo"
}

后来，由于token的独立性，一个user_id只会对应一个token，完美主义者们就希望连user_id也不要暴露给对方用户了。

url:xxxx/find/user
#基本逻辑，查询用户id为2的相关信息
{
	token:"dqwdwqdhohauqo"
}

大家对token的认知，因此到这里也开始戛然而止了。但是，问题依然存在，token的初始化目的，只是为了url被拦截的时候，并不会暴露用户的信息。但是黑客们还是可以利用token，来直接进行请求来伪造目标客户的操作。当然，伪造也是需要一定的条件的，但是，这样的条件在相对的情况之下，是完全可以接受的。

思考解决方案

说是解决方案，其实也不是十分的玄幻。我并不是十分喜欢算法的人，所以，我也说不出那些连符号都无法看懂的人。
而且，个人认为，其实根本就不存在绝对安全的方法，安全策略的目的，其实就是让破解的成本增加，黑客们只要知道了基本的原理，或者是能拿得到请求进行伪造。就自然而然能想得到方案来进行破解。（所以，大部分这样的问题，都是内部人员的操作）

与时间条件进行纠缠

1. 条件之上，外加上发送时间与失效时间。失效时间尽量较短，个人认为普通的连接不需要超过十秒
2. 将 token 与 发送时间 ， 过期时间 ，秘钥等等一系列信息重新编码生成新的 token。
3. 后端根据同样的算法，来对信息重新加密，然后把生成的密文与新的‘token’进行对比

url:xxxx/find/user
#基本逻辑，查询用户id为2的相关信息
{
   user_id:2,
   start_time:"xxxxx",
   end_time:"xxxxxx",
   sign:"xxxxxxxxxxxxxxxxx" //新生成的token
}

上面的操作的主要目的：增加token的不确定性，这样即时对方能拦截的到URL,但是却得不到关键信息。就算能重新伪造，但是请求也会快速的失效

当然，上面的设计自然而然并不是完全的标准答案，大家只要能让token随机数增强，就可以进行自由的设定。