服务器端刷新令牌

Question

一般问题不是特定于框架的，但对于上下文，我使用带有应用程序路由器和.NET API 的 nextjs v14。对于身份验证，我为访问令牌和刷新令牌设置了 cookie。刷新令牌的路径设置为

/auth/refresh-token

。

我的问题是，如果我在服务器渲染配置文件页面（其中显示有关当前登录用户的数据）或使用用户的访问令牌从 API 获取的任何其他页面，并且访问令牌过期，我该如何刷新令牌？

在客户端，我有 axios 中间件来处理令牌刷新并重试原始请求。但是，当访问令牌过期并且服务器上的 api 调用失败时，我无法在那里调用刷新令牌，因为刷新令牌的 cookie 已设置路径，因此不会在每个请求上发送它。

我尝试像

/refresh-token

一样重定向到客户端的临时页面，在客户端进行令牌刷新，然后重定向回原始网址，但这看起来很糟糕。例如，我看到 YouTube 在每个请求上都会调用

RotateCookiesPage

- 不确定这是否是可行的解决方案，因为他们每次刷新页面时都会调用该方法，并且如果由于令牌过期而导致初始渲染失败，则没有多大帮助。

我该如何处理这个问题？ Nextjs 的具体答案非常棒，但总体答案也足够了，所以我知道这是可能的，并且可以尝试使用 Nextjs 实现解决方案。

谢谢！

Answer 1

这是一个非常有趣的问题，涉及安全数据和不安全数据之间的差异。我的一些想法：

不安全的数据

对于不安全的数据，NEXT.js 可以为初始页面加载和 Ajax 请求复制数据。您可以预渲染数据并将其全部预部署到 CDN。您还可以获得 SEO 的好处。

安全数据

这有一些根本的区别：

• 无法预渲染，因为这不安全，因此您无法获得 NEXT.js 的所有优势
• 无法通过 SEO 访问

默认情况下，您从客户端的 API 获取数据。并处理刷新并使用最安全的 cookie 路径。

如果您也在运行时使用 SSR，成本和收益分别是多少？

• 现在需要做两处CSRF、两处API访问、两处token刷新等Web防御，这会导致cookie的暴露增加，复杂性更大。

• 性能优势并不总是像你想象的那么好。例如，在某些情况下，首次渲染的时间可能会稍快一些，而在其他情况下，下载大型 HTML 有效负载可能会降低性能。

该怎么办？