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

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

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

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

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

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

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

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

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

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

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

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

这个答案来自Justin Richer通过OAuth 2标准正文电子邮件列表。这是在他的许可下发布的。

刷新令牌的生命周期取决于（AS）授权服务器-它们可以过期、被撤销等。刷新令牌和访问令牌的区别在于受众：刷新令牌只返回授权服务器，访问令牌返回（RS）资源服务器。

此外，仅仅获得访问令牌并不意味着用户已经登录。事实上，用户可能已经不在那里了，这实际上是刷新令牌的预期用例。刷新访问令牌将允许您代表用户访问API，但不会告诉您用户是否在那里。

OpenIDConnect不仅从访问令牌提供用户信息，还提供ID令牌。这是一个单独的数据块，指向客户端本身，而不是AS或RS。在OIDC中，如果您可以获得一个新的ID令牌，您应该只考虑某人实际通过协议“登录”。刷新它可能还不够。

有关更多信息，请阅读http://oauth.net/articles/authentication/

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

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

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

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

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

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

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

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

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

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

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

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

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