基本上，刷新令牌用于获取新的访问令牌。

为了明确区分这两个令牌并避免混淆，以下是OAuth 2.0授权框架中给出的它们的函数：

• 访问令牌**由授权服务器在资源所有者批准后颁发给第三方客户端。客户端使用访问令牌来访问资源服务器托管的受保护资源。
• 刷新令牌**是用于获取访问令牌的凭据。刷新令牌由授权服务器颁发给客户端，用于在当前访问令牌无效或过期时获取新的访问令牌，或者用于获取具有相同或更窄范围的附加访问令牌。

现在，为了回答您为什么仍然获得刷新令牌而不仅仅是保护访问令牌的问题，互联网工程任务组在Refresh tokens中提供的主要原因是：

存在安全原因，refresh_token仅与授权服务器交换，而access_token与资源服务器交换。这降低了长时间的ACCESS_TOKEN泄漏的风险，该风险是在“访问令牌有效期为一小时，刷新令牌有效期为一年或有效期直至撤销”与“没有刷新令牌的访问令牌有效期直至撤销”中泄漏的。

有关OAuth 2.0流程的更详细、更完整的信息，请尝试查看以下参考资料：

• OAuth 2.0 Flow: Server-side web apps
• 互联网工程任务组(IETF)发布的The OAuth 2.0 Authorization Framework
• 所以在Why Does OAuth v2 Have Both Access and Refresh Tokens?之后

刷新令牌至少用于两个目的。首先，刷新令牌是一种证明，表明OAuth2客户端已经从用户那里获得了访问其数据的许可，因此可以再次请求新的访问令牌，而不需要用户经历整个OAuth2流。其次，与寿命较长的访问令牌相比，它有助于提高整个安全流。我将更详细地谈到这两点。

刷新令牌，不惹恼用户

让我们用一个例子来谈谈第一个目的。假设您是一名用户，正在使用第三方客户端Web应用程序，该应用程序想要与您的YouTube帐户数据交互。一旦你授予客户端应用程序使用你的YouTube数据的权限，你想让客户端应用程序在其YouTube令牌到期时再次提示你许可吗？如果YouTube令牌过期时间非常短，比如5分钟，会发生什么情况？让客户端应用程序至少每隔5分钟提示您一次许可，这会让人有点恼火！OAuth2针对这个“问题”提出的解决方案是刷新令牌。通过使用刷新令牌，访问令牌可以保持短期(在访问令牌以某种方式泄露或被盗的情况下是可取的)，而刷新令牌可以保持较长的(呃)生命期，从而允许客户端在新的访问令牌到期时获得新的访问令牌，而不需要(再次)用户的许可。

但为什么是刷新令牌呢？如果重点是不用权限请求来窃听用户，那么为什么客户端不能简单地说“嘿，授权服务器，我想要另一个访问令牌。现在！”或者，“嘿，授权服务器，这是我过期的令牌，给我一个新的！”刷新令牌充当了一种“证据”，证明客户端在某个原始时间点被用户授予了访问权限。该“证据”的形式是由授权服务器对刷新令牌进行数字签名。通过客户端提供刷新令牌，授权服务器可以验证客户端在过去的某个时刻从用户接收了许可，并且客户端不必再次提示用户。

刷新令牌提高安全性

然而，这引发了一个问题，“那么，如果刷新令牌被泄露或被盗，或者只是由恶意的客户端应用程序保存，而该应用程序并没有应用户的请求将其删除，会发生什么？难道攻击者不能继续使用刷新令牌来无限期地(或直到其过期)获得有效的访问令牌吗？这个问题导致讨论我提到的第二个目的，即有助于更安全的流的刷新令牌。

访问令牌产生的问题是，一旦获得，它们只会呈现给资源服务器(例如YouTube)。那么，如果访问令牌被盗或泄露，如何告诉资源服务器不要信任该令牌呢？嗯，你真的不能。要做到这一点，唯一的方法是更改授权服务器上的私有签名密钥(最初签署令牌的密钥)。我想这不太方便，而且在某些情况下(如Auth0)不受支持。

另一方面，刷新令牌需要频繁地呈现给授权服务器，因此如果一个令牌被泄露，那么作为一个整体撤销或拒绝刷新令牌是微不足道的，并且不必更改任何签名密钥。

