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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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