在早期交互式网页还未盛行的时候，我们进行网页浏览时，只需要拿到网页地址，就可以随意获取网页数据，对于用户而言，对于服务器而言都比较友好，但是也都比较单一。随着一些类似购物车，商城的网页出现之后，人们开始发现用户在访问网页时需要进行身份认证之后才能获取该用户特有的数据，这个时候就慢慢出现了我们现在的交互式网页。但是我们的http协议是无连接、无状态的，多个请求之间是没有关联的，独立的。那既然http协议是无状态的，我们又怎么区分用户身份呢？
我们大家现在来想象一个场景：
我们在访问某个网页时需要先进行登录，服务器识别当前用户身份，再凭借当前身份去获取服务器上面的数据。而且大家有没有发现当我们登录一次之后，很长一段时间都不需要再登录了，那这是怎么实现的呢？
有人肯定会说，我们可以把账号密码存到我们本地储存里面，这样每次登录的时候让浏览器自己去完成登录不就实现保持登录状态了吗？
这看似解决了自动登录的问题，其实有非常大的弊端，首先我们将用户名和密码存储到本地储存里面就是一件非常危险的事情，一旦我们的电脑被攻击，我们本地储存里面的用户名和密码很容易被别人获取，其次虽然我们可以让浏览器自动帮我们登录，但是我们还是没有解决http协议无状态的问题，我们在此后发起的每一条请求都需要让浏览器想办法帮我们加入用户名和密码与服务器进行用户身份识别并保持登录状态，这样非常不合理。
那么我们能不能想办法让每一次的请求都自动帮我们带上一些数据到服务器，让服务器识别我们的身份呢？由此有人提出了cookie的概念
cookie鉴权：
当客户端第一次访问服务器时，服务器就会产生cookie，并且以setCookie的方式向cookie里面以键值对的形式存储一些关于用户信息的数据，并发送给我们的客户端，客户端会自动保存我们cookie中的数据。当浏览器下一次向服务器发送请求的时候，会自动携带这个cookie到服务器，服务器在解析出来cookie中的身份信息之后，会返回给客服端数据。
cookie的特点：
a、cookie储存在客服端
b、cookie是不可跨域的，每个cookie都会绑定一个单一的域名，无法在别的域名下面获取使用。
c、cookie的存储大小大概是4kb左右
d、cookie有两种保存形式，一种是保存在内存中，叫进程cookie，首先要知道当我们打开浏览器时，会启用进程，该cookie就保存在打开浏览器的进程中，当浏览器关闭的时，进程结束，cookie也就消失了。二是：客户端保存形式，叫硬盘cookie，保存在硬盘中，也就是在浏览器的安装目录下生成一个文件夹，有一个过期时间，除非用户手动清理或到了过期时间，cookie中的数据才会消失，不然是长期储存的。
使用cookie的优点：
1、弥补了HTTP协议无状态的缺点
2、存储在客户端，不占用服务器资源，减少服务器压力
cookie的缺点：
1、可以被用户主动禁用浏览器的Cookie功能，可以通过window.navigator.cookieEnabled属性查看当前浏览器Cookie是否开启。
2、可以被用户直接操作，Cookie保存在浏览器，并且是明文存储的，能够直接被用户查看、修改或删除。
3、若Cookie中含有关键敏感信息，可能会被不法分子通过跨站脚本攻击（XSS）、跨站请求伪造（CSRF）等手段获取到Cookie造成严重后果。
因为cookie里面的数据都是明文保存的，这样让cookie在HTTP协议上面传输是非常不安全的，而且cookie里面保存用户信息也是非常不安全的，所以，为了解决这个问题，出现了session机制。
session鉴权：
当用户第一次请求服务器时，服务器会根据我们的用户信息创建session，session里面包含一个用户唯一标识sessionID，和会话结束时间，这个sessionID是一个在服务器上面不重复且不容易找到规律伪造的不规律字符串，然后sessionID会以cookie作为载体的形式发送给客户端，浏览器在接收到我们的请求响应之后，会自动储存cookie，这个时候，cookie里面就只有一个sessionID，如果此时我们的电脑被攻击，sessionID被别人获取，获取我们在网络上传输sessionID被别人获取，其实意义也不大了，因为他没办法通过我们的sessionID推断出账号密码了。
而当我们再次向服务器发送请求的时候，会自动携带cookie到服务器，服务器从cookie中获取出来sessionID，与储存在服务器内存中的所有sessionID进行比较，如果发现sessionID，就认为本次会话期是存在且未过期的，返回给用户数据
注意：
1、session并不是cookie的一部分，他只是借助了cookie作为载体在HTTP协议上传输
2、session是有会话期，这个会话期结束时间，是创建session的时候设置的，而cookie的结束时间一般也是这个session的会话结束时间
我们创建session得到识别用户的唯一ID（sessionID）是不是解决了像cookie明文储存用户信息不安全的问题，这起来一切都非常的完美！但是细心的同学又发现了新的问题：
我们在创建session的时候，是不是会把每一个新的sessionID存到服务器的内存中，当我们下一次向服务器发起请求的时候，服务器会拿着本次请求的sessionID与服务器的内存中的所有sessionID比较，那这样是不是相当于我们在无形中增大了服务器的压力，如果我们一旦用户数量庞大，高并发请求的时候，是不是很容易干爆服务器的内存。而且我们如果此时再去请求另一台服务器的数据时，另一台服务器的内存中并没有储存这些sessionID，可扩展性也极差。
于是我们的技术前沿大佬们又想出了一个新的解决方案，我们能不能只在服务器上面生成用户唯一标识，但是不存储他呢，让这个唯一标识储存到客户端，每次客户端发起请求的时候携带这个标识到服务器上，服务器只进行身份验证呢？这个时候token就出现了。
Token以及Token鉴权
访问资源接口（API）时所需要的资源凭证。简单 token 的组成： uid(用户唯一的身份标识)、time(当前时间的时间戳)、sign（签名，token 的前几位以哈希算法压缩成的一定长度的十六进制字符串）。
特点：服务端无状态化、可扩展性好，支持移动端设备，安全，支持跨程序调用。
1、客户端使用用户名跟密码请求登录
2、服务端收到请求，去验证用户名与密码
3、验证成功后，服务端会签发一个 token 并把这个 token 发送给客户端
4、客户端收到 token 以后，会把它存储起来，比如放在 cookie 里或者 localStorage 里
5、客户端每次向服务端请求资源的时候需要带着服务端签发的 token
6、服务端收到请求，然后去验证客户端请求里面带着的 token ，如果验证成功，就向客户端返回请求的数据
7、每一次请求都需要携带 token，需要把 token 放到 HTTP 的 Header 里
8、基于token的用户认证是一种服务端无状态的认证方式，服务端不用存放 token 数据。用 解析token的计算时间换取session 的存储空间，从减轻服务器的压力，减少频繁的查询数据库
9、token完全由应用管理，所以它可以避开同源策略。
所以我们的cookie、session、token其实都是服务器端生成的，都是为了鉴别用户的身份，但是鉴于cookie的不安全性出现了session，而session又会面临着服务器性能方面的问题和可扩展性差的问题，因此出现了token，那么其实现在很多的HTTP协议的请求都选择token鉴别用户身份，但token也不是完美的，如果，我们在获取到用户的token之后，直接拼入到请求头中，向服务器发送请求，也是可以获取到用户数据的，况且现在在前后端分离式开发的调试过程中，大家也很愿意这样干，前端将获取到的token给后端哪去调试接口，但是整体情况上说，我们的token机制确实解决了用户身份鉴别的功能，对于服务器和客户端也都比较友好，不会造成性能问题