Token 登录认证

关键技术点：

token 管理：生成、校验、解析、删除

token：这里使用 userId_UUID 的形式

有效期：使用 Redis key 有效期设置（每次操作完了都会更新延长有效时间）

销毁 token：删除 Redis 中 key 为 userId 的内容

token 存储：客户端（Cookie）、服务端（Redis）

Cookie 的存取操作（js-cookie 插件）

Redis 存取（StringRedisTemplate）

token 登录认证设计流程

1. 用户发出登录请求，带着用户名和密码到服务器经行验证，服务器验证成功就在后台生成一个 token 返回给客户端

2. 客户端将 token 存储到 cookie 中，服务端将 token 存储到 redis 中，可以设置存储 token 的有效期。

3. 后续客户端的每次请求资源都必须携带 token，这里放在请求头中，服务端接收到请求首先校验是否携带 token，以及 token 是否和 redis 中的匹配，若不存在或不匹配直接拦截返回错误信息（如未认证）。

优点

1. 支持跨域访问，将 token 置于请求头中，而 cookie 是不支持跨域访问的；

2. 无状态化，服务端无需存储 token，只需要验证 token 信息是否正确即可，而 session 需要在服务端存储，一般是通过 cookie 中的 sessionID 在服务端查找对应的 session；

3. 无需绑定到一个特殊的身份验证方案（传统的用户名密码登陆），只需要生成的 token 是符合我们预期设定的即可；

4. 更适用于移动端（Android，iOS，小程序等等），像这种原生平台不支持 cookie，比如说微信小程序，每一次请求都是一次会话，当然我们可以每次去手动为他添加 cookie

5. 避免 CSRF 跨站伪造攻击，还是因为不依赖 cookie；

和 cookie 登录认证区别

1. Token 完全由应用管理，所以它可以避开同源策略

2. Token 可以避免 CSRF 攻击

3. Token 可以是无状态的，可以在多个服务间共享