关于session&cookies和JWT的选择

session与cookies的区别：

额外信息由谁来维护？

利用cookies来实现会话管理时，用户的相关信息或者其他我们想要保持在每个请求中的信息，都是放在cookies中，而cookies是由客户端来保存，每当客户端发出新请求时，就会稍带上cookies，服务端会根据其中的信息进行操作。当利用session来进行会话管理时，客户端实际上只存了一个由服务端发送的session_id，而由这个session_id，可以在服务端还原出所需要的所有状态信息，从这里可以看出这部分信息是由服务端来维护的。

session：

优点：

​ 可以在生成cookies时设置httponly预防xss攻击。

缺点：

​ 1、在分布式系统中可扩展性差。
​ 2、容易遭受csrf跨站攻击。
​ 3、由于用户登录状态记录在服务端，用户数量庞大时服务端的压力比较大。
​ 4、受同源策略约束，在多个域名下，会存在跨域问题。（可以通过搭建反向代理nginx解决）

JWT：

优点：

​ 1、在客户端记录状态，所以易于扩展。
​ 2、因为json的通用性，JWT可以进行跨语言支持，像JAVA,NodeJS,PHP等很多语言都可以使用。
​ 3、便于传输，jwt的构成非常简单，字节占用很小，所以它是非常便于传输的。
​ 4、无跨域问题。

缺点：

​ 1、token令牌可能会被xss攻击截获。
​ 2、JWT并不支持用户主动退出登录，服务端一旦发出令牌，无法主动控制让token过期。所以过期时间不能设置过长。
​ 3、token过期时间如果比较短，用户在操作中会被要求重新登录，所以要隔断时间去请求新的token。

登录信息传递方式以及请求后台接口方式改变

解释：token还是JWT的形式，把token放入headers去请求改为token存入cookies，让后台自行判断是否过期。前端登录成功之后获取到token，把token解析后放入localstorage。

步骤：

1、输入用户名和密码登录

2、登录成功获取到token，包含用户名、角色id、过期时间等

3、把token中的信息解析后放入localstorage存起来

4、写公共方法，有使用到账户信息做判断的页面，用该方法获取到相应的token信息。

5、若访问接口时检测到token已过期，请求报401或403错误，则将localstorage中保存的账户信息清除。

6、当前端检测不到对应字段的localstorage则会提示用户登录失效。

相比JWT的优点：
1、后台可以设置HttpOnly，防止xss攻击，“跨域脚本”，这些脚本代码可以盗取cookie或是Local Storage中的数据。

2、比JWT大小小一点

3、过期时间可控

缺点：

1、无法跨域（需要借助负载均衡器去统一域名方可使用）

拓展：csrf攻击、xss攻击

前解决方案：

身份验证方式：JWT。

Token存储位置：localStorage

1、前端加反向代理，将供应商和商城平台放在统一域名下，共享token。

2、所有需要身份验证通过的请求都要在header中带上token。实现跨域访问后端接口。

发现问题：

1、在分布式系统中可扩展性差。

2、服务器发出token后无法控制token刷新时间。

3、若加入ssr，则服务端渲染时获取不到localStorage中的token，刷新页面后无法对登录状态进行判断。

新解决方案：

身份验证方式：cookie&session

session_id存储位置：客户端cookie中

1、前端加一层反向代理，将三个平台的前端代理到统一域名下，并将后台接口也代理到改域名下。这样做，1）、解决了前后端接口请求跨域问题。2）、解决了前端的身份验证信息共享问题（cookie或localStorage）。

2、登录接口返回payload，内容为用户的信息，存放在localstorage中。

3、可判断ssr登录状态，若cookie不正确则可以跳转到登录页。