具有 JWT 身份验证 refresh_token 的系统如何横向扩展答案

【问题标题】：How a system with JWT authentication refresh_token do horizontal scale out具有 JWT 身份验证 refresh_token 的系统如何横向扩展
【发布时间】：2021-09-27 23:22:13
【问题描述】：

我正在尝试使用 JWT 对我的网络应用进行身份验证。

我之所以选择它，是因为 JWT 适合横向扩展（水平）系统，因为我们不需要在服务器中存储任何内容（例如会话数据）。

我还想使用“让我登录”选项制作我的登录表单。然后我发现了魔法refresh_token solution。

这是一个很好的解决方案。

但是，我关心它如何实现横向扩展的目的？因为，AFAIK，我们必须将有关 refresh_token 的数据存储在数据库或类似的东西中。

P.s：如果上面的解释有误，我是分配系统的新手，请帮助纠正我。谢谢

【问题讨论】：

与其自行设置安全性，不如考虑研究现有的 OAuth2 系统。你不应该写这个。
@Evert 谢谢，我去看看

标签： node.js express authentication jwt

【解决方案1】：

刷新令牌由客户端持有，不需要服务器端存储（除非您正在考虑一些“奇怪”的使用场景）。所以没有水平缩放问题。在服务器上，您只保留 client_id 和 secret（它是 env var 或类似的，因此不会成为水平可扩展性的障碍）。

有一个类似的讨论： How to securely keep my users signed in with refresh tokens?

在 cmets 中编辑适当的讨论。服务器始终验证访问令牌（如果它未过期、签名是否有效、是否列入白名单、是否包含所需的范围等）。刷新令牌用于在旧令牌过期时请求新的访问令牌，这是它的唯一用途。

是的，服务器需要一些数据进行验证，但它是由 OAuth2 服务提供商通过 .well-known 端点或类似端点提供的。因此，服务器需要能够与服务提供商通信，才能获取验证所需的信息。

那些 .well-known 端点通常是公开的，例如：

【讨论】：

something 需要在服务器上存储刷新令牌，否则服务器怎么知道它是有效的？
@Evert 的问题是存储它以保持用户登录 - 从用户/系统端，而不是 oauth2 服务提供商如何验证它。
已编辑答案详细说明刷新令牌的目的 - 您通过将刷新令牌传递给 oauth2 服务提供商来请求新的访问令牌。您不应该以任何方式解释它，它只是存储为您延长访问的门票
@GintautasKišonas 您的假设是存在一个现有的 OAuth2 服务器，但不幸的是，对于许多新的 JWT 实施者来说，每个人都在重新发明轮子。
@Evert 好的同意我没有想到有人可能希望在有大量免费 SaaS 或自托管服务提供商的情况下实现自己的 OAuth2 服务提供商