节点刷新令牌为啥不在后端刷新

Posted 2023-03-04

【中文标题】节点刷新令牌为啥不在后端刷新

【英文标题】：Node refresh token why not refresh on backend节点刷新令牌为什么不在后端刷新

【发布时间】：2020-10-14 16:31:48

【问题描述】：

大家好，我是刷新令牌概念的新手。

但我认为这是今天的标准。

我正在构建一个 React/Node 应用程序，我在很多类似这里的文章中看到，我们应该向服务器发送额外的请求以刷新令牌

喜欢这里：https://medium.com/@monkov/react-using-axios-interceptor-for-token-refreshing-1477a4d5fc26

我的问题是我们是否有中间件来检查 cookie 中的访问令牌是否有效，为什么如果令牌无效服务器返回 401 状态，该访问令牌无效，然后我们从前端发送额外的请求以刷新令牌。

为什么不在中间件的cookies中检查令牌，在中间件中刷新令牌并返回新令牌，如果两者都无效返回401状态，但在教程中他们总是发送额外的刷新令牌请求

【参考方案1】：

当你说middleware 时，那是Angular 的interceptor 元素吗？因为有不同的使用概念。

回到您的 auth + refresh tokens 问题。 这就是 OAuth 的工作方式。

大多数 OAuth 库没有具有检查刷新令牌是否有效或不对您说“是的，刷新令牌没问题”的功能。如果 OAuth 库获得刷新令牌，它将为您提供一对新的 auth+refresh 令牌（显然，它将检查刷新令牌是否有效以继续进行）。

更多信息：关于 worfklow 的 RFC OAuth 2.0 (https://www.rfc-editor.org/rfc/rfc6749)

关于在 cookie 上存储令牌：

不要在 cookie 中存储不记名令牌：实现不得存储 cookie 中可以明文发送的不记名令牌（其中 是 cookie 的默认传输模式）。实现 将不记名令牌存储在 cookie 中的必须采取预防措施 防止跨站请求伪造。

来源：OAuth 2.0 RFC (https://www.rfc-editor.org/rfc/rfc6750)

【讨论】：

感谢您抽出宝贵的时间，回答会检查出来。当我说中间件时，我想到的是 Node -> Express on backend 中的中间件

如果不在cookies中令牌存储在哪里，我读到也不推荐localStorage，还有为什么我们需要在第一次请求时向服务器发送第二个请求我们可以刷新令牌？

这不是关于将令牌存储在 cookie 或 localStorage 上（如果你考虑一下，你需要将它们存储在某个地方），据我所知，两者都是可以接受的。这是关于你如何沟通后端和前端。还有一些地方你不应该通过 cookie 发送令牌，因为它们是不安全地发送的。您应该在请求正文中发送令牌（以两种方式）。

我没有收到您的why do we need to send second request？一旦您知道它们已过期，您只需请求一次新令牌。

【参考方案2】：

您不希望拥有一个自动刷新过期令牌的中间件，因为您不希望拥有一个永不过期的令牌。

从技术上讲，没有什么可以阻止您在服务器上拥有一个自动刷新过期令牌的中间件，实际上，您不需要编写中间件，只需将初始令牌的过期日期设置为非常长未来的时间，因为自动刷新它与确保它永不过期一样。

但在安全方面，您不应该这样做。想象一下攻击者设法获取用户的访问令牌的场景；如果您要自动刷新过期的令牌，那么攻击者可以终身访问该帐户，除非您当然更改了令牌签名 - 但您不知道要这样做。

更多关于令牌生命周期的细节here