尽管上面的答案很好，但我作为一名安全硕士生和程序员，在研究买家保护和欺诈时，曾在eBay工作过，可以说，将访问令牌和刷新令牌分开，在骚扰频繁输入用户名/密码的用户和保留撤销对可能滥用您服务的访问权限之间取得了最佳平衡。

想象一下这样的情景。您向用户发出3600秒的访问令牌，刷新令牌的时间长达一天。

用户是一个好用户，他在家里，上下你的网站，在他的iPhone上购物和搜索。他的IP地址不会改变，并且服务器负载很低。像每分钟3-5页的请求。当他在访问令牌上的3600秒结束时，他需要一个具有刷新令牌的新令牌。在服务器端，我们检查他的活动历史和IP地址，认为他是一个人，行为举止得体。我们授予他一个新的访问令牌以继续使用我们的服务。用户不需要再次输入用户名/密码，直到达到刷新令牌本身的一天寿命。用户是一个粗心大意的用户。他住在美国纽约，病毒程序被关闭，在波兰被黑客入侵。当黑客获得访问令牌和刷新令牌时，他试图模拟用户并使用我们的服务。但是，在短暂的实时访问令牌过期后，当黑客试图刷新访问令牌时，我们在服务器上注意到用户行为历史中的IP发生了巨大变化（嘿，这家伙在美国登录，现在在波兰仅3600秒后刷新访问）。我们终止刷新过程，使刷新令牌本身无效，并提示再次输入用户名/密码。该用户是恶意用户。他打算通过使用机器人每分钟调用1000次我们的API来滥用我们的服务。直到3600秒后，当他试图刷新访问令牌时，我们注意到他的行为，认为他可能不是人类。我们拒绝并终止刷新过程，并要求他再次输入用户名/密码。这可能会破坏他的机器人的自动流动。至少让他不舒服。

当我们试图平衡我们的工作、用户体验和被盗令牌的潜在风险时，您可以看到刷新令牌的表现非常完美。服务器端的看门狗不仅可以检查IP更改，还可以检查api调用的频率，以确定用户是否应该是一个好用户。

另一个词是，您还可以尝试通过在每个api调用上实现基本IP看门狗或任何其他措施来限制被盗令牌/滥用服务的损害控制。但这很昂贵，因为您必须读取和写入有关用户的记录，并且会降低服务器响应速度。

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

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

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

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

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

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

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

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

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

第一点是，有时用户的访问令牌可能会在用户不知情的情况下被盗。由于用户不知道攻击，他们将无法手动通知我们。然后，就我们给攻击者完成攻击的时间（机会）而言，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等）

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

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

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

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

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

让我们考虑一个系统，其中每个用户链接到一个或多个角色，每个角色链接到一种或多种访问权限。可以缓存这些信息以获得更好的API性能。但是，用户和角色配置可能会发生变化（例如，可能会授予新的访问权限，或者可能会撤销当前的访问权限），这些都应该反映在缓存中。

我们可以为此目的使用访问和刷新令牌。当使用访问令牌调用API时，资源服务器检查缓存的访问权限。如果有任何新的访问许可，则不会立即反映。一旦访问令牌过期（例如在30分钟内）并且客户端使用刷新令牌生成新的访问令牌，就可以使用来自DB的更新的用户访问权限信息来更新缓存。

换句话说，我们可以将昂贵的操作从使用访问令牌的每次API调用转移到使用刷新令牌生成访问令牌的事件。