如何在移动应用程序环境中处理 JWT 刷新令牌

Question

我正在具有单独后端服务器的客户端移动应用程序中实现 JWT，并且我正在寻找一种使用刷新令牌的最佳方法，无需太多服务器调用，同时保持良好的用户体验。

我是实现这种机制的新手，我对很多事情感到困惑，所以我真正寻找的是一个可靠的概念解决方案来保护用户对应用程序的访问，并让他同时无限期地登录。

如有任何更正或建议，我们将非常欢迎：

• 为什么还要刷新令牌？

  单独使用 JWT 访问令牌可能会危及用户安全：如果攻击者持有访问令牌，他可以随时运行功能请求。即使对访问令牌应用了到期日期，如果服务器在旧访问令牌到期时发出新的访问令牌，攻击者也将使用旧的访问令牌接收新的访问令牌，并继续访问用户功能。

  一旦用户使用其登录名/密码重新获得对其帐户的访问权限，刷新令牌即可阻止攻击者：当用户使用应用程序且服务器检测到其刷新令牌无效时，他将被注销，并会生成新的刷新令牌和访问令牌在他使用凭据登录后发出。攻击者将无法使用旧令牌。

  我的第一个问题是：

  I. 无论攻击者如何从用户环境获取令牌，只要用户仍处于非活动状态并且没有使用其凭据再次登录以创建新令牌，他是否能够无限期地使用它们？

• 当令牌异步刷新时怎么办？

  让我们想象一个场景，其中用户位于应用程序内部，并且至少有两个服务器调用异步运行：

  • accessToken1“Service1”使用过期的和 a进行服务器调用refreshToken1，服务器通过发送新的accessToken2和refreshToken2
  • 在收到“Service1”响应之前，“Service2”使用 和 进行另一个服务器调用accessToken1，refreshToken1服务器refreshToken1与之前保存的进行比较refreshToken2，发现它们不同。然后它会做出响应Invalid refresh token，这会导致用户被注销！

  为了避免此问题并保持用户登录状态，可以有一个集中式身份验证服务，该服务在进行任何服务器调用之前首先检查令牌的有效性。这意味着除非身份验证服务空闲，否则不会执行任何调用，或者等待新令牌（如果已加载）。

  我的第二个问题是：

  二. 使用这样的服务来避免异步刷新令牌问题意味着到服务器的往返次数更多，这可能会导致成本高昂。有更好的解决方案吗？

Answer 1

登录/撤销对 api 的访问有一些步骤：

\n

\n
• 当您登录时，发送 2 个令牌（访问令牌、刷新令牌）以响应客户端。
\n
• 访问令牌的过期时间较短，而刷新的过期时间较长。
\n
• 客户端（前端）将刷新令牌存储在其本地存储中，并将访问令牌存储在 cookie 中。
\n
• 客户端将使用访问令牌来调用 API。但是当它过期时，从本地存储中选择刷新令牌并调用身份验证服务器 API 来获取新令牌。
\n
• 您的身份验证服务器将公开一个 API，它将接受刷新令牌并检查其有效性并返回新的访问令牌。
\n
• 一旦刷新令牌过期，用户将被注销。
\n

\n

JSON Web 令牌是在各方之间安全传输信息的好方法。因为 JWT 可以签名\xe2\x80\x94，例如，使用公钥/私钥对\xe2\x80\x94，您可以确定发送者是他们所说的人。此外，由于签名是使用标头和有效负载计算的，因此您还可以验证内容是否未被篡改。

\n

\n

当令牌异步刷新时怎么办？

\n

\n

应该通过对端点的单个请求来完成，因此有一个 accessToken

\n

\n

使用这样的服务来避免异步刷新令牌问题意味着到服务器的往返次数更多，这可能会导致成本高昂。有更好的解决方案吗？

\n

\n

我认为这是移动和无服务器应用程序的最佳且安全的解决方案，令牌就像 ssh 密钥一样必须始终保持安全:)

\n

有关更多信息，请检查[问题]：JWT 刷新令牌流程

\n

这是JWT官方的介绍

\n