最近在做token认证，研究了好几天，下面把这些天吸收的知识点做个总结
密码登录流程
用户发送密码和用户名
服务端验证信息，获取相应用户信息
密码登录问题
密码相应一个用户，是不会频繁更改的。
但是如果频繁传送密码进行验证，那么很容易将密码泄露
所以最好使用一个可控并且频繁变化的凭证来代替密码
session认证流程
用户发送密码和用户名
服务端通过验证后，创建一个session会话，保存用户相关信息，然后将sessionId传给用户
用户再次访问服务器时带上sessionId，到之前的服务器读取已经存在的session
jwt token登录流程
用户发送密码和用户名
服务端通过验证后，会创建一个token，token可以自包含用户的一些信息，然后返回给用户
用户需要表明身份的时候，就带上token请求服务端
session和jwt token认证的优缺点
session认证
jwt token认证
优点：
没有跨域问题，因为其身份信息是token自带的
不会受到csrf的攻击
信息透明，但是有私钥加密
缺点：
token泄露，他人可以冒充用户
token刷新问题
token比较长，传输比较消耗流量
session跨域问题
Session介绍
由于http是无状态的，所以服务端为了记住一些客户端的信息，需要把信息保存到session中。每个客户最多只有一个session，当再次访问服务端的时候，我们能够通过客户手里的sessionId拿到当前客户的session。session是存储在堆中的，所以是要消耗一定的资源的。
Session共享问题
由于session是存储在内存中的，并且每个用户都只有一个，那么假如一个用户访问了A主机后，此时去访问我们集群中的B主机，那么就拿不到A主机上的session。
cookies攻击
http无状态
http为了方便及高效，所以不持久化之前的响应和请求。及响应完本次请求就忘记，然后继续下次请求。
Cookie介绍
Cookie 会根据从服务器端发送的响应报文内的一个叫做 Set-Cookie 的
首部字段信息，通知客户端保存 Cookie。当下次客户端再往该服务器
发送请求时，客户端会自动在请求报文中加入 Cookie 值后发送出
去。
也就是说cookie是由服务器指定生成的，或则客户端脚本也可以生成。
目的是为了维护http的一些状态。
cookie可以分为内存cookie(会话cookie)和硬盘cookie。
会话cookie当关闭浏览器，cookie信息就会消失。
硬盘cookie是根据各自浏览器把cookie信息存储在某个地方，不同浏览器可能存储路径不同，所以不太会共享。
CSRF攻击
原理分析：
在本浏览器中发送一个服务器请求，假如我们浏览器的cookie有缓存这个服务器的认证信息，那么我们请求会自动筛选相应的cookie信息，加到请求头里，这样请求就能够被认为是合法的。
举例：
假如我们点开了一个广告的游戏网站，这个网站可能会发起一个上传简书文章的请求，那么当前咱们浏览器的cookie里面有简书的登录凭证，所以这个发布是会成功的。
随机串和token的区别
随机串是不带用户信息的，所以只能当作票据来换取用户信息。所以其实还是把用户信息存到服务端。
假如把随机串持久化到数据库，那么过期更新是个比较麻烦的事情。所以随机串还是面临着数据共享的问题。
