在 react.js 中存储访问令牌的位置? [英] Where to store access-token in react.js?

问题描述

我正在用 Reactjs 构建一个应用程序.在验证 access_token 后，我必须进行 fetch 调用.注册时，access_token 是从后端服务器获取的.但是，在哪里存储这些 access_token.有没有办法让这些 access_token 成为全局的，以便所有组件都可以访问它.我使用过本地存储、缓存和会话存储，但这些都是不可取的.这几天一直在纠结这个问题，求解决方法.提前致谢.

解决方案

可用选项和限制:

有两种用于存储令牌的选项:

1. 网络存储 API:提供 2 种机制:sessionStorage 和 localStorage.存储在此处的数据将始终可供您的 Javascript 代码使用，并且无法从后端访问.因此，例如，您必须手动将其添加到您的请求中的标头中.此存储仅适用于您应用的域，而不适用于子域.这两种机制的主要区别在于数据过期:

• sessionStorage:数据仅可用于会话(直到浏览器或标签页关闭).
• localStorage:存储没有过期日期的数据，只能通过JavaScript清除，或清除浏览器缓存/本地存储的数据

2. Cookies:自动发送到您的后端要求.可以控制您的 Javascript 代码的到期时间和可见性.可用于您应用的子域.

在设计身份验证机制时，您必须考虑两个方面:

• 安全性:访问或身份令牌是敏感信息.要始终考虑的主要攻击类型是跨站点脚本 (XSS) 和 跨站请求伪造 (CSRF).
• 功能需求:浏览器关闭时用户是否应该保持登录状态?他的会议将持续多久?等

出于安全考虑，OWASP 不建议将敏感数据存储在网络存储中.您可以查看他们的 CheatSheetSeries 页面.您还可以阅读这篇详细的文章了解更多详情.>

原因主要与XSS漏洞有关.如果您的前端不是 100% 抵御 XSS 攻击，那么恶意代码可能会在您的网页中执行，并且可以访问令牌.要完全防止 XSS 是非常困难的，因为它可能是由您使用的 Javascript 库之一引起的.

另一方面，如果 Cookie 设置为 HttpOnly，则 Javascript 可能无法访问它们.现在 cookie 的问题是它们很容易使您的网站容易受到 CSRF 的攻击.SameSite cookie 可以减轻这种类型的攻击.但是，旧版本的浏览器不支持这种类型的 cookie，因此可以使用其他方法，例如使用状态变量.此 Auth0 文档文章中有详细说明.

建议的解决方案:

为了安全地存储您的令牌，我建议您使用 2 个 cookie 的组合，如下所述:

JWT 令牌具有以下结构:header.payload.signature

通常，有效载荷中存在有用的信息，例如用户角色(可用于调整/隐藏部分 UI).因此，让该部分对 Javascript 代码可用非常重要.

一旦身份验证流程完成并在后端创建 JWT 令牌，想法是:

1. 将 header.payload 部分存储在 SameSite Secure Cookie 中(因此只能通过 https 使用，并且仍可用于 JS 代码)
2. 将 signature 部分存储在 SameSite Secure HttpOnly Cookie
3. 在后端实现一个中间件，以从这 2 个 cookie 中重新构建 JWT 令牌并将其放入标头中:Authorization: Bearer your_token

您可以为 cookie 设置到期时间以满足您应用的要求.

在 这篇文章 作者:Peter Locke.

I am building an app in Reactjs. I have to make fetch call, after verifying the access_token. On signup, access_token are acquired from back-end server. But, where to store these access_token. Is there any way of making these access_token global, so that all component can access it. I have used local storage, cache and session storage, but those are not advisable. Held up in this issue for past few days, any solutions for it. Thnks in advance.

解决方案

Available options and limitations:

There are 2 types of options for storing your token:

1. Web Storage API: which offers 2 mechanisms: sessionStorage and localStorage. Data stored here will always be available to your Javascript code and cannot be accessed from the backend. Thus you will have to manually add it to your requests in a header for example. This storage is only available to your app's domain and not to sub domains. The main difference between these 2 mechanisms is in data expiry:

• sessionStorage: Data available only for a session (until the browser or tab is closed).
• localStorage: Stores data with no expiration date, and gets cleared only through JavaScript, or clearing the Browser cache/Locally Stored Data

2. Cookies: Automatically sent to your backend with the subsequent requests. Expiry and visibility to your Javascript code can be controlled. Can be available to your app's sub domains.

You have to consider 2 aspects when designing your authentication mechanism:

• Security: An access or identity token is a sensitive information. The main types of attacks to always consider are Cross Site Scripting (XSS) and Cross Site Request Forgery (CSRF).
• Functional requirements: Should the user stay logged in when the browser is closed? How long will be his session? etc

For security concerns, OWASP does not recommend storing sensitive data in a Web Storage. You can check their CheatSheetSeries page. You can also read this detailed article for more details.

The reason is mainly linked to the XSS vulnerability. If your frontend is not a 100% protected against XSS attacks then a malicious code can get executed in your web page and it would have access to the token. It is very difficult to be fully XSS-proof as it can be caused by one of the Javascript librairies you use.

Cookies on the other hand can be unaccessible to Javascript if they are set as HttpOnly. Now the problem with cookies is that they can easily make your website vulnerable to CSRF. SameSite cookies can mitigate that type of attacks. However, older versions of browsers don't support that type of cookies so other methods are available such as the use of a state variable. It is detailed in this Auth0 documentation article.

Suggested solution:

To safely store your token, I would recommend that you use a combination of 2 cookies as described below:

A JWT token has the following structure: header.payload.signature

In general a useful information is present in the payload such as the user roles (that can be used to adapt/hide parts of the UI). So it's important to keep that part available to the Javascript code.

Once the authentication flow finished and JWT token created in the backend, the idea is to:

1. Store the header.payload part in a SameSite Secure Cookie (so available only through https and still availble to the JS code)
2. Store the signature part in a SameSite Secure HttpOnly Cookie
3. Implement a middleware in your backend to resconstruct the JWT token from those 2 cookies and put it in the header: Authorization: Bearer your_token

You can set an expiry for the cookies to meet your app's requirements.

This idea was suggested and very well described in this article by Peter Locke.

这篇关于在 react.js 中存储访问令牌的位置?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！