我应该将JWT令牌存储在哪里?httpOnly对cookie意味着什么

Question

我阅读了有关auth的文档。我在Nuxt项目上工作，我的服务器返回一个cookieHtppOnly

我的问题：

JWT令牌的存储有很多混乱，有些人不建议使用localStroage我还读到，我们可以直接在头中复制令牌，用于下一个请求，但我找不到示例。此外，当cookie是HttpOnly时，我们如何使用它，因为JavaScript无法访问它？

// https://github.com/FormidableLabs/urql/tree/main/exchanges/auth#quick-start-guide
if (result.data?.refreshLogin) {
// save the new tokens in storage for next restart
localStorage.setItem('token', result.data.refreshLogin.token);
localStorage.setItem('refreshToken', result.data.refreshLogin.refreshToken);
//...
}

资源：

• nuxt/auth=>https://www.npmjs.com/package/@nuxtjs/auth-next
• urql/auth=>https://www.npmjs.com/package/@urql/exchange身份验证
• https://formidable.com/open-source/urql/docs/advanced/authentication/
• https://formidable.com/open-source/urql/docs/api/auth-exchange/#options
• https://github.com/FormidableLabs/urql/tree/main/exchanges/auth#quick-起动指南
• https://blog.logrocket.com/jwt-authentication-best-practices/
• https://www.howtographql.com/react-urql/5-authentication/

Answer 1

JWT使用cookie比使用localStorage更安全。而且accessToken的过期时间很短，通常会用refreshToken刷新。

以下是对httpOnly效应的完美解释：https://www.ibm.com/mysupport/s/question/0D50z000062kLbCCAU/is-there-a-way-to-read-browser-cookie-with-httponly-flag-set-on-ibpm-856-cf02-

客户端API(如JavaScript(无法访问HttpOnly cookie。此限制消除了通过跨站点脚本(XSS(窃取cookie的威胁。如果浏览器允许您访问它，那么这将是浏览器中的缺陷。

如果有一个特定的cookie你想被浏览器修改，并且不担心它的XSS，你可以删除HTTPOnly标志。只有服务器端代码才能访问这些cookie。

---

如果您希望您的cookie被您的客户端代码修改，您可以只设置secure: true，并允许它用于httpOnly之外的更多内容。

cookie通用nuxt非常适合管理客户端cookie。

---

回答您的意见：

你说的是什么中间件？

你的东西能治疗失眠吗？发送GQL电话，看看你是否有什么东西。

---

我只在客户端与GQL合作过，所以我会给出我应该在哪里的反馈，但可能不是100%准确。

1. 您应该有一些后端逻辑来处理整个登录流，但如果您想管理某人是否登录的事实，这确实会在前端。您将需要一些状态来查看要向最终用户显示的内容。当然，这依赖于这样一种假设，即您的应用程序仅作为SPA运行，而后端作为GQL API运行。但根据你页面的隐私量等，你可能有各种方法来解决这个问题。很难给出这样一个宽泛的答案。

2. 两个后端都处理JWT。客户端负责存储它，检查它是否过期，然后刷新它。它会将它发送到后端，看看你是否可以访问请求的数据等等。对于前端，如果你想将它保存在cookie中，以便在刷新之间保持，那么它就在前端。

3. JWT刷新令牌存储在前端。当它过期时，你的前端应该将它发送到你的后端，让它更新它的值。然后，您可以保留更新的版本，直到它再次过期。

4. 如果通过资源请求，您的意思是访问数据库中包含的值，这是一些后端工作。您的前端负责调用查询/突变，甚至不知道幕后是什么。这就是GQL的全部要点，通过删除典型的RESTneneneba API所具有的所有可能的端点，使前端更友好。

---

总结

你的前端不能包含敏感信息，这是最重要的。

你的大部分问题都是知道堆栈的哪一边受到关注。我不确定你是否是一个全栈开发人员，但你可能应该阅读一些关于GQL如何工作的文章。

此外，这里还有很多问题。我确实建议你一次只关注一件事，不要同时关注很多方面，否则很难从整体上理解。

此外，StackOverflow上的那些帖子(询问很多事情(很快就会被关闭。