作为一个后端菜鸟水平的FE，鉴权问题一直都似懂非懂，也不是完全不懂，就是只懂前端部分的逻辑，对于后端的配合处理一直都是一个模糊的了解，最近请教肃哥大概搞懂了一个整体的流程，从后端处理方式的角度简单说一下session和token两种。
session方式
简介
用户发来需要鉴权的请求，后端验证通过后，后端创建一个对象，用这个对象对查询到的用户信息进行存储，在响应用户请求时，通过cookie将后端保存信息的这个对象的索引—sessionId传给用户。
例子
用户再次请求一些需要权限的接口时携带cookie，后端根据cookie的内容拿到sessionId后去尝试寻找并访问存储用户信息的对象，不光通过session对象里存放的具体内容可以进行一些权限的判断，本身这个对象的有无也是一个用户信息的反应，就拿用户登陆这个场景来说，如果根据sessionId找到了对应的对象，那么后端就判断这个用户是已经登陆的，否则就是未登陆。
总结
简单总结一下，session模式就是服务端开辟空间进行用户权限信息的存储，然后借助cookie传递sessionId来解决http的状态问题，让用户与服务端自己的session对象相绑定。
相对的优缺点也比较明显了，采用session模式进行鉴权的话优点就是通过session对象相当于对用户一些请求的结果进行缓存，比如查询了一次数据库将结果存储，下次再请求直接使用即可；缺点就是需要占用服务端资源。并且服务端是一般是单体的，具体来说就是服务端的session对象存储于一个服务器上，不利于大规模项目分担服务器压力以及实现单点登录等需求。（我们为了存储session对象再单独开服务器就走远了...）
token方式
简介
对比session模式来说，说白了就是session模式用户的信息是服务器存储的，现在后端通过鉴权之后直接把用户信息（可以理解为session模式中的session对象）进行压缩加密等操作后，生成一个token字符串，这个字符串传给用户，也就是把数据的存储从服务端转移到客户端，用户再次请求时携带这个token字符串，从而后端就知道此用户已经通过了鉴权，进而获取一些私有信息。
疑问
-
通过
session模式可以实现对一些重复的、浪费性能的操作进行缓存，如存储数据查询的结果，那在token鉴权模式中也把包括缓存的所有用户信息都放入token字符串中吗？答：no，比如对于一个用户来说，我们只在
token中存放一些关键的用户信息，比如唯一标识用户名等。 -
那既然
token只存储了少量的一些信息，那它岂不是不具有session那种信息存储的策略？答：不是的，键值对数据库radis就是专门进行用户信息存储的。
我不了解radis，但是对其
分布式、缓存等标签还是有所耳闻的，听到这里我突然就悟了！
总结
相较于session，token的优点：
- 无需服务端存储用户信息，减少服务端压力
- 既然脱离了对服务端存储的数据的依赖，那么自然就有利于做单点登录等一些用户信息的共享。（毕竟信息是完全由用户发送来的），当然这里需要借助radis等分布式数据库。
token传输的形式灵活，不依赖于cookie（我们完全可以当作一个响应体里的字符串传递给客户端），自然解决了cookie的一些痛点，比如cookie无法跨域，以及安全性低等
最后
上面是目前我的一些理解，很多东西也是我作为一个前端外行人的臆测，缺乏实战经验，如果有啥错误非常欢迎大佬指正
