为了进一步简化B T的答案：当您通常不希望用户再次输入凭据，但仍然希望能够撤销权限（通过撤销刷新令牌）时，请使用刷新令牌

您不能撤销访问令牌，只能撤销刷新令牌。

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

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

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

Catchdave提供的讨论链接还有Dick Hardt提出的另一个有效的观点（原始的，死链接），我认为除了上面写的内容之外，这里还值得一提：

我记得刷新令牌是为了安全和撤销。<...>撤销：如果访问令牌是自包含的，则可以通过不发布新的访问令牌来撤销授权。资源不需要查询授权服务器以查看访问令牌是否有效。这简化了访问令牌验证，并使扩展和支持多个授权服务器更加容易。当访问令牌有效但授权被撤销时，有一个时间窗口。

事实上，在资源服务器和授权服务器是同一个实体的情况下，并且用户和其中任何一个之间的连接（通常）都是同样安全的，那么将刷新令牌与访问令牌分开并没有多大意义。

尽管如引用中所述，刷新令牌的另一个作用是确保用户可以随时（例如通过其配置文件中的web界面）撤销访问令牌，同时保持系统的可伸缩性。

通常，令牌可以是指向服务器数据库中特定记录的随机标识符，也可以包含自身的所有信息（当然，这些信息必须使用MAC进行签名）。

具有长期访问令牌的系统应该如何工作

服务器允许客户端通过发出令牌访问预定义范围内的用户数据。由于我们希望保持令牌的可撤销性，我们必须在数据库中存储令牌以及设置或取消设置的标志“已撤销”（否则，如何使用自包含令牌？）。数据库可以包含多达len（用户）x len（注册客户端）x len（范围组合）的记录。然后，每个API请求都必须命中数据库。虽然对执行O（1）的数据库进行查询非常简单，但单点故障本身可能会对系统的可伸缩性和性能产生负面影响。

具有长期刷新令牌和短期访问令牌的系统应该如何工作

在这里，我们发布两个密钥：带有数据库中相应记录的随机刷新令牌，以及签名的自包含访问令牌，其中包含过期时间戳字段。

由于访问令牌是自包含的，因此我们根本不必访问数据库来检查其有效性。我们所要做的就是解码令牌并验证签名和时间戳。

尽管如此，我们仍然需要保留刷新令牌的数据库，但对该数据库的请求数量通常由访问令牌的寿命定义（寿命越长，访问率越低）。

为了撤销特定用户对客户端的访问，我们应该将相应的刷新令牌标记为“已撤销”（或完全删除），并停止发布新的访问令牌。很明显，在一个窗口中，刷新令牌已被撤销，但其访问令牌可能仍然有效。

权衡取舍

刷新令牌部分消除了访问令牌数据库的SPoF（单点故障），但它们有一些明显的缺点。

“窗口”。事件“用户撤销访问”和“保证撤销访问”之间的时间间隔。客户端逻辑的复杂性。无刷新令牌使用访问令牌发送API请求如果访问令牌无效，则失败并要求用户重新验证带刷新令牌使用访问令牌发送API请求如果访问令牌无效，请尝试使用刷新令牌更新它如果刷新请求通过，则更新访问令牌并重新发送初始API请求如果刷新请求失败，请要求用户重新验证

我希望这个答案确实有意义，有助于某人做出更深思熟虑的决定。我还想指出，一些著名的OAuth2提供商，包括github和foursquare，采用了没有刷新令牌的协议，并对此感到满意。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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