JWT刷新令牌是否提供了更多的安全性？应该把它们存放在哪里？

我很难理解JWT刷新令牌如何比仅使用寿命长的普通JWT访问令牌更安全。我知道，通过缩短JWT访问令牌的寿命，它限制了攻击者滥用它的机会窗口。这假设攻击者已绕过HTTPS的SSL层，以便首先获得JWT访问令牌

JWT刷新令牌如何准确地解决这个问题？一旦访问令牌过期，您就必须传输刷新令牌，如果我们认为HTTPS不够安全，刷新令牌也可能被劫持。如果攻击者获得了刷新令牌的控制权，那么他现在可以访问大量的访问令牌，因为刷新令牌通常具有较长的使用寿命。通过扩展，我们还可以说，如果HTTPS协议被破坏，初始用户名/密码身份验证可能被窃取

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

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

我已经从以下链接（以及更多链接）中找到了一些写得很好的答案：

---

但我对这三个问题感到不满意。

我将尝试回答你问题中的所有要点

• 不要使用JWT刷新令牌。使用不透明的刷新令牌。通常，JWT的使用寿命非常短。这样做的原因是，如果你没有被列入黑名单，撤销它们可能是不可能的

• 您可以将刷新令牌存储在HttpOnly安全cookie中。如果您想避免CSRF和XSS，那么您可以拆分访问令牌并将一半存储在cookie中，另一半存储在localstorage中

• 如果您假设https被破坏（这实际上是可能的），那么这里最好的防御措施就是采取措施来检测被盗的刷新令牌。您可以通过实现。这也可以用来实现记忆我的功能相当容易，并具有最高级别的安全性

---

总的来说，这个话题相当复杂，我不可能在这里解释所有的事情。下面是一个我喜欢的例子，它解释了会话安全性要做的一切。他们还有一个名为YouCanUse的开源库，这是我见过的最安全的实现。他们在不同的技术栈中都有它，也可以为你的技术栈实现一个。

你已经收到了答案并选择了它，但我想我应该添加另一个视角

首先，我将用你的一个假设指出一点神话：

LocalStorage显然不适合存储刷新令牌，因为它 并不意味着是一个安全的存储

我相信有些人会不同意我的观点，但对我来说，本地存储和Cookie存储一样安全，甚至更安全

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

因此，从这个角度来看，Cookie提供了比LocalStorage更大的攻击面

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

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

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

因此，问题不完全是安全问题

至于你问题的要点，我理解为：

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

你说得对。访问令牌和刷新令牌都可能受损。问题是。。。一旦您的服务器发现，它可以做什么

访问令牌和刷新令牌的概念是，访问令牌的寿命很短，而刷新令牌的寿命很长

就个人而言，我认为刷新令牌几乎没有什么用处，除非您使用JWTs作为访问令牌，这是您在文章中回避的

正如您可能知道的，JWT是无状态的（尽管您可以实现白/黑列表，这会使它们有状态，但这有点违背了目的）。因此，服务器无法禁用无状态JWT

由于这个事实，有些人认为在JWT上长时间到期是有风险的，因为它们如果被破坏就不容易被禁用。我同意这一点

因此，为了“两全其美”，可以使用短到期JWT（10分钟左右）和长到期刷新令牌（许多OAuth实现从未使刷新令牌过期）

---

此策略允许您的服务器拒绝发布新的刷新令牌，从而拒绝新的访问令牌，同时还受益于JWTs的一些卖点，从而使您的服务器重新获得一些控制权。

我喜欢您将访问令牌拆分为cookie存储和localStorage以减轻CSRF和XSS的想法。但是这如何回答OP关于刷新tok的问题呢