承载令牌和cookie之间最大的区别是浏览器将***自动发送cookie***，其中承载令牌需要显式添加到HTTP请求中。
此功能使Cookie成为保护网站安全的好方法，用户在网站上登录并使用链接在页面之间导航。
浏览器自动发送cookie也有一个很大的缺点，那就是CSRF攻击。在CSRF攻击中，恶意网站利用浏览器会自动将身份验证cookie附加到对该域的请求中，并欺骗您的浏览器执行请求。
假设网站https://www.example.com允许经过身份验证的用户通过POST更改其密码-将新密码更改为https://www.example.com/changepassword，而无需公布用户名或旧密码。
如果您访问恶意网站时仍登录到该网站，该网站会在您的浏览器中加载一个页面，从而触发对该地址的POST，则您的浏览器将忠实地附加身份验证Cookie，从而允许攻击者更改您的密码。
Cookies也可以用来保护网络服务，但现在最常用的是承载令牌。如果您使用Cookies来保护您的网络服务，该服务需要在设置了身份验证Cookies的域上运行，因为same-origin policy不会将Cookies发送到其他域。
此外，Cookie使非基于浏览器的应用程序（如移动的到平板电脑应用程序）更难使用您的API。

概述

您所要求的是从客户机向服务器发送JSON Web令牌（JWT）时cookie和承载令牌之间的区别。
Cookie和承载令牌都发送数据。
一个不同之处在于cookie用于发送和存储任意数据，而承载令牌专门用于发送授权数据。
这些数据通常被编码为JWT。
∮ ∮ ∮
Cookie是一个名称-值对，存储在Web浏览器中，具有到期日期和关联域。
我们使用JavaScript或HTTP响应头将Cookie存储在Web浏览器中。

document.cookie = 'my_cookie_name=my_cookie_value'   // JavaScript
Set-Cookie: my_cookie_name=my_cookie_value           // HTTP Response Header

Web浏览器会自动将Cookie与每个请求一起发送到Cookie的域。

GET http://www.bigfont.ca
Cookie: my_cookie_name=my_cookie_value               // HTTP Request Header

∮ ∮ ∮
不记名令牌是一个值，它会进入任何HTTP请求的Authorization标头。它不会自动存储在任何地方，它没有到期日期，也没有关联的域。它只是一个值。我们手动将该值存储在客户端中，并手动将该值添加到HTTP授权标头。

GET http://www.bigfont.ca
Authorization: Bearer my_bearer_token_value          // HTTP Request Header

JWT和基于令牌的身份验证

当我们进行基于令牌的身份验证时，例如OpenID、OAuth或OpenID Connect，我们会从可信的授权机构接收到access_token（有时是id_token）。通常我们希望存储它，并将其与受保护资源的HTTP请求一起发送。
选项1是将令牌存储在cookie中。这处理存储，并且还自动将令牌发送到每个请求的Cookie标头中的服务器。然后服务器解析cookie，检查令牌，并做出相应响应。
选项2是将令牌存储在本地/会话存储器中，然后手动设置每个请求的Authorization头，在这种情况下，服务器读取头并继续处理，就像cookie一样。
要了解更多信息，请阅读链接的RFC。

除了MvdD所说的关于cookie被自动发送：

1. Cookie可以是一种媒介，但它最重要的功能是如何与浏览器交互。Cookie由服务器设置，并以非常特定的方式在请求中发送。另一方面，JWT是一种专门的媒介，它是对特定结构中某些事实的Assert。如果您愿意，您可以将JWT作为您的验证Cookie。当您阅读比较它们的文章时，他们通常讨论使用由前端代码作为承载令牌发送的JWT，而不是对应于后端上的一些缓存会话或用户数据的身份验证cookie。
2. JWT提供了许多特性，并将它们放入标准中，以便可以在各方之间使用。JWT可以在许多不同的地方充当一些事实的签名Assert。Cookie，无论您在其中放入什么数据或是否对其签名，只有在浏览器和特定后端之间使用才真正有意义。JWT可以从浏览器使用到后端。在由不同方控制的后端之间（OpenId Connect是一个例子），或在一方的后端服务中。关于您的签名cookie的具体例子，您可能可以实现相同的功能（“不使用会话id，不使用服务器内存或文件存储”），但是除了在其他答案中谈到的CSRF问题之外，您还失去了库和标准的同行评审。
   总而言之：您正在阅读的帖子可能将JWT作为一个承载令牌与用于浏览器到服务器验证目的的验证cookie进行比较。但JWT可以做得更多，它带来了标准化和特性，可用于您可能正在考虑的用例之外。

虽然Cookie会随着请求一起 * 自动 * 发送，因此会增加CSRF攻击的风险，但如果设置了HttpOnly标志，则可以降低XSS攻击的风险，因为注入到页面中的任何脚本都无法读取Cookie。
CSRF：用户单击攻击者站点上的链接（或查看图像），这会导致浏览器向受害者站点发送请求。如果受害者使用cookie，浏览器会自动在请求中包含cookie，并且如果GET请求可导致任何非只读操作，则受害者站点容易受到攻击。
XSS：攻击者在受害站点中嵌入脚本（只有在输入未被正确净化的情况下，受害站点才会受到攻击），攻击者的脚本可以执行JavaScript允许在页面上执行的任何操作。如果您将JWT令牌存储在本地存储中，攻击者的脚本可以读取这些令牌，并将这些令牌发送到他们控制的服务器。如果您使用带有HttpOnly标记的Cookie，攻击者的脚本一开始就无法读取您的cookie，也就是说，他们成功注入的脚本仍然能够执行JavaScript所能执行的任何操作，因此您仍然无法执行任何操作（即，虽然他们可能不能读取cookie以将其发送到他们自己的服务器供以后使用，但是他们 * 可以 * 使用XHR向受害站点发送请求，其无论如何都将包括cookie）。

参考-Need for JSON Web Token

饼干

在使用Cookie的情况下，一旦用户通过身份验证，Gmail服务器将创建一个唯一的会话ID。与此会话ID相对应，Gmail服务器将在内存中存储识别用户并允许其执行操作所需的所有用户信息。
对于所有后续的请求和响应，这个会话id也将被传递，所以现在当服务器收到请求时，它将检查会话id，使用这个会话id将检查是否有任何相应的信息，然后它将允许用户访问资源并返回响应和会话id。

Cookie的缺点

• Cookies/会话ID不是自包含的。它是一个引用令牌。在每次验证过程中，Gmail服务器需要获取与其对应的信息。
• 不适合涉及多个API和服务器的微服务体系结构

JWT

• JWT是自包含的，它是一个值令牌，所以在每次验证过程中，Gmail服务器不需要获取与之对应的信息。
• 它是数字签名的，因此如果任何人修改它，服务器将知道它
• 它最适合微服务体系结构
• 它还有其他优点，比如指定过期时间。

1.是的，Cookie可以用于任何用途。
1.我们为什么需要 JWT ？
JSON是最好的（也是唯一需要的IMHO）数据格式，您可以在其中放置任何您想要的内容。
使用JWT，您不受数据大小的限制，使用Cookie，每个域只有4093字节-适用于所有Cookie，而不是一个Cookie。