刷新令牌和 JWT 令牌交互

Question

我正在构建一个使用 JWT 进行身份验证的应用程序。我开始做一些研究，我对刷新令牌和令牌存储等主题缺乏共识感到惊讶。

据我所知，JWT 和 OAuth 是两种不同的协议，它们遵循 不同的规格。

OAuth 使用刷新令牌来获取新的访问令牌，但为此，流程中涉及 4 个实体，用户（前端）、资源服务器（Facebook、Google 等） )、客户端服务器（例如 PHP Web 应用程序）和授权服务器。

在这种情况下，有一个刷新令牌是有意义的，因为为了刷新令牌，它需要一个客户端 ID 和一个只有客户端服务器知道的客户端密码（由资源/验证服务器发布）而不是由用户（用户前端）。因此，对于窃取刷新令牌的攻击者来说，刷新令牌将毫无用处。

但我的问题是，对于一个没有针对第三方资源服务器（如谷歌、Facebook 等）进行身份验证的应用程序，拥有刷新令牌真的有用吗，为什么不让 JWT 令牌持久为只要一个刷新令牌。

另一方面，我可以看到，当刷新令牌与 This Article 状态的 JWT 令牌一起使用时，刷新令牌通常受到严格的存储要求，以确保它们不会泄露。但是，我找不到在用户端存储此令牌的内容/位置和方式，以满足这些严格的存储要求。

有人能告诉我这一切吗？谢谢。

注意：我想强调我的网络应用程序没有使用第三方应用程序进行身份验证（Facebook、Google 等），它是前端的单页应用程序和服务器端的单个 API，它发出一个智威汤逊令牌。我的问题集中在这种架构上

Answer 1

JWT 令牌应该有一个有限的生命周期，以限制它们在被盗时的有用性。刷新令牌用于在不涉及用户的情况下获取新的访问令牌，并且只能从机密客户端使用。

我在 this answer 中更详细地描述了 OAuth2 流程和刷新令牌的使用。

Answer 2

简而言之，您是对的，如果您以相同的方式存储刷新令牌和访问令牌，并且您的应用本身就是身份提供者，那么使用刷新令牌就没有多大意义 - 它同样可能被盗方式作为实际的访问令牌。

但是，请考虑两件事。

第一，访问令牌随每个请求一起发送。如果您查看最近（和较旧）的 https 漏洞，有时外部攻击者可能会提取 https 流的位（在某些情况下，取决于特定的漏洞）。这通常不是直截了当的，而且可能不可能在每个请求上都实现。如果您有一个寿命较短的访问令牌和一个很少使用的较长寿命的刷新令牌，即使访问令牌受到此类 ssl/tls 攻击的破坏，刷新令牌也可能不会。这是一个很小的好处，但仍然如此。

此外，您可能会以不同的方式存储刷新令牌。这些代币的主要风险之一是 XSS。如果您以在 httpOnly cookie 中发出刷新令牌的方式实现身份提供程序，则 Javascript 无法访问刷新令牌，因此无法使用 XSS 来读取它。您仍然可以将访问令牌存储在 Javascript 对象或 localStorage 或其他任何东西中，如果它被泄露，它至少是短暂的。这很好，因为 XSS 通常需要用户交互，所以如果它工作了一次，因为例如用户点击了一个链接或访问了特定页面，并不能保证他会再次这样做，所以读取下一个访问令牌可能是攻击者很难。同样，这不是一个巨大的好处，但它是一个优势。