为了消除一些混淆，您必须了解客户机密码和用户密码的角色，这两个角色非常不同。

客户端是应用程序/网站/程序/。。。，该服务器希望通过使用第三方身份验证服务对用户进行身份验证。客户端机密是一个（随机）字符串，该字符串对此客户端和身份验证服务器都是已知的。使用这个秘密，客户端可以通过身份验证服务器识别自己，从而获得请求访问令牌的授权。

要获取初始访问令牌和刷新令牌，需要：

用户ID用户密码客户端ID客户机密

要获取刷新的访问令牌，客户端使用以下信息：

客户端ID客户机密刷新令牌

这清楚地表明了区别：在刷新时，客户端通过使用其客户端密钥来获得刷新访问令牌的授权，因此可以使用刷新令牌而不是用户ID+密码来重新验证用户。这有效地防止了用户必须重新输入他/她的密码。

这也表明，丢失刷新令牌是没有问题的，因为客户机ID和机密是未知的。它还表明，保持客户机ID和客户机机密是至关重要的。

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

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

这一切都与扩展和保持资源服务器无状态有关。

您的服务器/资源服务器服务器是无状态的，这意味着不检查任何存储以快速响应。通过使用公钥验证令牌的签名来执行此操作。检查每个请求的access_token。通过只检查access_token的签名和过期日期，响应速度非常快，并允许扩展。access_token应该有很短的到期时间（几分钟），因为如果它被泄露，就没有办法撤销它。身份验证服务器/OAuth服务器服务器不是无状态的，但它可以，因为请求要少得多。仅在access_token过期时检查refresh_token。（例如每2分钟）请求速率远低于资源服务器。将刷新令牌存储在数据库中，并可以撤消它。refresh_token可能有很长的到期时间（几周/几个月），如果它被泄露，有办法撤销它。

不过有一个重要的注意事项，身份验证服务器的请求要少得多，因此可以处理负载，但是由于必须存储所有refresh_token，因此可能存在存储问题，如果用户急剧增加，这可能会成为一个问题。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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