Refresh Token是什么？

出于安全目的，访问令牌的有效期可能很短。 一旦过期，客户端应用程序就可以使用刷新令牌来 "刷新 "访问令牌。 也就是说，刷新令牌是一种凭证工件，可让客户端应用程序获得新的访问令牌，而无需要求用户再次登录。
image

在上图中，SPA = Single-Page Application(单页面应用程序)；AS = Authorization Server(授权服务器)；RS = Resource Server(资源服务器)；AT = Access Token(访问令牌)；RT = Refresh Token(刷新令牌)。

只要刷新令牌有效且未过期，客户端应用程序就能获得新的访问令牌。 因此，寿命很长的刷新令牌理论上可以给令牌持有者无限的权力，让他随时获取新的访问令牌，访问受保护的资源。 刷新令牌的持有者可能是合法用户，也可能是恶意用户。 因此，Auth0 等安全公司创建了各种机制，以确保这种功能强大的令牌主要由目标方持有并持续使用。

什么时候使用Refresh Tokens

重要的是要记住，OAuth 2.0 规范定义了访问令牌和刷新令牌。 因此，如果我们要讨论其他身份协议或框架（如 SAML）的授权策略，我们就不会有访问令牌或刷新令牌的概念。
对于从事网络开发的人来说，访问令牌和刷新令牌是常谈的话题，因为网络通过 OAuth 2.0 框架和 OpenID Connect 协议广泛使用基于令牌的授权和身份验证。
OAuth 2.0 和 OIDC 结合在一起，带来了一系列授权和身份验证流程。 每个流程都有自己的优点和注意事项，这些优点和注意事项定义了我们应该使用访问和刷新令牌的最佳场景和架构。

如果有相应的应用程序，也会有相应的流程！
请记住，根据规范，在使用隐式流程时，授权服务器不应签发刷新令牌。 隐式流程通常在单页面应用程序（SPA）中实施，单页面应用程序在系统架构的前端层运行。
使用带有验证码交换密钥（PKCE）的授权代码流可以降低隐式流固有的许多风险。 例如，在使用隐式授予类型时，访问令牌是在 URI 片段中传输的，这可能会将其暴露给未授权方。 您可以阅读规范中的 "在隐式流程中滥用访问令牌冒充资源所有者 "部分，了解有关这些漏洞的更多信息。
不过，在您的应用程序中实施 PKCE 仍然不会影响刷新令牌的安全性。
不过，可能并不需要刷新令牌。
在某些情况下，您仍然可以获得访问令牌，而无需中断用户，也无需依赖刷新令牌的强大功能。 保持会话的其他方法包括 cookie 或静默身份验证。
然而，每天有数十亿人使用 SPA。 为用户提供兼顾安全性和便利性的用户体验非常重要。 有没有什么办法能让 SPA 以风险更小、更安全的方式享受刷新令牌带来的便利呢？
当然有！
提供刷新令牌轮换功能的身份验证平台可以接受在单页面应用程序中使用刷新令牌。 规范强调，如果无法验证刷新令牌是否属于某个客户端（如 SPA），除非刷新令牌已轮换到位，否则不应使用刷新令牌。 让我们在下一节中进一步了解这一安全策略。

保证Refresh Tokens的安全

短期访问令牌有助于提高应用程序的安全性，但它也有代价：过期后，用户需要再次登录才能获得新的访问令牌。 频繁的重新认证会降低应用程序的用户体验。 即使您这样做是为了保护他们的数据，用户也可能会觉得您的服务令人沮丧或难以使用。
刷新令牌可以帮助您在安全性和可用性之间取得平衡。 由于刷新令牌的寿命通常较长，因此在寿命较短的访问令牌过期后，您可以使用它们来申请新的访问令牌。
不过，由于刷新令牌也是不记名令牌，因此我们需要制定策略，在它们被泄漏或泄露时限制或减少它们的使用。 所有持有刷新令牌的人都有权随时获得新的访问令牌。
在 Auth0，我们创建了一系列功能，通过对刷新令牌的生命周期实施保障和控制，降低了与使用刷新令牌相关的风险。 我们的身份识别平台提供刷新令牌轮换功能，同时还具有自动重复使用检测功能。
让我们深入探讨一下这项安全技术。

