HTTP是一种无状态的协议，为了分辨链接是谁发起的，支持客户端与服务器之间的交互，需要通过不同的技术为交互存储状态，给用户颁发许可证，将动作连贯起来，许可证的实现技术有Cookie、Session和Token。
Cookies
是服务器生成，保存在本地机器上存储的小段文本，随每一个请求发送至同一服务器，是在客户端保持状态的方案。
主要内容包括：cookie名，cookie值，过期时间，路径和域。
设置过期时间，则cookie会被保存在硬盘上，过期后自动清除；若没有设置过期时间，则cookie被保存在浏览器内存中，浏览器关掉就消失了。路径和域就是对应的域名，a网站的cookie自然不能给b用。
Session
存在服务器端的一种用来存放对象的HashTable结构，是一种保存上下文信息的机制，它通过sessionId来区分不同的客户端，而sessionId是保存在客户端的，做为客户端与服务器的验证标识，它是一个24位的随机字符串，用户每次提交页面时，浏览器都会把这个sessionId包含在HTTP头中提交给WEB服务器。
session生成过程
当服务器接收到客户端的请求，要求产生一个session时，服务器会先检查下，客户端的cookies中是否有sessionId，并且判断它是否过期。若存在sessionId且还没有过期，则会根据该sessionId值将服务器中的session检索出来；否则，将产生一个新的session，当创建一个新session后，服务器也会产生一个sessionId号，回写客户端的cookies当中。
一般这个值会有个时间限制，超时后毁掉这个值，默认30分钟。
cookie和session的区别
- 存储数据方面：session存储对象，cookie存储String
- 存放地址：cookie保存在客户端，session保存在服务端
- Session过多时会消耗服务器资源，大型网站会有专门Session服务器；每个域的Cookie数量和数据大小都是有限的，单个cookie保存的数据不能超过4K，很多浏览器都限制一个站点最多保存20个cookie。
- session不区分路径，同一个用户在同一个网站期间，所有的session在任何一个地方都可以访问到。而cookies是区分路径的，如果设置了路径参数，那么同一个网站不同路径下的cookies是互相访问不到的。
单点登录中，cookie 被禁用了怎么办？
单点登录的原理是后端生成一个 session ID，设置到 cookie，后面所有请求浏览器都会带上cookie，然后服务端从cookie获取 session ID，查询到用户信息。所以，保持登录的关键不是cookie，而是通过cookie 保存和传输的 session ID，本质是能获取用户信息的数据。除了cookie，还常用 HTTP 请求头来传输。但这个请求头浏览器不会像cookie一样自动携带，需手工处理
session多服务器间共享，以及实现负载均衡时存在的问题
为了保障高可用，一般服务器至少需要两台机器，通过负载均衡的方式来决定到底请求该打到哪台机器上。这就涉及到了session多服务器间共享问题：
session 复制
A 生成 session 后复制到 B, C，这样每台机器都有一份 session，但是同一样的一份 session 保存了多份，数据冗余
session 粘连
让每个客户端请求只打到固定的一台机器上，支持按 ip 或 cookie 粘连等等，这样的话每个 client 请求到达 Nginx 后，只要它的 ip 不变，根据 ip hash 算出来的值会打到固定的机器上，也就不存在 session 找不到的问题了，当然不难看出这种方式缺点也是很明显，对应的机器挂了怎么办？
session 共享
将 session 保存在 redis，memcached 等中间件中，请求到来时，各个机器去这些中间件取一下 session 即可。就是每个请求都要去 redis 取一下 session，多了一次内部连接，消耗了一点性能。
Token
token意思是令牌，是用户身份的验证方式。最简单的token组成：uid(用户唯一的身份标识)、time（当前时间的时间戳）、sign（签名）等元素加密产生的加密字符串。
Token认证的五点认识
- Token就是一些信息的集合；
- 在Token中包含足够多的信息，以便在后续请求中减少查询数据库的几率；
- 服务端需要对cookie和HTTP Authrorization Header进行Token信息的检查；
- 基于上一点，你可以用一套token认证代码来面对浏览器类客户端和非浏览器类客户端；
- 因为token是被签名的，所以我们可以认为一个可以解码认证通过的token是由我们系统发放的，其中带的信息是合法有效的；
为什么有了session还需要token？
随着Web，应用程序，已经移动端的兴起，基于服务器验证方式逐渐暴露出了问题。尤其是在可扩展性方面。
1、服务器压力增大
通常session是存储在内存中的，每个用户通过认证之后都会将session数据保存在服务器的内存中，而当用户量增大时，服务器的压力增大。
2、CSRF跨站伪造请求攻击
session是基于cookie进行用户识别的, cookie如果被截获，用户就会很容易受到跨站请求伪造的攻击。
3、扩展性不强
在服务端的内存中使用Seesion存储登录信息，伴随而来的是可扩展性问题。如果将来搭建了多个服务器，虽然每个服务器都执行的是同样的业务逻辑，但是session数据是保存在内存中的（不是共享的），用户第一次访问的是服务器1，当用户再次请求时可能访问的是另外一台服务器2，服务器2获取不到session信息，就判定用户没有登陆过。
在这些问题中，可扩展行是最突出的。因此我们有必要去寻求一种更有行之有效的方法。
Token的身份验证的过程
- 用户通过用户名和密码发送请求。
- 程序验证。
- 程序返回一个签名的token给客户端。
- 客户端储存token，并且每次用于每次发送请求。
- 服务端验证token并返回数据。
Token和session的区别
- session是一种认证方式；token是认证授权的方式，认证是针对用户，授权是针对App，其目的是让 某App有权利访问 某用户 的信息。
- 多数场景上使用 session 会更合理；如果在单点登录（一次性命令认证上），或者第三方共享、允许第三方调用 API 接口，使用 token 会更合适，最好在不同的业务场景中合理选型，才能达到事半功倍的效果。
- Session是存放在服务器端的，可以保存在：内存、数据库、NoSQL中。它采用空间换时间的策略来进行身份识别，若Session没有持久化落地存储，一旦服务器重启，Session数据会丢失。Token是放在客户端存储的，采用了时间换空间策略，它也是无状态的，所以在分布式环境中应用广泛。
