我正在使用JWT构建应用程序进行身份验证。我开始做一些研究，我对于刷新令牌和令牌存储等主题缺乏共识感到惊讶。
据我所知，JWT和OAuth是两种不同的协议，它们都遵循 不同的规格。
OAuth使用刷新令牌来获取新的访问令牌，但为了做到这一点，流程中涉及4个实体，用户（前端），资源服务器（Facebook，Google等） ），客户端服务器（例如PHP Web应用程序）和授权服务器。
在这种情况下，拥有刷新令牌是有意义的，因为为了刷新令牌，需要客户端ID和客户端密钥（由资源/身份验证服务器发出），这只有客户端服务器知道而不是用户（用户前端侧）。因此，刷新令牌对于窃取刷新令牌的攻击者来说是无用的。
但我的问题是，对于未针对第三方资源服务器（如Google，Facebook等）进行身份验证的应用程序，拥有刷新令牌真的很有用，为什么不制作JWT令牌最后只要刷新令牌。
另一方面，我可以看到当刷新令牌与JWT令牌一起用作This Article状态时，刷新令牌通常受到严格的存储要求以确保它们不会泄露。但是，我无法找到What / Where以及如何在用户端存储此令牌以满足这些严格的存储要求。
有人可以告诉我这一切吗？感谢。
注意：我想强调一下，我的网络应用程序不使用第三方应用程序进行身份验证（Facebook，Google等），它是前端和单服务器端的单页应用程序，它发出一个API JWT令牌。我的问题集中在这种架构上
答案 0 :(得分：2)
简而言之，您是对的，如果您以相同的方式存储刷新和访问令牌，并且您的应用程序本身就是身份提供者，那么使用刷新令牌也没有多大意义 - 它可能被盗作为实际访问令牌的方式。
但是，请考虑两件事。
一，每次请求都会发送访问令牌。如果您查看最近（和较旧）的https漏洞，有时外部攻击者可能会提取https流的位（在某些情况下，具体取决于特定漏洞）。这通常不是直截了当的，并且可能在每次请求时都不可能。如果您有一个短期访问令牌和一个很少使用的更长寿命的刷新令牌，即使访问令牌通过这种ssl / tls攻击受到攻击，刷新令牌也可能不会。这是一个非常小的好处，但仍然。
此外，您可以以不同方式存储刷新令牌。这些令牌的主要风险之一是XSS。如果您以在httpOnly cookie中发出刷新令牌的方式实现身份提供程序，则Javascript无法访问刷新令牌，因此无法使用XSS来读取它。您仍然可以将访问令牌存储在Javascript对象或localStorage或其他任何内容中，如果它被泄露，它至少是短暂的。这很好，因为XSS通常需要用户交互，所以如果它工作一次，因为例如用户点击了链接或访问了某个特定页面，则无法保证他会再次执行此操作，因此读取下一个访问令牌可能是攻击者很难。同样，这不是一个巨大的好处，但 是一个优势。
答案 1 :(得分：-1)
JWT代币的使用寿命有限，以防止它们被盗时的实用性。刷新令牌用于获取新的访问令牌而不涉及用户，并且只能从机密客户端使用。
我在this answer中更详细地描述了OAuth2流程和刷新令牌的使用。