Refresh Token轮换

直到最近，一种帮助 SPA 维护用户会话的强大策略是将授权代码流（Authorization Code Flow）与 PKCE 和静默身份验证结合使用。 刷新令牌轮换是一种使用刷新令牌获取新访问令牌的技术，它超越了静默身份验证。
刷新令牌轮换可确保应用程序每次交换刷新令牌以获取新访问令牌时，也会返回一个新的刷新令牌。 因此，如果刷新令牌被泄露，就不会再有一个长期存在的刷新令牌，可以提供对资源的非法访问。
例如，在 Auth0 控制面板中启用刷新令牌轮换后，每次应用程序交换刷新令牌以获得新的访问令牌时，授权服务器也会返回新的刷新-访问令牌对，从而降低了非法访问的威胁。 这种保护措施可帮助您的应用程序减少因令牌受损而导致的重放攻击。

Refresh Token自动重复使用检测

刷新令牌是不记名令牌。 当收到新的访问令牌请求时，授权服务器不可能知道谁是合法用户或恶意用户。
如果合法用户和恶意用户之间存在竞争条件，我们该如何处理？ 例如：

你认为接下来会发生什么？ 恶意用户会设法获得新的访问令牌吗？ 这就是身份识别平台具有🤖 自动重用功能时会发生的情况。
检测：

当以前使用过的刷新令牌被发送到授权服务器时，最近签发的刷新令牌必须立即失效。
无论合法用户还是恶意用户能否在对方之前用 🔄刷新令牌 1 交换新的刷新-访问令牌对，这种保护机制都能起作用。 如果不执行发送者约束，授权服务器就无法知道在发生重放攻击时哪个行为者是合法的，哪个是恶意的。
自动重用检测是刷新令牌轮换策略的关键组成部分。 服务器已经使已经使用过的刷新令牌失效。 不过，由于授权服务器无法知道合法用户是否持有最新的刷新令牌，为了安全起见，它会使整个令牌系列失效。

刷新令牌帮助我们拥抱隐私工具

隐私是我们数字世界的热门话题。 我们不仅需要在安全性和便利性之间取得平衡，还需要在平衡的基础上增加隐私保护。
浏览器隐私保护技术的最新发展，如智能跟踪防护（ITP），可以防止访问会话 cookie，要求用户重新认证。
浏览器中没有持久存储机制可以确保只有目标应用程序才能访问。 因此，长寿命刷新令牌并不适合 SPA，因为恶意用户可能会利用漏洞获取这些高价值的人工制品，从而访问受保护的资源。
由于刷新令牌的轮换并不依赖于对 Auth0 会话 cookie 的访问，因此不会受到 ITP 或类似机制的影响。
不过，刷新令牌的寿命可能会受到访问令牌寿命的限制。 这意味着我们可以安全地使用刷新令牌来配合浏览器隐私工具，并在不影响用户体验的情况下为终端用户提供持续访问。

可以将刷新令牌存储在本地存储中

是的，你没看错。 当刷新令牌轮换到位后，我们可以将令牌存储在本地存储或浏览器内存中。 您以前可能听说过（也许是我们说的），我们不应该将令牌存储在本地存储中。

将令牌存储在浏览器本地存储中可以在刷新页面和浏览器标签页时保持持久性；但是，如果恶意用户使用跨站脚本 (XSS) 攻击在 SPA 中运行 JavaScript，他们就可以检索存储在本地存储中的令牌。 导致 XSS 攻击成功的漏洞可能存在于 SPA 源代码或应用程序使用的任何第三方 JavaScript 代码中，例如 Bootstrap 或 Google Analytics。

不过，我们可以缩短令牌的绝对令牌过期时间，以降低在本地存储中存储令牌的安全风险。 这可以降低反射 XSS 攻击的影响（但不能降低持久性攻击的影响）。 通过配置，刷新令牌的寿命可能很长。 但是，刷新令牌的轮换会缩短刷新令牌的使用寿命。 刷新只在访问令牌的有效期内有效，而访问令牌的有效期很短。