前言
🧐读完本篇文章你会懂得session和token这两种认证方式的来龙去脉。
包括session这种认证方式的缺陷、以及token是如何解决该缺陷等等。
会话是什么
从打开浏览器到关闭浏览器期间的全部请求与响应，称为一次会话。
会话是系统为了保持当前用户的登录状态所提供的机制。
会话出现可以解决登录完之后，访问其他资源不用再登录这样的问题。
要实现上述的需求，常见的方式有基于session的认证方式和基于token的认证方式。
这里需要重点理解：会话的产生是系统为了保持当前用户的登录状态这句话
下面来看看基于session的认证方式是如何运作的（下面的内容很重要，务必理解消化）
- 首先，用户在
前端页面输入了用户名和密码进行了登录操作。用户名和密码信息被发送到了服务器的登录接口。 - 在
服务器的登录接口处发生了什么呢？首先当然是完成了登录相关的业务。除此之外，此处会将登录的用户名保存到session,然后再将session保存到session缓存。同时会将sessionid保存到cookie响应给前端，浏览器自动保存。
注意：
session缓存是被保存在服务器的。session缓存中的存储方式是id--session[admin]的键值对形式保存的。
补充：sessionid是哪里来的？答：由服务器生成。
小贴士：一些面试题在问session和cookie的区别的时候，都会说cookie保存在客户端，session保存在服务器，这就是原因。
- 现在前端开始访问访问系统资源，当请求发送到服务器的时候，首先会被后台的过滤器进行拦截。此外，服务器会拿到前端所携带的
cookie,再拿到cookie中的sessionid，然后再利用sessionid去获取session缓存中的session。如果能拿到session,那么就说明这个用户已经登录过了，进行放行。
session这种认证方式的弊端
讲完了session的运作流程，现在来说说它的弊端：只适合于单体应用，不适合用于分布式微服务集群的项目。
一个项目如果是集群的，就相当于后台项目会被部署到多台服务器上，这样就会导致每一个服务器都会有它自己的session缓存。
这就会导致一个问题了，我前脚刚刚登录，登录产生的session缓存被保存在了服务器A上。我后脚访问服务器B上的服务，但是这个服务器上没有保存我的session缓存，这就导致我又要重新登录了。这就是session的弊端。
基于token的认证方式是如何运作的（重要内容！！！）
- 首先，用户在前端发起登录请求，此时在
服务器A中，对应的接口完成了前端的登录请求。除此之外，后端会颁发一个token（令牌）给前端，前端会将这个token保存起来。 - 现在前端开始访问
服务器B中提供的服务，服务器B会首先对前端所携带的token进行解析，只要这个token解析通过，就表示这个用户已经登录了，允许访问相关的资源接口。
注意，认证方式是很灵活的，此处还可以配合redis来进行认证。如下所示（简述）：
- 前端发起登录请求，
服务器A完成登录请求之后，服务器先按照token-用户对象的键值对格式讲信息存储在redis中，再对前端颁发token - 前端向
服务器B发起请求，服务器B先利用前端携带的token去redis中验证是否存在该用户，如果存在，就允许让前端访问资源。
基于session的认证方式的缺陷就这样被token解决了，是不是很简单！！！
