JWT vs Cookies，用于基于令牌的身份验证 [英] JWT vs cookies for token-based authentication

问题描述

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

1. 我想要一些说明，当人们谈论基于令牌的身份验证与cookie"时， cookies 在这里仅指 会话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')更节省空间，唯一的缺点是客户端无法读取令牌，只有服务器可以...但是我认为这很好，因为就像 claim JWT是可选的，令牌不必有意义

解决方案

承载令牌和cookie之间的最大区别是浏览器将 自动发送cookie 令牌需要显式添加到HTTP请求中.

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

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

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

如果您访问的恶意网站仍在登录该网站，该恶意网站在浏览器中加载了触发该地址的POST的页面，则浏览器将忠实地附加身份验证cookie，从而使攻击者可以更改您的密码.

Cookie也可以用于保护Web服务，但是如今，不记名令牌是最常用的.如果您使用Cookie来保护您的Web服务，则该服务必须存在于设置了身份验证Cookie的域中，例如同源策略不会将Cookie发送到另一个域.

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

I read some posts about "JWT vs Cookie" but they only made me more confused...

1. I want some clarification, when people talking about "token-based authentication vs cookies", cookies here merely refer to session cookies? My understanding is that cookie is like a medium, it can be used to implement a token-based authentication(store something that can identify logged-in user on the client side) or a session-based authentication(store a constant on the client side that matches session information on the server side)

2. Why do we need JSON web token? I was using the standard cookie to implement token-based authentication(not using session id, not use server memory or file storage): Set-Cookie: user=innocent; preferred-color=azure, and the only difference that I observed is that JWT contains both payload and signature...whereas you can choose between signed or plaintext cookie for http header. In my opinion signed cookie (cookie:'time=s%3A1464743488946.WvSJxbCspOG3aiGi4zCMMR9yBdvS%2B6Ob2f3OG6%2FYCJM') is more space efficient, the only drawback is that client cannot read the token, only the server can...but I think it's fine because just like claim in JWT is optional, it's not necessary for token to be meaningful

解决方案

The biggest difference between bearer tokens and cookies is that the browser will automatically send cookies, where bearer tokens need to be added explicitly to the HTTP request.

This feature makes cookies a good way to secure websites, where a user logs in and navigates between pages using links.

The browser automatically sending cookies also has a big downside, which is CSRF attacks. In a CSRF attack, a malicious website takes advantage of the fact that your browser will automatically attach authentication cookies to requests to that domain and tricks your browser into executing a request.

Suppose the web site at https://www.example.com allows authenticated users to change their passwords by POST-ing the new password to https://www.example.com/changepassword without requiring the username or old password to be posted.

If you are still logged in to that website when you visit a malicious website which loads a page in your browser that triggers a POST to that address, your browser will faithfully attach the authentication cookies, allowing the attacker to change your password.

Cookies can also be used to protect web services, but nowadays bearer tokens are used most often. If you use cookies to protect your web service, that service needs to live on the domain for which the authentication cookies are set, as the same-origin policy won't send cookies to another domain.

Also, cookies make it more difficult for non-browser based applications (like mobile to tablet apps) to consume your API.

这篇关于JWT vs Cookies，用于基于令牌的身份验证的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！