用于基于令牌的身份验证的 JWT 与 cookie

不记名令牌和 cookie 最大的区别在于浏览器会自动发送 cookie，其中不记名令牌需要显式添加到 HTTP 请求中。

此功能使 cookie 成为保护网站的好方法，用户可以在其中登录并使用链接在页面之间导航。

浏览器自动发送cookies还有一个很大的缺点，就是CSRF攻击。在 CSRF 攻击中，恶意网站利用您的浏览器会自动将身份验证 cookie 附加到对该域的请求的事实，并诱使您的浏览器执行请求。

假设 https://www.example.com 的网站允许经过身份验证的用户通过 POST 将新密码更改为 https://www.example.com/changepassword 来更改他们的密码，而无需发布用户名或旧密码。

如果您在访问恶意网站时仍然登录到该网站，该网站在您的浏览器中加载了一个触发 POST 到该地址的页面，您的浏览器将忠实地附加身份验证 cookie，从而允许攻击者更改您的密码。

Cookie 也可用于保护 Web 服务，但现在最常使用不记名令牌。如果您使用 cookie 来保护您的网络服务，则该服务需要存在于为其设置了身份验证 cookie 的域中，因为 same-origin policy 不会将 cookie 发送到另一个域。

此外，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 Authorization 标头中。

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 的内容：

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

总而言之：您正在阅读的帖子可能是将 JWT 作为不记名令牌与身份验证 cookie 进行比较，以用于浏览器和服务器身份验证目的。但是 JWT 可以做的更多，它带来了标准化和功能，可以在您可能正在考虑的用例之外使用。

---

虽然 cookie 可以通过与请求一起自动发送来增加 CSRF 攻击的风险，但是当设置 HttpOnly 标志时，它们可以降低 XSS 攻击的风险，因为任何注入的脚本进入页面将无法读取cookie。

CSRF：用户单击攻击者站点上的链接（或查看图像），这会导致浏览器向受害者站点发送请求。如果受害者使用 cookie，浏览器会自动将 cookie 包含在请求中，如果 GET 请求会导致任何非只读操作，则受害者站点很容易受到攻击。

XSS：攻击者在受害站点中嵌入脚本（受害站点仅在输入未正确清理的情况下易受攻击），并且攻击者的脚本可以执行 JavaScript 允许在页面上执行的任何操作。如果您将 JWT 令牌存储在本地存储中，攻击者的脚本可以读取这些令牌，并将这些令牌发送到他们控制的服务器。如果您使用带有 HttpOnly 标志的 cookie，攻击者的脚本将无法读取您的 cookie。也就是说，他们成功注入的脚本仍然可以做 JavaScript 可以做的任何事情，所以你仍然会受到 IMO 的困扰（即，虽然他们可能无法读取 cookie 以将其发送到他们自己的服务器以供以后使用，他们可以使用 XHR 向受害网站发送请求，无论如何都会包含 cookie）。

---

参考 - Need for JSON Web Token

饼干

https://i.stack.imgur.com/fvrwn.png

饼干的缺点

Cookie/会话 ID 不是自包含的。它是一个参考令牌。在每次验证期间，Gmail 服务器都需要获取与其对应的信息。

不适合涉及多个 API 和服务器的微服务架构

https://i.stack.imgur.com/kayrh.png

智威汤逊

JWT 是自包含的。它是一种价值代币。因此，在每次验证期间，Gmail 服务器不需要获取与其对应的信息。

它是数字签名的，所以如果有人修改它，服务器就会知道它

最适合微服务架构

它还有其他优点，例如指定过期时间。

https://i.stack.imgur.com/sQXBZ.png

---