我在这里获得了一些额外的资源，这些资源澄清了我们为什么需要refresh_token的某些问题。这些资源的一些要点如下：

在现实世界中，最好使用名为authServer和resourceServer/s的独立服务器authServer-仅用于身份验证和授权。该服务器的职责是发布刷新令牌、访问令牌以及登录和注销用户resourceServer-此服务器（也可以是负载平衡的多个服务器）提供受保护的数据。例如，这些数据可以像电子商务项目中的产品、评论等refresh_token的一个用途是，每次需要新的access_token时，我们不必通过网络（从前端到authServer）发送用户名和密码（凭据）。这应该只在第一次完成（当您还没有refresh_token时），refresh_taken将立即从authServer获取新的access_token，这样您就可以继续向受保护的resourceServer发出请求。这里的优点是，用户不必每次都提供凭据，因此用户的用户名和密码不容易被泄露。refresh_token的另一个主要用途是，假设您的authServer与现实世界中的resourceServer（第三方服务，如auth0、okta、azure等，或您自己的实现）相比非常受保护。您只需将access_token发送到resourceServer（以获取数据），而无需向resourceServer发送refresh_token。因此，当您的access_token发送到resourceServer时，很有可能会有黑客拦截您的resourceServer（因为它不像authServer那样安全），从而访问您的短暂访问权。因此，access_token的寿命很短（例如30分钟）。记住，当这个access_token过期时，您将向authServer（它比resourceServer更安全）发送refresh_token以获取新的access_toke。由于您在任何时候都不会向resourceServer发送refresh_token，因此拦截resourceServer的黑客不可能获得您的refresh_taken。如果作为一名开发人员，您仍然怀疑用户的refresh_token也可能被黑客入侵，那么您可以注销所有用户（使refresh_taken对所有用户无效），这样用户将再次登录（提供用户名和密码）以获得新的refresh_token+access_token，事情将再次步入正轨。

一些有用的资源

具有或不具有刷新令牌的工作流-Youtube

JWT认证代码示例-节点JS-Youtube

刷新令牌的思想是，如果访问令牌因其短暂而受到破坏，攻击者可以在有限的窗口中滥用它。

刷新令牌（如果被破坏）是无用的，因为攻击者除了需要刷新令牌之外还需要客户端id和密码，以便获得访问令牌。

话虽如此，由于每次对授权服务器和资源服务器的调用都是通过SSL完成的，包括请求访问/刷新令牌时的原始客户端id和secret，因此我不确定访问令牌如何比长期刷新令牌和客户端id/secret组合更“不可妥协”。

当然，这与不同时控制授权服务器和资源服务器的实现不同。

这里有一个很好的线程，讨论了刷新令牌的使用：OAuth存档。

引用上述内容，讨论刷新令牌的安全目的：

刷新令牌。。。降低长期access_token泄漏的风险（在不安全的资源服务器上的日志文件中查询参数，测试版或编码不良的资源服务器应用程序，非https站点上的JS SDK客户端将access_toke放入cookie等）

让我们考虑一个系统，其中每个用户链接到一个或多个角色，每个角色链接到一种或多种访问权限。可以缓存这些信息以获得更好的API性能。但是，用户和角色配置可能会发生变化（例如，可能会授予新的访问权限，或者可能会撤销当前的访问权限），这些都应该反映在缓存中。

我们可以为此目的使用访问和刷新令牌。当使用访问令牌调用API时，资源服务器检查缓存的访问权限。如果有任何新的访问许可，则不会立即反映。一旦访问令牌过期（例如在30分钟内）并且客户端使用刷新令牌生成新的访问令牌，就可以使用来自DB的更新的用户访问权限信息来更新缓存。

换句话说，我们可以将昂贵的操作从使用访问令牌的每次API调用转移到使用刷新令牌生成访问令牌的事件。

首先，客户端通过给予授权授权与授权服务器进行身份验证。然后，客户端通过提供访问令牌向资源服务器请求受保护的资源。资源服务器验证访问令牌并提供受保护的资源。客户端通过授予访问令牌向资源服务器发出受保护的资源请求，如果有效，资源服务器将在其中验证该请求并为请求提供服务。此步骤一直重复，直到访问令牌过期。如果访问令牌过期，则客户端向授权服务器进行身份验证，并通过提供刷新令牌来请求新的访问令牌。如果访问令牌无效，资源服务器将向客户端发回无效令牌错误响应。客户端通过授予刷新令牌与授权服务器进行身份验证。然后，授权服务器通过验证客户端来验证刷新令牌，并发出新的访问令牌（如果有效）。

客户可以通过多种方式受到损害。例如，可以克隆手机。访问令牌过期意味着客户端被迫重新向授权服务器进行身份验证。在重新认证期间，授权服务器可以检查其他特征（IOW执行自适应访问管理）。

刷新令牌允许仅客户端进行重新身份验证，其中重新授权会强制与用户进行对话，许多用户表示他们不愿意这样做。

刷新令牌基本上适用于正常网站可能选择在一小时左右后定期重新验证用户的相同位置（例如银行网站）。由于大多数社交网站都不会重新验证网络用户，因此目前它的使用率并不高，那么他们为什么要重新验证客户端呢？

为了理解这个问题的答案，我们需要了解两点。

第一点是，有时用户的访问令牌可能会在用户不知情的情况下被盗。由于用户不知道攻击，他们将无法手动通知我们。然后，就我们给攻击者完成攻击的时间（机会）而言，15分钟和一整天之间会有巨大的差异。因此，这就是我们需要每“短时间”（例如，每15分钟）“刷新”访问令牌的原因，我们不想将此操作推迟很长时间（例如，一整天）。因此，OP在问题中所说的显然不是一个选项（将访问令牌的到期时间延长到刷新令牌的有效时间）。

因此，我们至少还有以下两个选择：

要求每个用户每隔一段时间重新输入他们的凭据，以便为他们提供新的访问令牌。但显然，这不是一个流行的选项，因为它会困扰用户。使用刷新令牌。阅读下面的第二点，以了解其工作原理（背后的逻辑）。

第二点需要理解的是，因为我们已经将访问令牌与刷新令牌分开，现在可以以“不同的方式”发送刷新令牌，因此我们可以以攻击者的JavaScript（通常是客户端代码）无法访问的方式发送它，例如，使用httpOnly标记：

HttpOnly Cookie是添加到浏览器Cookie中的标记，用于阻止客户端脚本访问数据。来源

在生成cookie时使用HttpOnly标志有助于降低客户端脚本访问受保护cookie的风险。HttpOnly cookie于2002年由Microsoft Internet Explorer开发人员针对Internet Explorer 6 SP1首次实现。来源（感谢IE！）

因此，尽管攻击者仍然可以窃取访问令牌（强烈建议将其保存在RAM中，而不是本地存储等易受攻击的地方），但他们将无法窃取刷新令牌。因此，如果攻击者窃取了一个人的访问令牌，他们只有很短的时间滥用它（15分钟？比一整天好得多！），然后一旦它过期，他们就没有机会自己获得新的令牌。