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

Question

我读了一些关于"JWT vs Cookie"的帖子,但它们只让我更加困惑......

1. 我想要澄清一下,当人们谈论"基于令牌的身份验证与cookie"时,这里的cookie只是指会话cookie吗？我的理解是cookie就像一个媒介,它可以用来实现基于令牌的身份验证(存储可以识别客户端登录用户的东西)或基于会话的身份验证(在客户端存储常量)匹配服务器端的会话信息)

2. 为什么我们需要JSON Web令牌？我使用标准cookie来实现基于令牌的身份验证(不使用会话ID,不使用服务器内存或文件存储):Set-Cookie: user=innocent; preferred-color=azure和我观察到的唯一区别是JWT包含有效负载和签名 ...而您可以选择http标头的签名或纯文本 cookie 之间.在我看来签署的cookie()cookie:'time=s%3A1464743488946.WvSJxbCspOG3aiGi4zCMMR9yBdvS%2B6Ob2f3OG6%2FYCJM'更节省空间,唯一的缺点是,客户端无法读取该令牌,只有服务器可以...但我认为这是很好的,因为就像要求在智威汤逊是可选的,它不是必需的令牌有意义

Answer 1

承载令牌和cookie之间的最大区别在于浏览器将自动发送cookie,其中需要将明确添加的承载令牌添加到HTTP请求中.

此功能使Cookie成为保护网站安全的好方法,用户使用链接登录并在页面之间导航.

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

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

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

Cookie也可用于保护Web服务,但现在最常使用的是承载令牌.如果您使用cookie来保护您的Web服务,则该服务需要存在于设置了身份验证cookie的域中,因为同源策略不会将cookie发送到另一个域.

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

Answer 2

概观

您要求的是用于将JSON Web令牌(JWT)从客户端发送到服务器的cookie和承载令牌之间的区别.

Cookie和承载令牌都会发送数据.

一个区别是cookie用于发送和存储任意数据,而承载令牌专门用于发送授权数据.

该数据通常编码为JWT.

曲奇饼

Cookie是一个名称 - 值对,存储在Web浏览器中,并且具有到期日期和关联域.

我们使用JavaScript或HTTP Response标头将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

持票人令牌

承载令牌是进入Authorization任何HTTP请求的标头的值.它不会自动存储在任何地方,它没有到期日期,也没有关联的域.这只是一个价值.我们在客户端手动存储该值,并手动将该值添加到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,检查令牌,并做出相应的响应.

另一种选择是将令牌存储在本地/会话存储中,然后手动设置Authorization每个请求的头.在这种情况下,服务器读取标题并像cookie一样继续.

值得阅读链接的RFC以了解更多信息.

Answer 3

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

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

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

Answer 4

除了MvdD关于自动发送cookie的说法:

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

总结:您正在阅读的帖子可能是将JWT作为承载令牌与用于浏览器到服务器身份验证的身份验证cookie进行比较.但JWT可以做得更多,它带来了标准化和功能,可以在您可能正在考虑的用例之外使用.

Answer 5

Ref -需要 JSON 网络令牌

饼干

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

饼干的缺点

• Cookies/session id 不是自包含的。它是一个参考令牌。在每次验证期间，Gmail 服务器都需要获取与其对应的信息。
• 不适合涉及多个 API 和服务器的微服务架构

智威汤逊

• JWT 是自包含的。它是一种价值代币。因此在每次验证期间 Gmail 服务器不需要获取与其对应的信息。
• 它是数字签名的，所以如果有人修改它，服务器就会知道它
• 最适合微服务架构
• 它还有其他优点，例如指定到期时间。