我正在构建一个使用 JWT 进行身份验证的应用程序。我开始做一些研究，令我惊讶的是，对于刷新 token 和 token 存储等主题缺乏共识。
据我所知，JWT 和 OAuth 是两种不同的协议(protocol)，它们遵循 不同的规范。
OAuth 使用刷新 token 来获取新的访问 token ，但为了做到这一点，该过程涉及 4 个实体:用户(前端)、资源服务器(Facebook、Google 等) )、客户端服务器(例如 PHP Web 应用程序)和授权服务器。
在这种情况下，拥有刷新 token 是有意义的，因为为了刷新 token ，需要客户端 ID 和客户端 key (由资源/身份验证服务器颁发)，而客户端 key 只有客户端服务器知道而不是由用户(用户前端侧)。因此，对于窃取刷新 token 的攻击者来说，刷新 token 将毫无用处。
但我的问题是，对于未通过第三方资源服务器(例如 Google、Facebook 等)进行身份验证的应用程序，拥有刷新 token 真的有用吗？为什么不让 JWT token 最后作为只要作为刷新 token 。
另一方面，我可以看到，当刷新 token 与 JWT token 一起使用时，如 This Article状态，刷新 token 通常受到严格的存储要求，以确保它们不被泄露。但是，我找不到什么/在哪里以及如何在用户端存储此 token 以满足这些严格的存储要求。
有人可以告诉我这一切吗？谢谢。
注意:我想强调的是，我的网络应用程序没有使用第三方应用程序进行身份验证(Facebook、Google 等)，它是前端的单页应用程序，在服务器端是一个发出JWT token 。我的问题集中在这种架构上
最佳答案
简而言之，你是对的，如果你以相同的方式存储刷新和访问 token ，并且你的应用程序本身就是身份提供者，那么使用刷新 token 没有多大意义 - 它同样可以被窃取方式作为实际的访问 token 。
但是，请考虑两件事。
第一，访问 token 随每个请求一起发送。如果您查看最近(和较旧的)https 漏洞，外部攻击者有时可能会提取 https 流的位(在某些情况下，取决于具体漏洞)。这通常并不简单，并且可能无法满足每个请求。如果您有一个短期访问 token 和一个很少使用的长期刷新 token ，即使访问 token 因此类 ssl/tls 攻击而受到损害，刷新 token 也可能不会受到损害。这是一个非常微小的好处，但仍然如此。
此外，您还可以以不同的方式存储刷新 token 。这些代币的主要风险之一是 XSS。如果您以在 httpOnly cookie 中发出刷新 token 的方式实现身份提供程序，则 Javascript 无法访问刷新 token ，因此无法使用 XSS 来读取它。您仍然可以将访问 token 存储在 Javascript 对象或 localStorage 等中，如果它被泄露，它至少是短暂的。这很好，因为 XSS 通常需要用户交互，所以如果它工作过一次，因为例如用户单击了链接或访问了特定页面，则不能保证他会再次执行此操作，因此读取下一个访问 token 可能是对于攻击者来说是困难的。再说一次，这不是一个巨大的好处，但它是一个优势。
关于security - 刷新 token 和 JWT token 交互，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/49911112/