@Teyam提及所以发布为什么OAuth v2既有访问令牌又有刷新令牌？但我更喜欢另一个答案：https://stackoverflow.com/a/12885823/254109

tl；drrefresh_token不会带来更高的安全性。它的目的是提高可伸缩性和性能。然后，access_token可以仅存储在一些快速的临时存储装置(如存储器)中。它还允许授权和资源服务器分离。

以下是OAuth 2.0 documentation的信息。

刷新令牌用于在当前访问令牌无效或过期时获取新的访问令牌，或者用于获取具有相同或更窄范围的其他访问令牌(访问令牌的生命周期可能更短，权限可能比资源所有者授权的更少)。

+--------+                                           +---------------+
  |        |--(A)------- Authorization Grant --------->|               |
  |        |                                           |               |
  |        |<-(B)----------- Access Token -------------|               |
  |        |               & Refresh Token             |               |
  |        |                                           |               |
  |        |                            +----------+   |               |
  |        |--(C)---- Access Token ---->|          |   |               |
  |        |                            |          |   |               |
  |        |<-(D)- Protected Resource --| Resource |   | Authorization |
  | Client |                            |  Server  |   |     Server    |
  |        |--(E)---- Access Token ---->|          |   |               |
  |        |                            |          |   |               |
  |        |<-(F)- Invalid Token Error -|          |   |               |
  |        |                            +----------+   |               |
  |        |                                           |               |
  |        |--(G)----------- Refresh Token ----------->|               |
  |        |                                           |               |
  |        |<-(H)----------- Access Token -------------|               |
  +--------+           & Optional Refresh Token        +---------------+

(A)客户端通过向授权服务器认证并提供授权授予来请求访问令牌。

(B)授权服务器认证客户端并验证授权授权，并且如果有效，则发布访问令牌和刷新令牌。

(C)客户端通过提交访问令牌向资源服务器发出受保护资源请求。

(D)资源服务器验证访问令牌，如果有效，则服务于该请求。

(E)重复步骤(C)和(D)，直到访问令牌到期。如果客户端知道访问令牌过期，它跳到步骤(G)；否则，它发出另一个受保护的资源请求。

(F)由于访问令牌无效，资源服务器返回无效令牌错误。

(G)客户端通过向授权服务器认证并提供刷新令牌来请求新的访问令牌。客户端身份验证要求基于客户端类型和授权服务器策略。

(H)授权服务器认证客户端并验证刷新令牌，并且如果有效，则发布新的访问令牌(并且可选地，发布新的刷新令牌)。

“因此，我不认为这比从一开始就给我一个访问令牌，而不用担心整个更新令牌系统更安全。”我纠结于同样的问题。简而言之，刷新令牌是确保凭据未过期所必需的。

举个例子可能会有帮助：我有一个存储你的医疗记录的数据库。您同意与您的配偶共享您的医疗记录。您的配偶使用他们的访问令牌从我的数据库中读取您的记录。两周后，您的配偶将再次检查您的医疗记录，刷新令牌用于确保他们仍有权(从身份验证服务器)查看您的记录。刷新令牌不需要您的配偶向身份验证服务器重新输入他们的凭据(用户名和密码)，但它确实确保了他们仍然具有访问资源的合法性。永不过期的访问令牌不会知道您是否已经取消了配偶访问您的医疗记录的权利。

E1d0d1使用频率更高，而且撤销能力并不是很重要，因为它们的寿命很短。

E1d1d1使用频率较低，撤销能力至关重要，因为它们可用于生成新的e1d2d1。

验证签名令牌的成本较低，但很难撤消。

验证存储在数据库中的令牌成本很高，但很容易被撤销。

因此，签名密钥可以用作access_token以提高性能。

DB存储的密钥可以用作refresh_token，以便于撤销它们。

如果没有refresh_token，就很难找到一种提供低成本验证和容易撤销能力的机制。因此，refresh_token的存在是由于性能原因。

仅使用访问令牌比同时使用访问令牌和刷新令牌风险更大。

例如，您只使用了访问令牌设置**“100天”到期日期**，但有一天，访问令牌被黑客窃取。现在，黑客有很大的机会将访问令牌免费使用100天作为最大值用于不良目的。

