前言
HTTP是一种“无状态”协议，它的每个请求都是完全独立的，每个请求中包含了处理这个请求所需的完整的数据，发送请求不会涉及到状态变更。
举个例子：你第一次去A店买了苹果，然后你第二次去买苹果时你和老板说我上次来过，能便宜点不，他说他不认识你，并且无论你去他那买多少次苹果他都不认识你。他只知道有人来买过苹果，具体是谁他不知道。
所以在浏览器向服务端请求数据的过程中就延伸出一种严重的问题–数据泄露，许多Web应用程序的安全和正常运行都取需要系统能够区分用户并识别用户及其权限。所以这就需要一些机制来为一个HTTP请求提供状态。它们使站点能够在会话期间对各用户做出适当的响应，从而保持跟踪用户在应用程序中的活动（请求和响应）。cookie和token都是典型的解决方案。
基于cookie的身份验证
cookie是由浏览器存储在客户计算机上的简单文件。该方法为有状态验证。它们通常包含一个名称和一个值，即键值对的形式存储。他用于将客户端标识为对服务器端具有特定许可权的特定用户。
cookie与源域相连接的方式可以确保仅源域能够访问其中存储的信息。第三方服务器既不能读取也不能更改用户计算机上该域的cookie内容。
那么他是如何进行身份验证的呢？
当用户向服务端请求数据时，服务端会创建一个会话（session），并将会话数据存储在数据库中，并向浏览器返回一个会话ID（sessionID）该ID对应服务端上的数据,客户端会将该ID存储在cookie中去，当客户端需要再一次向服务端请求数据时，服务端会验证该ID是否有效，并作出对应的响应。
缺点
- 每次页面请求都会把cookies往服务器上送一次，浪费了带宽；
- 状态数据存放在浏览器上确实是太危险了，一定会有人想办法把浏览器里的状态信息改掉来欺骗服务器，而且Cookies在HTTP请求中是以明文传输的，除非你用HTTPS，所以一般都是将有用信息保存在服务端，只向浏览器返回一个代表这些数据的ID。
- Cookie的大小限制在4KB, 对于复杂的状态数据显然不够用。
基于token的身份验证
基于token的验证一般指的是JSON Web Tokens（JWT），该方法为无状态验证。服务器不记录哪些用户已登陆或者已经发布了哪些JWT。对服务器的每个请求都需要带上验证请求的token。该标记既可以加在header中，可以在POST请求的主体中发送，也可以作为查询参数发送。
当用户向服务端发送请求时，服务端会返回一个盖了章的token，客户端将token，保存在浏览器的cookie 或sessionstorage中，当用户需要再一次向服务端请求数据时，需要携带该token，服务端会进行解码验证该token是否有效，并作出对应的响应。
优点
- 防跨站请求伪造（CSRF）
- 多站点使用
- 支持移动平台 移动端不支持cookie
- 尺寸小 传输速度快
本文作者为小王子，转载请注明。
