JWT刷新令牌是否提供更高的安全性？一个应该在哪里存储它们？

Question

我正努力了解JWT刷新令牌比仅使用使用寿命长的普通JWT访问令牌更安全。我了解，通过缩短JWT访问令牌的寿命，可以限制攻击者滥用它的机会之窗。这假定攻击者以某种方式绕过了HTTPS的SSL层，以便首先获得JWT访问令牌。

JWT刷新令牌如何确切地解决此问题？一旦访问令牌过期，您将必须转移刷新令牌，如果我们假设HTTPS不够安全，也可以劫持该刷新令牌。如果攻击者获得了刷新令牌的控制权，那么由于刷新令牌的寿命通常较长，因此他现在可以访问大量的访问令牌。 通过扩展，我们还可以说，如果HTTPS协议遭到破坏，则初始用户名/密码身份验证可能会被盗。

由于刷新令牌必须保存在前端（我正在构建Angular / Spring引导应用程序），因此，我们必须格外注意，刷新令牌也不能在客户端被盗。 LocalStorage显然不适合存储刷新令牌，因为它并不是安全存储。它们也不适合发送给每个请求，因为否则它们将与访问令牌一起被盗，这首先会破坏使用寿命短的访问令牌的目的。 刷新令牌应该存储在哪里？

如果我希望在登录页面上提供记住我功能，我可以简单地设置具有无限使用寿命的刷新令牌吗？

我已经从以下链接（以及更多链接）中获得了几个写得很好的答案：

What if JWT is stolen? SPA best practices for authentication and session management https://security.stackexchange.com/questions/119371/is-refreshing-an-expired-jwt-token-a-good-strategy

但是我对这3个问题不满意。

Answer 1

我将尽力回答您问题中的所有要点

• 请勿使用JWT刷新令牌。使用不透明的刷新令牌。通常，JWT的使用寿命非常短。原因是如果您没有将其列入黑名单，则可能无法撤消它们

• 您可以将刷新令牌存储在安全的HttpOnly cookie中。如果要避免使用CSRF和XSS，则可以拆分访问令牌并将一半存储在cookie中，另一半存储在本地存储中

• 如果您认为https被入侵（实际上是可能的），那么最好的防御方法就是采取措施来检测被盗的刷新令牌。您可以通过实现rotating refresh tokens来完成。这也可以用来轻松实现具有最高安全性的“记住我”功能。

通常，这个主题非常复杂，我无法在这里解释所有内容。因此，这里有一个blog post，我喜欢这样解释所有与会话安全有关的事情。他们还有一个名为SuperTokens的开源库，您可以使用它是迄今为止我所见过的最安全的实现。他们在各种技术堆栈中都有它，并且还可以为您的技术堆栈实现一个。

Answer 2

您已经收到并选择了答案，但是我想我会添加另一个观点。

我将首先从您的一个假设中指出一个神话：

LocalStorage显然不适合存储刷新令牌，因为它 并不是安全存储。

我敢肯定有些人会对此表示反对，但是对我而言，LocalStorage与Cookie存储一样安全，甚至更多。

Cookie容易受到CSRF攻击，而LocalStorage则不那么容易。而且LocalStorage和Cookies都容易受到XSS攻击（甚至httpOnly cookie，因为注入的代码可以使用凭据执行任何操作）。

因此，从这个角度来看，Cookie的攻击面比LocalStorage大。

因此，从安全性的角度来看，在LocalStorage中存储访问NOR刷新令牌没有任何问题。

除了安全问题外，您可能 将它们存储在LocalStorage（或非Cookie商店）中，具体取决于您部署到的平台，例如：某些移动框架不需要支持Cookies。

相反，如果您计划运行执行服务器端呈现的JS Web应用程序，则可能需要Cookie，因为通常服务器进程将无法访问LocalStorage。

所以问题不完全是安全性之一。

关于您问题的主要要点，我理解为：

如果访问令牌容易受到攻击，那么刷新令牌会有所帮助，因为它们也同样容易受到相同的攻击吗？

您是对的。访问令牌和刷新令牌都可以被破坏。问题是……一旦发现，您的服务器将如何处理？

访问令牌和刷新令牌的想法是访问令牌寿命短，刷新令牌寿命长。

就个人而言，除非您将JWT用作访问令牌，否则我在刷新令牌中几乎没有用。

您可能知道，JWT是无状态的（尽管您可以实现白名单/黑名单，这会使它们成为有状态的，但这样做有损于目的）。因此，服务器无法禁用无状态JWT。

由于这个事实，有些人认为JWT的有效期很长是有风险的，因为一旦受到损害，它们很难被禁用。我同意这一点。

因此，要获得“两全其美”的效果，可以将具有短期限的JWT（大约10分钟）与具有较长期限的刷新令牌一起使用（许多OAuth实现永不使刷新令牌失效）。

此策略通过拒绝发布新的刷新令牌，从而拒绝新的访问令牌，同时还受益于JWT的某些卖点，使服务器获得了一些控制权。