刷新令牌和JWT令牌交互

Question

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

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

但我的问题是，对于一个没有通过第三方资源服务器如Google、Facebook等认证的应用程序，有一个刷新令牌真的有用吗？为什么不让JWT令牌像刷新令牌一样持续时间长。

另一方面，我可以看到，如本文所述，当刷新令牌与JWT令牌一起使用时，刷新令牌通常会受到严格的存储要求的约束，以确保它们不会泄露。但是，我无法找到在用户端存储该令牌的内容/位置以及如何存储该令牌以满足这些strick存储需求。

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

注意：我想强调的是，我的web应用程序不是使用第三方应用程序进行身份验证(Facebook，Google等），它是单页应用程序在前端端和服务器端的一个单一API发出一个JWT令牌。我的问题集中在这种建筑上

Answer 1

简而言之，您是对的，如果您以相同的方式存储刷新和访问令牌，并且您的应用程序本身是身份提供者，那么使用刷新令牌没有太大意义--它可能与实际访问令牌相同地被窃取。

但是，考虑两件事。

第一，访问令牌随每个请求一起发送。如果您查看最近（和以前）的https漏洞，外部攻击者有时可能会提取https流的部分（在某些情况下，取决于特定的漏洞）。这通常并不简单，而且可能不可能在每一个请求中都这样做。如果您有一个生存期较短的访问令牌和一个很少使用的生存期较长的刷新令牌，即使访问令牌通过这种SSL/TLS攻击受到损害，刷新令牌也可能不是。这是一个非常轻微的好处，但仍然。

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