为什么OAuth v2同时具有访问和刷新令牌？

刷新令牌的想法是，如果访问令牌被破坏，因为它是短暂的，攻击者有一个有限的窗口来滥用它。

刷新令牌，如果受损，是无用的，因为攻击者除了刷新令牌之外还需要客户端ID和密钥才能获得访问令牌。

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

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

这里有一个关于刷新令牌使用的好线程：OAuth存档。

引用上面的一段话，讨论刷新令牌的安全目的：

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

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

因此，刷新令牌的唯一目的是限制通过网络发送到身份验证服务的客户端凭据的使用。访问令牌的TTL越短，就越经常使用客户端凭据来获取新的访问令牌，因此攻击者就越有机会破坏客户端凭据（尽管如果使用非对称加密来发送它们，这可能是超级困难的）。因此，如果你有一个一次性刷新令牌，你可以在不损害客户端凭据的情况下将访问令牌的TTL任意变小。

客户端可以通过多种方式受到攻击。例如可以克隆手机。访问令牌过期意味着客户端被迫重新向授权服务器进行身份验证。在重新身份验证期间，授权服务器可以检查其他特征（IOW执行自适应访问管理）。

刷新令牌只允许客户端重新身份验证，其中重新授权强制与用户进行对话，许多人表示他们宁愿不这样做。

刷新令牌基本上适用于普通网站可能在一小时左右后选择定期重新验证用户的地方（例如银行网站）。由于大多数社交网站不重新验证网络用户，因此目前它的使用并不广泛，那么他们为什么要重新验证客户端呢？

由Catchdave提供的讨论链接还有Dick Hardt制作的另一个有效点（原创，死链接），我相信除了上面写的之外，这里还值得一提：

我对刷新令牌的记忆是为了安全和撤销。<…>

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

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

虽然，正如引用中提到的，刷新令牌的另一个作用是确保用户可以随时撤销访问令牌（例如，通过其配置文件中的Web界面），同时保持系统的可扩展性。

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

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

服务器通过发出令牌，允许客户端在预定义的一组范围内访问用户的数据。由于我们希望保持令牌的可撤销性，我们必须在数据库中存储令牌以及设置或取消设置的“撤销”标志（否则，如果是自包含的令牌，你将如何做到这一点？）数据库可以包含多达len(users) x len(registered clients) x len(scopes combination)的记录。然后，每个API请求都必须访问数据库。虽然对这样的数据库进行O（1）的查询非常微不足道，但单点故障本身会对系统的可扩展性和性能产生负面影响。

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

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

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

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

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

权衡

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

1. “窗口”。事件“用户撤销访问权限”和“保证撤销访问权限”之间的时间范围。

2. 客户端逻辑的复杂性。

   没有刷新令牌

   • 使用访问令牌发送API请求
   • 如果访问令牌无效，失败并要求用户重新验证

   与刷新令牌

   • 使用访问令牌发送API请求
   • 如果访问令牌无效，请尝试使用刷新令牌更新它
   • 如果刷新请求通过，更新访问令牌并重新发送初始API请求
   • 如果刷新请求失败，要求用户重新验证

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

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

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

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

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

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

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

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

为什么不只是让access_token和refresh_token一样长没有refresh_token吗？

除了其他人提供的很好的答案之外，我们使用刷新令牌还有另一个原因，这与索赔有关。

每个令牌都包含声明，其中可以包括用户名称、角色或创建声明的提供者的任何内容。随着令牌的刷新，这些声明会更新。

如果我们更频繁地刷新令牌，我们显然会给我们的身份服务带来更大的压力；然而，我们正在获得更准确和最新的声明。

为了澄清一些混淆，你必须了解客户端机密和用户密码的角色，这是非常不同的。

客户端是由服务器支持的应用程序/网站/程序/…，它希望通过使用第三方身份验证服务来验证到用户。客户端密钥是此客户端和身份验证服务器都知道的（随机）字符串。使用此密钥，客户端可以在身份验证服务器中识别自己，接收授权管理以请求访问令牌。

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

• 用户ID
• 用户密码
• 客户端ID
• 客户的秘密

为了获得刷新的访问令牌，客户端使用以下信息：

• 客户端ID
• 客户的秘密
• 刷新令牌

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

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

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

想象一下这样的场景。您向用户颁发3600秒的访问令牌，并将令牌刷新一天。

