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