常见的两种登录方式
一、服务器session+客户端sessionId
过程
- 客户端带着用户名和密码去访问 /login 接口， 服务器端收到后校验用户名和密码，校验正确就会在服务器端存储一个sessionId和session的映射关系。
- 服务器端返回response，并且将sessionId以set-cookie的方式种在客户端，这样一来，sessionId就存在了客户端。这里要注意的是，将sessionId存在cookie中并不是一种强制的方案，而是大家一般都这么做。
- 客户端之后再发起非登录请求时，发请求的时候符合domain和path的时候（非跨域请求），会自动带上cookie，省去了手动塞的过程。服务端通过cookie中的sessionId找到对应的session来知道此次请求是谁发出的。
二、tooken（为了防止csrf攻击）
业界通用的加密方式是jwt（json web token），jwt的具体格式如图：
- jwt = base64url(header) + "." + base64url(payload) + "." + signature
- jwt可以放在response中返回，也可以放在cookie中返回，这都是具体的返回方式，并不重要
过程：
- 用户登录，成功后服务器返回Token给客户端。
- 客户端收到数据后保存在客户端
- 客户端再次访问服务器，将token放入headers中
- 服务器端收到请求之后，解析token并且验证相关信息
两种方式区别
sessionId的方式本质是把用户状态信息维护在server端，token的方式就是把用户的状态信息加密成一串token保> 存在客户端。所以跟第一种登录方式最本质的区别是：通过解析token的计算时间换取了session的存储空间
两种方式问题
session方式
- session方式由于在服务器端维护session信息，单机还好说，如果是多机的话，服务器之间需要同步session信息，服务横向扩展不方便。
- session数量随着登录用户的增多而增多，存储会增加很多。
- session+cookie里面存sessionId的方式可能会有csrf攻击的问题，常见的方式是使用csrf_token来解决
jwt方式
- jwt的过期时间需要结合业务做设置，而且jwt一旦派发出去，后端无法强行使其作废
总结
- session存储于服务器，可以理解为一个状态列表，拥有一个唯一识别符号sessionId，通常存放于cookie中。服务器收到cookie后解析出sessionId，再去session列表中查找，才能找到相应session。依赖cookie
- cookie类似一个令牌，装有sessionId，存储在客户端，浏览器通常会自动添加。
- token也类似一个令牌，无状态，用户信息都被加密到token中，服务器收到token后解密就可知道是哪个用户。需要开发者手动添加。
- jwt只是一个跨域认证的方案
