Cookie 是由客户端（通常是浏览器）保存的小型文本信息，其内容是一系列的键值对，是由 HTTP 服务器设置并保存在浏览器上的信息。
在post请求的瞬间，cookie会被浏览器自动添加到请求头中。
Session则是由服务器保存。
但是HTTP 协议是无状态的，也就是说当下一次用户发送请求的时候，请求中没有任何信息能表明用户身份！也就是说不知道请求是谁发出来了，这样也就不能认证了。
所以想到Cookie 来管理 Session，即生成一个SessionID， 放入 HTTP 响应中还给客户端，并保存在客户端，当客户端发送下一次请求的时候，就把这个 Sessionid 一起发送回来，这样就能知道请求是谁发出来的了
但是有几个问题：
1. 内存开销大
我们知道 Session 是存在服务器上的，实际上为了加快认证的速度，我们一般都会放在内存中，这样当用户基数大的时候，内存的开销就会很大。当然也可以将 Session 存入到 Session 表或者是缓存（redis等）中，但是依旧会有这样的问题。
2. 安全性（CSRF，Cross-site request forgery的缩写，跨站请求伪造）
因为是基于 Cookie 进行用户识别，如果 Cookie 被截获，用户就会很容易收到跨站请求伪造的攻击。
假如用户正在登陆银行网页，同时登陆了攻击者的网页，并且银行网页未对csrf攻击进行防护。攻击者就可以在网页放一个表单，该表单提交src为http://www.bank.com/api/transfer，body为count=1000&to=Tom。倘若是session+cookie，用户打开网页的时候就已经转给Tom1000元了.因为form 发起的 POST 请求并不受到浏览器同源策略的限制，因此可以任意地使用其他域的 Cookie 向其他域发送 POST 请求，形成 CSRF 攻击。
3. 分布式
因为 Session 信息是被单个服务器所保存的，所以在分布式系统中就不能适用了，多服务器不共享session。比如 Session 一开始是保存在 A 服务器上，但是下一次请求的时候，这个请求被服务器负载均衡转发到了 B 服务器，而 B 服务器则没有这个 Session 信息，所以就不能用过认证了。
这时候就考虑使用token。
token是开发者为了防范csrf而特别设计的令牌，浏览器不会自动添加token到headers里，攻击者也无法访问用户的token，所以提交的表单无法通过服务器过滤，也就无法形成攻击。
token 也称作令牌，由uid+time+sign[+固定参数]
组成
- uid: 用户唯一身份标识
- time: 当前时间的时间戳
- sign: 签名, 使用 hash/encrypt 压缩成定长的十六进制字符串，以防止第三方恶意拼接
- 固定参数(可选): 将一些常用的固定参数加入到 token 中是为了避免重复查库
存放
token在客户端一般存放于
1. localStorage
LocalStorage可以被 javascript 访问，所以容易受到XSS攻击。尤其是项目中用到很多第三方的Javascript类库。
2. cookie
优点：
可以指定 httponly，来防止被Javascript读取，也可以指定secure，来保证token只在HTTPS下传输。
缺点：
不符合Restful 最佳实践。
容易遭受CSRF攻击 （可以在服务器端检查 Refer 和 Origin）
需要cookie.setDomain("localhost")，如果不设置setDomain的信息的话，就会导致能成功登录，但 Cookies中没有任何的信息记录 ，也就是说不会将cookie保存在本地，虽然有set-cookie
相比较而言，Web Storage比Cookie更容易受到攻击。
3. sessionStorage中。
针对一个session的用户存储，也可以被javascript访问，但当用户关闭浏览器时，也会随之消失
JWT(Json Web Token)是一个跨域认证的方案。
