cookie和session都是会话保持技术的解决方案，随着技术的发展，token机制出现在了我们面前，有木有人傻傻分不清，我就是0.0。记录一下，Salute！
首先看看cookie和session的用途
要知道我们访问网站都是通过HTTP协议或HTTPS协议来完成的，HTTP协议它本身是无状态的协议（即：服务器无法分辨哪些请求是来源于同个客户）。而业务层面会涉及到客户端与服务器端的交互（同网站下多个页面间能共享数据），此时服务器端必须要保持会话状态，这样才能进行用户身份的鉴别。
由于HTTP的无状态特性，如果要实话客户端和服务器端的会话保持，那就需要其它机制来实现，于是Cookie和Session应运而生。
上图就展示了cookie的验证方式：
Cookie 验证是服务器在用户登录时生成 用户唯一标识 即 session-id 并以映射表的形式保存在该台服务器的内存上（一般做法，也可以保存在其他地方），接着将该 session-id 通过 set-cookie 头部传给客户端浏览器保存到 cookie，下次 同源请求 浏览器会自动带上 session-id 给服务器，服务器再去查对应的用户 id。
通常情况下，Session和Cookie是搭配在一起使用的。
What is Token
上面说到的Session和Cookie机制来保持会话，会存在一个问题：客户端浏览器只要保存自己的SessionID即可，而服务器却要保存所有用户的Session信息，这对于服务器来说开销较大，而且不利用服务器的扩展（比如服务器集群时，Session如何同步存储就是个问题）！
于是有人思考，如果把Session信息让客户端来保管而且无法伪造不就可以解决这个问题了？进而有了Token机制。
Token俗称为“令牌”，它的构成是：
uid：用户唯一身份标识
timestamp：当前时间戳
sign：签名字符串，防止第三方伪造数据；签名密钥是存储在服务器端的，其它人无法知道
其它附加参数。
Token机制下的认证流程
Token机制其实和Cookie机制极其相似，主要有以下流程：
1、用户登录进行身份认证，认证成功后服务器端生成Token返回给客户端；
2、客户端接收到Token后保存在客户端（可保存在Cookie、LocalStorage、SessionStorage中）；
3、客户端再次请求服务器端时，将Token作为请求头放入Headers中；
4、服务器端接收请求头中的Token，将用户参数按照既定规则再进行一次签名，两次签名若一致则认为成功，反之数据存在篡改请求失败。
生成签名示意图：
验证签名示意图：
总结一下：
Token 验证是服务器在用户登录时使用 密钥 对用户信息进行签名并将 用户信息和签名组合，这就是 Token 本身，此时用户 id 就可以放在用户信息上，理论上可以存放更多信息，只要别把密码放在里面就行，接着服务器不对这个 token 进行记录直接将这个 token 传给 客户端（不一定是浏览器，可能是 app），客户端的脚本会把 token 储存起来（浏览器可以储存到 cookie，也可以储存到 localStorage、SessionStorage），下次客户端向服务器发起请求时主动将 token 放到请求头，服务器接收到这个 token，使用同一个密钥对用户信息部分进行签名，再和 token 中的签名部分做比较，如果相等说明 token 没有被窜改，服务器不需要做其他操作就能拿到用户信息中的用户 id，在大用户数的情况下可以减少服务器压力。
Token与session+cookie的区别
其实上面已经说了很多两者间的不同点，其他的大部分是 token 验证能做而 Cookie 验证不能做的事情，它们就是：
在安全性方面，token 能防止 csrf 攻击。
在扩展性方面，token 可以处理多端的身份验证，不仅仅局限于浏览器，只要客户端能对 token 进行储存就行。
token 在跨域共享资源上表现惊艳，只要不同域的服务器之间约定好签名规则，大家都是一家人！
token 可以携带丰富的用户信息，只要不怕别人知道，你想传什么随你便！
Cookie 大小4KB，Cookie过期时间一般为1个月。
Cookie其实也充当的是令牌作用，但它是“有状态”的；而Token令牌是无状态的，更利于分布式部署。
参考文章：
https://blog.csdn.net/weixin_40022980/article/details/109990868
http://www.360doc.com/content/21/0328/10/74468719_969367467.shtml