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

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

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

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

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

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

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

例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，采用了没有刷新令牌的协议，并对此感到满意。

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

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

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

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

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

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

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

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

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

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

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