json - 用于基于 token 的身份验证的 JWT 与 cookie

Question

我读过一些关于“JWT vs Cookie”的帖子，但它们只会让我更加困惑......

1. 我想澄清一下，当人们谈论“基于 token 的身份验证与 cookie”时，这里的 cookies 仅指 session cookies ？我的理解是cookie就像一个媒介，它可以用来实现基于token的身份验证(在客户端存储可以识别登录用户的东西)或基于 session 的身份验证(在客户端存储一个与服务器端上的 session 信息匹配的常量)

2. 为什么我们需要 JSON 网络 token ？我使用标准 cookie 来实现基于 token 的身份验证(不使用 session id，不使用服务器内存或文件存储): Set-Cookie: user=innocent; preferred-color=azure，我观察到的唯一区别是 JWT 同时包含 payload 和 signature...而您可以在 signed 或 plaintext 之间进行选择http header 的 cookie。在我看来，签名 cookie (cookie:'time=s%3A1464743488946.WvSJxbCspOG3aiGi4zCMMR9yBdvS%2B6Ob2f3OG6%2FYCJM') 更节省空间，唯一的缺点是客户端无法读取 token ，只有服务器可以。 ..但我认为这很好，因为就像 JWT 中的 claim 是可选的一样， token 没有必要有意义

Answer 1

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

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

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

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

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

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

此外，Cookie 使非基于浏览器的应用程序(例如移动设备到平板电脑应用程序)更难以使用您的 API。