cookie是一种记录服务器和客户端会话状态的机制 cookie存储在客户端（本地的缓存文件夹中）：cookie是服务器发送到用户浏览器并保存在本地的一小块数据，它会在浏览器下次向同一服务器再发起请求时被携带并发送到服务器上。
session也是一种记录服务器和客户端状态的机制 session是基于cookie实现的，session存储在服务端，sessionId存储在客户端的cookie中。 session认证流程： 1、浏览器第一次发送请求时，服务器自动生成了Session(用户会话所需的属性及配置信息)，并且生成了Session ID来唯一标识这个Session，并将其通过响应发送到浏览器。 2、浏览器第二次发送请求会将前一次服务器响应中的Session ID放在请求的Cookie中一并发送到服务器上 3、服务器从请求中提取出Session ID，并和保存的所有Session ID进行对比，找到这个用户所对应的Session，从而知道了用户的登录信息。
1、安全性不同：session比cookie安全，session存储在服务端的，cookie是存储在客户端的 2、存取的类型不同：cookie只支持存字符串数据，想要设置其他类型的数据，需要将其转化成字符串，session可以存任意数据类型。 3、效期不同：Cookie 可设置为长时间保持，比如我们经常使用的默认登录功能，Session 一般失效时间较短，客户端关闭（默认情况下）或者 Session 超时都会失效。 4、存储大小不同：单个 Cookie 保存的数据不能超过 4K，Session 可存储数据远高于 Cookie，但是当访问量过多，会占用过多的服务器资源，因此选用cookie还是session技术，更多取决于你自身系统的需求。
token：token是服务端生成的用于验证用户登录状态的加密数据，和用session验证差不多。只不过token验证服务器端不需要存储用户会话所需的配置等数据。只需要后端将token验证进行验证签名，然后再发给浏览器。所以，使用token进行验证，在一次会话中，token值是不变化的，这个session一样。 1、客户端使用应户名、密码登录 2、服务端收到请求后，去验证用户名和密码 3、验证成功后，服务端会签发一个token并把这个token发送给客户端 4、客户端收到token后，会把它存储起来，比如放在cookie里或localstorage里 5、客户端每次向服务端请求资源的时候需要带着服务端签发的token 6、服务端收到请求，然后验证客户端请求里面带的token，如果验证成功，就向客户端返回请求的数据。
如果没有refresh token，也可以刷新access token，但每次刷新都要用户输入登录用户名和密码，会很麻烦，当token过期后，可在客户端直接用refresh token去更新access token获取新的token
1、session是一种记录服务器和客户端会话状态的机制，使服务端有状态化，可以记录会话信息；而token是令牌，访问资源接口（api）时所需要的资源凭证。token使服务端无状态化，不会存储会话信息。 2、一个系统中拥有session和token并不矛盾，作为身份认证token的安全性比session好，因为每一个请求都有签名还能防止监听以及重放攻击，而session就必须依赖链路来保证通讯安全。如果你需要实现有状态的会话，仍然可以增加session在服务端保存一些状态。
JWT就是token的一种实现形式，通过在客户端存储payload来降低服务端压力。 1、JSON Web Token（简称JWT）是目前最流行的跨域认证解决方案 2、JWT是一种认证授权机制 3、JWT是为了在网络应用环境间传递声明而执行的一种基于JSON开放标准（RFC 7519） 用点号分为三段，分别表示头部Header、负载Payload、签名signature 4、JWT的声明一般被用来在身份提供者和服务提供者间传递被认证的用户身份信息，以便于从资源服务器获取资源。比如用在用户登录上。 5、可以使用HMAC算法或者RSA的公私钥对JWT进行签名。因为数字签名的存在。这些传递信息是可信的。
相同： 1、都是访问资源的令牌 2、都可以记录用户的信息 3、都是使服务端无状态化 4、都是只有验证成功后，客户端才能访问服务端上受保护的资源 区别： 1、token：服务端验证客户端发送过来的token时，还需要查询数据库获取用户信息，然后验证token是否有效 2、JWT：将token和payload加密后存储于客户端，服务端只需要使用密钥解密进行校验（校验） 参考：https://blog.csdn.net/ITBigGod/article/details/106993176?utm_medium=distribute.pc_feed.362360.nonecase&depth_1-utm_source=distribute.pc_feed.362360.nonecase
