react jwt_React身份验证：如何在Cookie中存储JWT

react jwt

重点 (Top highlight)

👋 Say hi to me on Twitter!

Twitter 在 Twitter上 对我问好 ！

If you have a React app that needs to access data, perhaps your setup looks like this:

如果您有一个需要访问数据的React应用，则您的设置可能如下所示：

If that’s the case, there’s a decent chance that your API is secured somehow. Maybe you’re making authentication and authorization happen with JSON Web Tokens. If so, there’s also a decent chance you’re keeping your JWTs in local storage.

如果是这种情况，则很有可能以某种方式保护您的API。 也许您正在使用JSON Web令牌进行身份验证和授权。 如果是这样，那么您很有可能会将JWT保留在本地存储中。

You should strongly consider not storing them there anymore.

您应该强烈考虑不再将它们存储在那里。

JSON Web令牌应存储在哪里？ (Where Should JSON Web Tokens be Stored?)

This question drums up a lot of controversy around the internet. Perhaps even more controversial is whether you should be using JSON Web Tokens at all. For many applications that are as simple as the diagram above, cookies and sessions would be a sufficient form of authentication and authorization and would offer a lot of benefits.

这个问题在互联网上引起了很多争议。 也许更具争议性的是，您是否应该使用JSON Web令牌 。 对于像上图一样简单的许多应用程序，Cookie和会话将是身份验证和授权的足够形式，并提供很多好处。

However, if you are in a position where you really need to use JWTs (or just really want to), there are some things you can do to harden the security posture for your React apps. In this article, we’ll look specifically at where JWTs should be stored.

但是，如果您确实需要使用JWT(或只是想使用)，可以采取一些措施来增强React应用程序的安全性。 在本文中，我们将专门研究JWT的存储位置。

有什么选择？ (What are the options?)

When moving your JWTs out of local storage, there are two options I recommend:

当将JWT移出本地存储时，我建议有两种选择：

1. Browser memory (React state)
   浏览器内存(React状态)
2. HttpOnly cookie
   HttpOnly cookie

The first option is the more secure one because putting the JWT in a cookie doesn’t completely remove the risk of token theft. Even with an HttpOnly cookie, sophisticated attackers can still use XSS and CSRF to steal tokens or make requests on the user’s behalf.

第一种选择是更安全的选择，因为将JWT放在cookie中并不能完全消除令牌被盗的风险。 即使使用HttpOnly cookie，复杂的攻击者仍可以使用XSS和CSRF代用户窃取令牌或发出请求。

However, the first option isn’t always very practical. That’s because storing a JWT in your React state will cause it to be lost any time the page is refreshed or closed and then opened again. This leads to a poor user experience––you don’t want your users to need to log back in every time they refresh the page.

但是，第一种选择并不总是很实用。 那是因为在刷新或关闭页面然后再次打开页面时，将JWT存储在您的React状态将导致它丢失。 这导致糟糕的用户体验-您不希望用户每次刷新页面时都需要重新登录。

If you’re using a third-party authentication service like Auth0 or Okta, this isn’t a big deal because you can just call for another token behind the scenes (using a prompt=none call) to get a new token on refresh. However, this relies on a central auth server that is storing a session for your users.

如果您使用的是Auth0或Okta之类的第三方身份验证服务，这没什么大不了的，因为您可以在幕后调用另一个令牌(使用alert = none调用)以在刷新时获取新令牌。 但是，这依赖于为您的用户存储会话的中央身份验证服务器。

The same isn’t true if you’re rolling your own auth. In that case, you most likely have a completely stateless backend that just signs tokens and validates them at your API. If you’re using refresh tokens, Hasura has a great guide on how you can keep your access tokens in app state and refresh tokens in a cookie.

如果您要滚动自己的身份验证，则情况并非如此。 在这种情况下，您很可能拥有一个完全无状态的后端，该后端仅对令牌进行签名并通过您的API对其进行验证。 如果您使用的是刷新令牌，