session简介
做过Web开发的程序员应该对Session都比较熟悉，Session是一块保存在服务器端的内存空间，一般用于保存用户的会话信息。
用户通过用户名和密码登陆成功之后，服务器端程序会在服务器端开辟一块Session内存空间并将用户的信息存入这块空间，同时服务器会
在cookie中写入一个Session_id的值，这个值用于标识这个内存空间。
下次用户再来访问的话会带着这个cookie中的session_id，服务器拿着这个id去寻找对应的session，如果session中已经有了这个用户的
登陆信息，则说明用户已经登陆过了。
使用Session保持会话信息使用起来非常简单，技术也非常成熟。但是也存在下面的几个问题：
服务器压力大：通常Session是存储在内存中的，每个用户通过认证之后都会将session数据保存在服务器的内存中，而当用户量增大时，服务器的压力增大。
Session共享：现在很多应用都是分布式集群，需要我们做额外的操作进行Session共享；
CSRF跨站伪造请求攻击：Session机制是基于浏览器端的cookie的，cookie如果被截获，用户就会很容易受到跨站请求伪造的攻击。
基于token的认证#
基于token的认证机制将认证信息返回给客户端并存储。下次访问其他页面，需要从客户端传递认证信息回服务端。简单的流程如下：
客户端使用用户名跟密码请求登录；
服务端收到请求，去验证用户名与密码；
验证成功后，服务端会签发一个 Token，再把这个 Token 发送给客户端；
客户端收到 Token 以后可以把它存储起来，比如放在 Cookie 里或者 Local Storage 里；
客户端每次向服务端请求资源的时候需要带着服务端签发的 Token；
服务端收到请求，然后去验证客户端请求里面带着的 Token，如果验证成功，就向客户端返回请求的数据；
基于token的验证机制，有以下的优点：
支持跨域访问，将token置于请求头中，而cookie是不支持跨域访问的；
无状态化，服务端无需存储token，只需要验证token信息是否正确即可，而session需要在服务端存储，一般是通过cookie中的sessionID在服务端查找对应的session；
无需绑定到一个特殊的身份验证方案（传统的用户名密码登陆），只需要生成的token是符合我们预期设定的即可；
更适用于移动端（Android，iOS，小程序等等），像这种原生平台不支持cookie，比如说微信小程序，每一次请求都是一次会话，当然我们可以每次去手动为他添加cookie，详情请查看博主另一篇博客；
避免CSRF跨站伪造攻击，还是因为不依赖cookie；
缺点的话一个就是相比较于传统的session登陆机制实现起来略微复杂一点，另外一个比较大的缺点是由于服务器不保存 token，因此无法在使用过程中废止某个 token，或者更改 token 的权限。也就是说，一旦 token 签发了，在到期之前就会始终有效，除非服务器部署额外的逻辑。
退出登陆的话，只要前端清除token信息即可。