简单理解Token机制

互联网发展到现在已经到了一个非常成熟的时代，所以不再是一个你写一个静态网站就可以进行疯狂盈利的时代了。现在对产品有着很多的要求，健壮性，安全性这些都是必不可少的。前两篇也说过了现在公司一般用户登录成功会给前端返回token，前端访问接口请求数据需要携带token进行身份验证。我们一直说token，那究竟什么是token？token其实就是一个令牌，是服务端生成的一串字符串，解析可以得到用户信息。

因为HTTP是一种无状态协议，所以是没办法记住用户的登录状态的。所以客户端每次请求都需要验证身份，最早的解决方案是：当用户请求登录成功，在服务端生成一条记录，然后把记录id发送给客户端，客户端收到以后把这个id存储在cookie里，下次该用户再次向服务端发送请求的时候，可以带上这个cookie，这样服务端会验证一下cookie里的信息，看能不能在服务端这里找到对应的记录，如果可以，说明用户已经通过了身份验证，就把用户请求的数据返回给客户端。其实这种方案就是利用session,id值其实就是sessionid。那我们既然可以使用session进行身份验证，我们为什么还要选择使用token呢？

1.session是需要空间进行存储的，如果是多服务器session需要同步信息，但是token在服务器是可以不需要存储用户信息的。

2.token可以使用浏览器的localStorge等，APP也可以使用自带数据库存储字符串。且不会出现cookies出现跨域问题。

3.token可以用JWT来携带部分不太敏感的信息比如用户ID等，服务器只要解密token即可使用部分信息。

使用token验证机制讲完了，那我们需要知道我们使用token验证的整个流程：

1.当用户登录成功之后, 服务器端就会通过指定算法生成一个 token，过期时间48h，可以将token 存储在redis，再将这个token值返回给客户端；

2.客户端拿到 token 值之后,进行保存；

3.当客户端调用接口请求数据时,就会携带 token 值发送给服务器；

4.服务器接收到客户端的请求之后,会取出token值与保存在redis中的token值做对比。

5.如果token对比成功，说明用户处于登录状态，否则表示登录状态失效，需要用户重新登陆。用户每次重新登陆会刷新token的过期时间。

接下来我们用代码来走一趟整个流程：

首先我们实现登录逻辑，这套没什么好讲的，可以去看看一篇文章：你不知道的前后端分离之交互(2)

用户首次登录去数据库匹配账号密码，匹配成功会返回用户唯一标识uid,account这些基本数据。接下来我们需要去使用指定算法生成一个token

我们通过用户app_sid以及account生成一个简单的token：TKN:3:Q:d:8zTEiTJEJ7dee:AOK_H5，然后去redis查询以这个简单token为键值的token是否存在。

如果用户token已存在redis中，则删除这个token。然后生成新的token。

将新token存储到redis中，一样采用键名为简单token，键值为最终生成的token。过期时间设置成48h。

到这里我们生成token的操作就全部完善了。基本流程就是用户登录成功会以app_sid和account先生成一个简单token，去redis查询该token是否存在。存在则删除token，然后使用特定算法将简单token转化成最终的token存储到redis。然后给前端返回token进行存储。

可以看到我们成功将token返回给前端了。现在我们还需要一个验证token的接口。因为我们直接将token存储在redis中，所以接收到前端传的token，我们可以直接去redis中查询token是否存在，如果token存在，则代表用户处于登录状态，给前端返回数据。否则登陆失败，提示请先登录。

前端每次请求通用数据接口的时候，先验证token的有效性。这样整套下来我们就可以实现基于token的权限验证。但是这套逻辑是有缺点的，因为我们使用token理论上服务端可以不进行存储，直接指定加解密算法，我这里由于生成token使用的随机算法，无法反向解密，所以只能存储在redis中进行处理。其实我觉得更好的方案是直接设计加解密算法，服务端使用加密算法生成token返回给前端，前端每次请求通用数据接口携带token，服务端直接接收前端的token进行反向解密，如果解密成功则可以得到用户的uid等基本信息，解密失败则提示前端请先登录。这部分在这里我就不多说了，具体可以看看上一篇文章讲到的AES加解密。