现在，您同时使用访问令牌设置**“60分钟”到期日期和刷新令牌设置“100天”到期日期**，但有一天访问令牌被黑客窃取。现在，黑客自由使用访问令牌60分钟的机会要小得多，因为这是最大限度地用于不良目的。*

现在，您会想，如果刷新令牌被盗了。实际上，如果刷新令牌被黑客窃取，黑客仍有*大概率将刷新令牌免费使用100天用于不良目的。*但刷新令牌被盗的概率远低于访问令牌被盗的概率，因为刷新令牌每60分钟才使用一次来刷新访问令牌(获取新的访问令牌)，而访问令牌被使用的频率要高得多。

因此，最好同时使用访问令牌和刷新令牌。

访问令牌寿命较短和刷新令牌寿命较长至少有3个相关原因。

持有者令牌

由原质询引述如下：
如果我有刷新令牌，我总是可以使用它来获取新的访问令牌，因为它永远不会过期。

尽管您可能总是能够使用刷新令牌获得新的访问令牌，但攻击者通常不能。这是因为您对刷新令牌的使用与您作为客户端的身份的一些证明相结合，例如，通过提供您的CLIENT_SECRET。接入令牌不需要这样的证明，这是持有者令牌，即简单地出示它们就足够了。

让访问令牌是短暂的在某种程度上减轻了访问令牌的这种本来是无限的力量。

攻击面

访问令牌与(可能有多个)资源服务器交换，这增加了泄漏的可能性。刷新令牌仅与授权服务器交换。

同样，访问令牌的短命至少是某种程度的缓解。

吊销

将访问令牌实现为签名的JWT是可能的(也是常见的)。在这种情况下，任何服务器(知道签名方的公钥，通常位于某个众所周知的位置)都可以独立地验证访问令牌的正确性。这允许很好地分离体系结构，从这个意义上讲，资源服务器不必向授权服务器询问授权。

这种设置的缺点是这样的令牌不能被撤销(没有像撤销授权服务器的公钥那样严重的事情)。

通过使访问令牌具有短暂的生命期，可以简单地允许它们用完，而不是显式地撤销。

访问令牌寿命短。一旦到期，您需要一个新的访问令牌来访问受保护的资源。获取新的访问令牌的一种方法是再次对资源所有者进行身份验证，并获得授权授权，然后获得访问令牌。然而，这将是恼人的。

这个问题可以通过刷新令牌来解决。它的寿命很长。因此您可以使用它来获取新的访问令牌，而无需与资源所有者交互。

那么，你可能会想，拥有寿命长的令牌来获得另一个寿命短的密钥有什么意义。那么，即使刷新令牌被攻破，攻击者也不能仅仅从它那里获得访问令牌。原因是攻击者需要客户端凭据以及该刷新令牌。

因此，访问令牌的生命周期较短(其原因可在其他答案中找到)，以提高安全性。为了避免资源所有者在访问令牌到期时感到烦人，OAuth使用刷新令牌。

这是一次很好的学习体验，对令牌、刷新令牌和缓存有了一些了解。然而，(我很好奇，在这里我不给任何建议)我们可以使用代码，它在用户登录后返回使用Microsoft Identity Platform。我们是否可以只存储CodeIdToken，并在需要时使用它来获取新的访问令牌？因为我在想，我们使用它来获取访问令牌，那么我们是否应该每次都使用它来重新生成访问令牌？

...
 ResponseType = OpenIdConnectResponseType.CodeIdToken,
...

和

private async Task OnAuthorizationCodeReceived(AuthorizationCodeReceivedNotification context)
    {
        IConfidentialClientApplication clientApp = MsalAppBuilder.BuildConfidentialClientApplication();
        AuthenticationResult result = await clientApp.AcquireTokenByAuthorizationCode(new[] { "User.Read" }, context.Code)
          .ExecuteAsync();
    }

refresh_token模式使OAuth服务器处于控制之中，因此服务器可以在access_token和refresh_token泄漏等“坏”情况发生时进行干预。

例如：

如果access_token和refresh_token落入黑客手中，access_token将很快到期，黑客可能会尝试刷新令牌，但服务器现在有能力/控制不再发出access_token(考虑到服务器获得了泄漏的信息)。