1. 用户是一个好用户，他在家里，在你的网站上购物和搜索他的iPhone。他的IP地址不变，在你的服务器上的负载很低。比如每分钟3-5次页面请求。当他在访问令牌上的3600秒结束时，他需要一个带有刷新令牌的新用户。我们在服务器端检查他的活动历史记录和IP地址，认为他是一个人，表现得很好。我们授予他一个新的访问令牌来继续使用我们的服务。用户不需要再次输入用户名/密码，直到他达到刷新令牌本身的一天寿命。

2. 用户是一个粗心的用户。他住在美国纽约，病毒程序关闭了，被波兰的黑客攻击了。当黑客获得访问令牌和刷新令牌时，他试图冒充用户并使用我们的服务。但是在短暂的访问令牌到期后，当黑客试图刷新访问令牌时，我们在服务器上注意到用户行为历史中发生了巨大的IP变化（嘿，这家伙登录在美国，现在只花了3600秒就刷新了波兰的访问权限？？？）。我们终止刷新过程，使刷新令牌本身无效并提示再次输入用户名/密码。

3. 用户是一个恶意用户，他打算通过使用机器人每分钟调用1000次我们的API来滥用我们的服务。直到3600秒后，当他试图刷新访问令牌时，我们注意到他的行为，认为他可能不是人类。我们拒绝并终止刷新过程，并要求他再次输入用户名/密码。这可能会破坏他的机器人的自动流程。至少让他不舒服。

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

换句话说，您也可以尝试通过在每次API调用上实现基本IP看门狗或任何其他措施来限制被盗令牌/滥用服务的损害控制。但这是昂贵的，因为您必须读取和写入有关用户的记录，并且会减慢您的服务器响应。

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

我们可以为此使用访问和刷新令牌。当使用访问令牌调用API时，资源服务器会检查缓存中的访问权限。如果有任何新的访问授权，它不会立即反映出来。一旦访问令牌过期（比如30分钟后），客户端使用刷新令牌生成新的访问令牌，就可以使用数据库中更新的用户访问权限信息更新缓存。

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

首先，客户端通过授予授权权限与授权服务器进行身份验证。

然后，客户端通过提供访问令牌向资源服务器请求受保护的资源。

资源服务器验证访问令牌并提供受保护的资源。

客户端通过授予访问令牌向资源服务器发出受保护的资源请求，资源服务器将验证访问令牌并提供请求（如果有效）。此步骤会不断重复，直到访问令牌过期。

如果访问令牌过期，客户端向授权服务器进行身份验证，并通过提供刷新令牌请求新的访问令牌。如果访问令牌无效，资源服务器将无效令牌错误响应发回客户端。

客户端通过授予刷新令牌与授权服务器进行身份验证。

然后，授权服务器通过对客户端进行身份验证来验证刷新令牌，并发布一个新的访问令牌（如果它有效）。

刷新令牌由授权服务器保留。访问令牌是自包含的，因此资源服务器可以在不存储它的情况下对其进行验证，从而节省了验证时检索的工作量。讨论中缺少的另一点来自rfc6749#page-55

"例如，授权服务器可以使用刷新令牌轮换，其中每次访问都会颁发一个新的刷新令牌令牌刷新响应。上一个刷新令牌无效，但由授权服务器保留。如果刷新令牌是受到攻击并随后被攻击者和合法客户，其中一个将提供无效的刷新令牌，这将通知授权服务器违规。”

我认为使用刷新令牌的全部意义在于，即使攻击者以某种方式设法获得刷新令牌、客户端ID和秘密组合。如果每个刷新请求都导致新的访问令牌和刷新令牌，则可以跟踪攻击者获取新访问令牌的后续调用。

假设你让access_token持续很长时间，没有refresh_token，所以在一天内，黑客得到这个access_token，他可以访问所有受保护的资源！

但是如果你有refresh_token，access_token的生存时间很短，所以黑客很难破解你的access_token，因为它在短时间内会无效。Access_token只能通过不仅使用refresh_token，而且使用client_id和client_secret来检索，这是黑客没有的。

这个答案是在两位资深开发人员（John Brayton和David Jennes）的帮助下得出的。

使用刷新令牌的主要原因是为了减少攻击面。

假设没有刷新键，让我们来看看这个例子：

