刷新令牌和访问令牌只是术语。

这个小小的类比可以帮助巩固使用访问令牌和刷新令牌背后的理论基础：

假设Alice通过邮寄给Bob一张支票，该支票可以在出票后1小时内兑现（假设），否则银行不会兑现。但Alice还在给银行的邮件中附上了一张纸条，要求银行接受并兑现支票，以防支票延迟（在规定范围内）

当Bob收到这张支票时，如果他看到这张支票被篡改（令牌篡改），他将自己丢弃这张支票。如果没有，他可以把它拿到银行兑现。在这里，当银行注意到发行时间超过了1小时的时限，但看到Alice的签名通知，要求银行在规定的延迟范围内兑现。

看到这张纸条后，银行会尝试验证签名的消息，并检查Alice是否仍然具有正确的权限。如果是，银行将支票兑现。鲍勃现在可以向爱丽丝承认这一点了。

虽然不是非常准确，但这个类比可以帮助您注意到处理事务所涉及的不同部分：

Alice（发件人-客户）Bob（接收者-资源服务器）银行（授权服务器）验证过程（数据库访问）支票（访问令牌）备注（刷新令牌）

主要是，为了优化可伸缩性，我们希望减少对Auth Server以及最终对数据库的API调用次数。我们需要在方便和安全之间取得适当的平衡。

注意：与链中的资源服务器相比，让Auth服务器更早地响应请求当然更常见。

这些答案都没有找到刷新令牌存在的核心原因。显然，您总是可以通过将客户端凭据发送到身份验证服务器来获得新的访问令牌/刷新令牌对——这就是您首先获得它们的方式。

因此，刷新令牌的唯一目的是限制通过网络发送到身份验证服务的客户端凭据的使用。访问令牌的TTL越短，就越需要使用客户端凭据来获取新的访问令牌，因此攻击者就越有机会破坏客户端凭据（尽管如果使用非对称加密发送客户端凭据，这可能非常困难）。因此，如果您有一个一次性刷新令牌，您可以使访问令牌的TTL任意小，而不影响客户端凭据。

据我所知，如果您需要撤销访问，刷新令牌只是为了性能和成本节省。

例1：不实现刷新令牌；仅实现长期访问令牌：如果用户滥用服务（例如：不支付订阅），您需要能够撤销访问令牌=>您需要在每个需要访问令牌的API调用上检查访问令牌的有效性，这会很慢，因为它需要DB查找（缓存可以帮助，但这更复杂）。

例2：实现刷新令牌和短期访问令牌：如果用户滥用服务（例如：不支付订阅），您需要能够撤销访问令牌=>短暂的访问令牌将在短暂的白色（例如1小时）后过期，用户将需要获得新的访问令牌，因此我们不需要对需要访问令牌的每个API调用进行验证。您只需要在从刷新令牌生成访问令牌时验证用户。对于坏用户，如果无法生成访问令牌，则可以注销该用户。当用户尝试重新登录时，验证将再次运行并返回错误。

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

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

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

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

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

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

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

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

我在这里获得了一些额外的资源，这些资源澄清了我们为什么需要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

由于刷新和访问令牌是加载了大量语义的术语，因此术语转换可能会有所帮助？

可撤销令牌-必须通过授权服务器检查的令牌可以链接（请参阅RTR-刷新令牌循环）可以用于创建不可撤销的令牌，但也可以直接使用（当卷很小且检查不会成为负担时）可以使用很长时间，但这取决于用户需要多久才能获得新的凭据（用户名/密码）可以在RTR或任何其他可疑行为上无效不可撤销令牌-自包含的令牌，不需要通过授权服务器进行检查适用于大数据、分布式服务器/api调用的横向扩展应该是短暂的（因为是不可撤销的）

2020年，浏览器中也可以存在刷新令牌（最初为后端系统提供），这一点已被接受-请参见https://pragmaticwebsecurity.com/articles/oauthoidc/refresh-token-protection-implications.因此，焦点从“可刷新性”（在没有用户的情况下，后端如何延长对api的访问）转向了“可撤销性”。

因此，在我看来，将刷新令牌读取为可撤销令牌并将访问令牌读取为不可撤销令牌（可能是快速过期不可撤销的令牌）看起来更安全。

作为2021良好实践的附带说明，系统始终可以从可撤销的令牌开始，并在授权服务器压力增加时转向不可撤销的。