如何将 JWT 令牌存储在仅限 HTTP 的 cookie 中? [英] How to store a JWT token inside an HTTP only cookie?
问题描述
我创建了一个应用程序，它仅使用服务器根据正确的登录凭据发送的 JWT，并针对我的后端 Express.js 服务器上的任何 /api 路由进行授权.
I have created an app that simply uses a JWT sent by the server upon correct login credentials, and authorizes against any /api route on my backend Express.js server.
另一方面，AngularJS 获取此令牌，将其存储在会话存储中，并使用身份验证拦截器将令牌发送回服务器.
AngularJS, on the other hand, took this token, stored it in session storage, and used an auth interceptor every go around to send the token back to the server.
我最近才明白这种做法有多危险.
I've more recently come to understand how dangerous this practice is.
我了解在这种情况下来回传输令牌的方法.但是，如果您想将该 JWT 存储在客户端 Javascript 无法读取的仅 HTTP 的安全 cookie 中，那么有人会在高层次上解释一下发生的方法吗?
I understand the transfer method of tokens back and forth, in this scenario. However, would someone be so kind as to explain, at a high level, the method that takes place when you want to store that JWT inside a secure, HTTP only cookie that the client side Javascript cannot read?
例如:凭据成功时
- cookie 在服务器上创建，
- 在创建 cookie 的同时创建 JWT
- 将 JWT 存储在名为 token 等的 cookie 属性中.
我试图在这里获得一个关于它是如何工作的心智模型.如果我的理解是正确的，那么这样做就不再需要身份验证拦截器，因为在正确的凭据登录后，服务器将在 cookie 中完成所有令牌的传输.
I'm trying to gain a mental model here of how it works. If my understanding is correct, doing it this way wouldn't require an auth interceptor anymore because upon correct credential login, the server would do all of the transferring of the token inside the cookie.
推荐答案
处理 cookie 有很多微妙之处，但在高层次上，cookie 是您的 Web 服务器可以设置的一段数据，然后由用户的网络浏览器存储，并在浏览器将来向同一服务器发出的任何请求时将其发送回服务器，只要 cookie 有效且适用于所发出的请求.
Dealing with cookies has their fair share of subtleties, but at a high level a cookie is a piece of data that your web server can set, that will be then stored by the user's web browser and sent back to the server on any future requests that browser makes to the same server as long as the cookie is valid and applicable to the request being made.
(这就是你不再需要使用 Angular 拦截器的原因，因为浏览器本身可以确保发送 cookie)
除了一些特殊标志选项(例如仅 HTTP)之外，您还可以在更高级别设置 cookie 以与给定域和路径相关联.例如，您的服务器可以设置一个 cookie，以便稍后浏览器将其发送给 /api 路径下的请求.
Besides some specials flag options, like the HTTP only, at a higher level you can set cookies to be associated with a given domain and path. For example, your server could set a cookie in such way that it would only be later sent by the browser to requests made under the /api path.
总结一下，cookies是HTTP的一种状态管理机制，参见相关的RFC 2617 了解更多详情.
To sum it up, cookies are a state management mechanism for HTTP, see the associated RFC 2617 for more details.
相比之下，JWT 只是一些具有众所周知的表示并遵循一些约定的数据.更具体地说，JWT 由标头、有效负载和签名部分组成，对于大多数 JWT 用例，通常建议保持有效负载的大小较小.有关详细信息，请参阅开始使用 JSON 网络令牌.
In contrast, a JWT is just some data that has a well-know representation and follows some conventions. More specifically, a JWT is composed of a header, payload and signature sections and is generally advised to keep the size of the payload small for most of the JWT use cases. See Get Started with JSON Web Tokens for more details.
如果您阅读上一篇文章，您会注意到 JWT 的最终表示是三个用点分隔的 Base64url 编码字符串.这很有趣，因为这意味着 JWT 非常适合在 HTTP 中使用，包括作为 cookie 的值.
If you go through the previous article you'll notice that the final representation of a JWT is three Base64url encoded strings separated by dots. This is specially of interest because it means a JWT is well-suited to be used within HTTP, including as the value of a cookie.
要记住的一点是，根据规范，您只能保证浏览器将支持每个 cookie 最多 4096 字节的 cookie(通过 cookie 的名称、值和属性的长度之和来衡量).除非您在令牌中存储大量数据，否则您应该没有问题，但这始终是需要考虑的事情.是的，您还可以将 JWT 令牌分解为多个 cookie，但事情开始变得更加复杂.
One thing to have in mind is that by the specification you are only guaranteed that a browser will support a cookie up to 4096 bytes per cookie (as measured by the sum of the length of the cookie's name, value, and attributes). Unless you're storing way to much data in the token you should not have an issue, but it's always something to consider. Yes, you can also break a JWT token into multiple cookies, but things start to get more complex.
此外，cookie 有其过期的概念，因此请记住这一点，因为 JWT 本身在身份验证范围内使用时也会有自己的过期概念.
Additionally, cookies have their notion of expiration, so have that in mind also because the JWT itself, when used within the scope of authentication will also have thei own notion of expiration.
最后，我只想解决您对将 JWT 存储在 localStorage/sessionStorage 中的一些担忧.你是对的，如果你这样做，你必须理解它的含义，例如，与存储关联的域中的任何 Javascript 代码都将能够读取令牌.但是，仅 HTTP cookie 也不是灵丹妙药.我会阅读以下文章:Cookie 与令牌:权威指南.
Finally, I just want to address some of your concerns about storing the JWT in localStorage/sessionStorage. You're correct that if you do it you have to understand its implication, for example, any Javascript code within the domain for which the storage is associated will be able to read the token. However, HTTP only cookies are also not a silver-bullet. I would give the following article a read: Cookies vs Tokens: The Definitive Guide.
它侧重于传统会话标识符 cookie 与基于令牌 (JWT) 的身份验证系统之间的区别，名为 在哪里存储令牌? 的部分值得一读，因为它解决了与安全相关的问题存储空间.
It focuses on the differences between the traditional session identifier cookies vs the token-based (JWT) authentication systems, the section named Where to Store Tokens? warrants a read as it tackles the security related aspects of storage.
TL:DR 人员总结:
A summary for the TL:DR folks:
网站面临的两个最常见的攻击媒介是跨站点脚本(XSS)和跨站请求伪造(XSRF 或 CSRF).当外部实体能够在您的网站或应用程序中执行代码时，就会发生跨站点脚本攻击.(...)
Two of the most common attack vectors facing websites are Cross Site Scripting (XSS) and Cross Site Request Forgery (XSRF or CSRF). Cross Site Scripting) attacks occur when an outside entity is able to execute code within your website or app. (...)
如果攻击者可以在您的域上执行代码，则您的 JWT 令牌(在本地存储中)很容易受到攻击.(...)
If an attacker can execute code on your domain, your JWT tokens (in local storage) are vulnerable. (...)
如果您将 JWT 与本地存储结合使用，则跨站请求伪造攻击不是问题.另一方面，如果您的用例要求您将 JWT 存储在 cookie 中，则需要防范 XSRF.
Cross Site Request Forgery attacks are not an issue if you are using JWT with local storage. On the other hand, if your use case requires you to store the JWT in a cookie, you will need to protect against XSRF.
(重点是我的)
这篇关于如何将 JWT 令牌存储在仅限 HTTP 的 cookie 中?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