一栋大楼有80扇门。所有的门都是用同一把钥匙打开的。钥匙每30分钟更换一次。在30分钟结束时，我必须把旧钥匙交给钥匙匠，然后得到一把新钥匙。

如果我是黑客，拿到了你的钥匙，那么在30分钟结束时，我会把它快递给钥匙制造者，然后得到一把新钥匙。无论换钥匙，我都能不断打开所有的门。

提问：在这30分钟里，我有多少次破解密钥的机会？我有80次黑客机会，每次你使用密钥（把这想象成发出网络请求并传递访问令牌来识别自己）。这就是80X攻击面。

现在让我们通过相同的例子，但这一次让我们假设有一个刷新键。

一栋大楼有80扇门。所有的门都是用同一把钥匙打开的。钥匙每30分钟更换一次。要获得新钥匙，我不能通过旧的访问令牌。我只能通过刷新钥匙。

如果我是黑客，拿到了你的密钥，我可以使用它30分钟，但在30分钟结束时，将它发送给密钥制造者没有任何价值。如果我这样做了，那么密钥制造者只会说“此令牌已过期。您需要刷新令牌。”为了能够扩展我的黑客攻击，我必须将信使破解给密钥制造者。信使有一个独特的密钥（将其视为刷新令牌）。

提问：在30分钟内，我对刷新密钥有多少次黑客攻击机会？80？不。我只有1次黑客攻击机会。在这段时间里，快递员与密钥制造商通信。所以这是1X攻击面。我确实有80次破解密钥的机会，但30分钟后就没有用了。

服务器将基于凭据和（通常）JWT的签名来验证访问令牌。

访问令牌泄漏是不好的，但一旦过期，它对攻击者就不再有用了。刷新令牌泄漏要糟糕得多，但可能不太可能。（我认为有空间质疑刷新令牌泄漏的可能性是否远低于访问令牌泄漏，但这就是我们的想法。）

要点是访问令牌被添加到您发出的每个请求中，而刷新令牌仅在刷新流程中使用所以MITM看到令牌的机会更小

类似于心脏出血的SSL中的潜在安全漏洞、客户端中的潜在安全漏洞以及服务器中的潜在安全漏洞都使泄漏成为可能。

此外，如果授权服务器与处理其他客户端请求的应用程序服务器是分开的，那么该应用程序服务器将永远不会看到刷新令牌。它只会看到不会持续很长时间的访问令牌。

分隔对安全性有好处。

最后但并非最不重要的是，刷新令牌可以获得旋转。这意味着“每次客户端请求将刷新令牌交换为新的访问令牌时都会返回一个新的刷新令牌。”由于刷新令牌不断交换和失效，威胁就会降低。给你一个例子：令牌通常在TTL之后过期，通常是一个小时。

刷新令牌并不总是如此，但通常会在使用时撤销并颁发新的令牌。这意味着如果您遇到网络故障，当您检索新的刷新令牌时，然后下次发送该刷新令牌时，它被视为已撤销，您必须登录。

有关旋转的更多信息，请参阅这里和这里

总结

• 降低频率
• 分隔
• 令牌的轮换（更快的失效）和更细粒度的管理（过期时间或请求数量）。

都有助于减轻威胁

关于这一点，请参阅这个很棒的答案

什么刷新令牌不是关于？

通过刷新令牌更新/撤销访问级别的能力是选择使用刷新令牌的副产品，否则独立访问令牌可能会被撤销或在其过期且用户获得新令牌时修改其访问级别

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

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

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

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

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

假设爱丽丝通过post向Bob发送了<强>支票，可以在发出后1小时内兑现（假设），否则<强>银行将不会兑现。但爱丽丝还在给银行的帖子中加入了一张纸条，要求银行接受并兑现支票，以防它有点延迟（在规定的范围内）。

当鲍勃收到这张支票时，如果他看到这张被篡改（令牌篡改），他将自己<强>丢弃这张支票。如果没有，他可以把它带到银行兑现。在这里，当银行注意到发行时间已经超过了1小时的时间限制，但看到爱丽丝的签名纸条，要求银行在规定的延迟在可接受的范围内兑现。

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

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

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

主要是，我们希望减少对身份验证服务器的API调用次数，最终到数据库，以优化可扩展性。我们需要在方便和安全之间使用正确的平衡来做到这一点。

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

