基于session的验证方式和Token验证方式的区别，以及JWT的具体实现流程

1、传统的cookie认证过程

长期以来，基于Session的认证（Session based authentication）一直处于主流地位。由于http协议是无状态的，借助cookie，客户端登陆成功后，服务端就能识别其后续请求，而不需要每次都登陆。它是有状态的（statefull），也就是服务端和客户端都需要保存生成的session，也就是说在服务端需要在数据库中追踪session是否alive，客户端要把session写入cookie中。基本过程如下：

• 客户端登陆，一般输入用户名和密码
• 服务端如果验证通过，就会生成session，并把它存入数据库中
• 客户端在浏览器上会产生cookie，并把session_id写入
• 客户端后续有新的请求，都会在请求后携带sessIon_id，发给服务端
• 如果客户端登陆出去（log out），该生成的session就会在服务端都被销毁,session_id在客户端也会被清除

基于Token 认证和session 认证的比较
基于Session的认证方式

那么这样做有什么问题呢？

1. 服务端需要保存每个用户的session，这对于很多访问用户的情景来说，服务端的负担很重，需要大量的的资源来存储session
2. 另一方面不能很好解决跨域资源共享问题Cross-Origin Resource Sharing (CORS)
3. cookie存储在客户端或者浏览器引入了很多不安全因素，招致了很多专门针对cookie的攻击如上面这个攻击，在Java Guide中有详细的举例描述：JWT 身份认证优缺点分析以及常见问题解决方案
4. 这个链接中也谈了很多Session的相关缺点：如何理解HTTP的“无连接”和“无状态”

2、Token的认证方式

为了解决以上的问题，我们引入了Token的技术来解决登录验证与用户的状态记录等信息：
15分钟详解 Python 安全认证的那些事儿