由于刷新和访问令牌是包含大量语义学的术语，术语转换可能会有所帮助？

• 可撤销代币-必须使用授权服务器检查的令牌
  • 可以链接（参见RTR-刷新令牌轮换）
  • 可用于创建NonRevokable代币，但也可以直接使用（当交易量很小并且支票不会成为负担时）
  • 可以长期存在，但这取决于用户必须为凭据（用户名/密码）而烦恼以获得新凭据的频率
  • 可以在RTR或任何其他可疑行为上无效
• 不可撤销的代币-自包含且不需要使用授权服务器检查的令牌
  • 对于大数据、分布式服务器/api调用水平扩展很有用
  • 应该是短暂的（因为它们是不可撤销的）

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

所以，对我来说，把刷新代币读成可撤销代币和访问令牌读成不可撤销的代币（也许是快速到期的不可撤销代币）看起来更安全。

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

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

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

所以我们至少有两个选择：

• 要求每个用户每隔一小段时间重新输入他们的凭据，以便为他们提供新的访问令牌。但显然，这不是一个受欢迎的选项，因为它会困扰用户。

• 使用刷新令牌。阅读下面的第二点以了解它是如何工作的（背后的逻辑）。

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

HttpOnly Cookie是添加到浏览器cookie中的标签，可防止客户端脚本访问数据。来源

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

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

这一切都是关于缩放和保持资源服务器无状态。

• 您的服务器/资源服务器

  • Server是无国籍，这意味着不检查任何存储以快速响应。通过使用公钥来验证令牌的签名来做到这一点。

  • 在每个请求上检查access_token。

  • 通过仅检查access_token的签名和到期日期，响应非常快并允许缩放。

  • access_token应该有短的过期时间（几分钟），因为没有办法撤销它，如果它被泄露损害是有限的。

• 身份验证服务器/OAuth服务器
  • 服务器是不是无国籍，但没问题，因为请求要少得多。
  • 仅当access_token过期时检查refresh_token。（例如每2分钟）
  • 请求率远低于资源服务器。
  • 将刷新令牌存储在DB中并可以撤销它。
  • refresh_token可以有很长的过期时间（几周/几个月），如果它被泄露，有一种方法可以撤销它。

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

我在这里得到了一些额外的资源，这些资源澄清了为什么我们需要refresh_token。这些资源的一些关键点如下：

• 在现实世界中，最好有单独的服务器，称为authServer和resourceServer/s
  • 认证服务器-仅用于身份验证和授权。此服务器的职责是发出刷新令牌、访问令牌并注销用户
  • 资源节点-此服务器（也可以是多个服务器负载均衡）提供受保护的数据。例如，此数据可以像电子商务项目中的产品、评论等
• refresh_token的一个用途是，当我们需要一个新的access_token时，我们不必每次都通过网络发送username and password (credentials)（从前端到认证服务器）。这只应该在第一次（当你还没有refresh_token的时候）这样做，refresh_token会从现在开始给你新的access_token，从认证服务器开始，这样你就可以继续向受保护的资源节点发出请求。这里的优点是，用户不必每次都提供凭据，因为用户的用户名和密码不容易被泄露。
• refresh_token的另一个主要用途是，假设你的认证服务器是非常受保护，而现实世界中是资源节点（第三方服务，如Auth0，okta，access_token0等或你自己的实现）。你只会把你的access_token发送到资源节点（获取数据），你永远不必把refresh_token发送到资源节点。所以很有可能你的access_token发送到资源节点时，有一个黑客拦截你的资源节点（因为它不像AuthServer那样安全）谁可以访问你短暂的access_token。
  • 因此，access_token的使用寿命很短（例如30分钟）。请记住，当这个access_token到期时，您将发送refresh_token到access_token0（这比access_token1非常安全）以获得新的access_token。由于您不会随时将refresh_token发送到access_token1，因此拦截access_token1的黑客不可能获得您的refresh_token。如果您作为开发人员仍然怀疑您的用户refresh_token也可能被黑客入侵，那么您可以access_token4所有用户（使refresh_token对所有用户无效），这样用户将再次登录（提供用户名和密码）以获得新的refresh_token+access_token，事情将再次走上正轨。

一些有用的资源

有和没有刷新令牌的工作流-YouTube

JWT认证代码示例-节点JS-YouTube