在 StackOverflow 上的一个问题的评论中，OAuth2 为什么访问令牌会过期？，人们质疑刷新令牌的安全性。
这条评论是我的感受：
所以它提供了一些防止数据包嗅探的保护，只要拦截只捕获普通数据请求（Chuck 只获取访问令牌）？听起来有点弱；黑帽只需要等待一段时间，直到用户请求新的访问令牌，然后他将获得客户端 ID、秘密和刷新令牌。
我们是否都遗漏了某些东西或将我们的恐惧建立在不正确的理解之上？
或者，短期访问令牌和刷新令牌的安全性是否基于在“不太可能”发生刷新时嗅探器运行的假设概率是否正确。
访问令牌可能最终会通过普通 HTTP 连接在应用程序周围使用。因此，如果攻击者嗅到它，他们将只有短期访问权限。这是过去在网络上发生的标准。如果幸运的话，登录是通过 HTTPS 进行的，而会话的其余部分是通过纯 HTTP 进行的，以明文形式传输会话 ID。
刷新令牌仅传输到授权服务器，因此仅强制执行 HTTPS 更容易，这意味着攻击者无法窃听此连接。
出于安全原因，refresh_token 只与授权服务器交换，而 access_token 与资源服务器交换。这降低了长期 access_token 泄漏的风险（不安全资源服务器上的日志文件中的查询参数、测试版或编码不佳的资源服务器应用程序、将 access_token 放入 cookie 的非 https 站点上的 JS SDK 客户端等）在“一个小时有效的访问令牌，具有一年有效的刷新令牌或在撤销之前有效”与“在没有刷新令牌的情况下有效直到撤销的访问令牌”。
让我们考虑有一个服务器可以验证并向客户端颁发令牌。
客户端 （发送用户名和密码）-> 服务器
服务器 （验证凭据并返回访问和刷新令牌） ->客户端
客户端安全地存储令牌并将访问令牌用于对服务器进行的进一步 API 调用（直到访问令牌过期）。一旦访问令牌过期，客户端可能会收到来自服务器的 401（未授权）HTTP 代码，并意识到访问令牌不再有效。
然后，客户端使用其刷新令牌并从服务器获取新的访问和刷新令牌。
访问令牌受损的影响- 攻击者将能够访问数据，直到访问令牌过期。
受损刷新令牌的影响- 攻击者可能能够获得新的访问和刷新令牌，这也可能使受害者的访问无效。当受害者尝试使用他们的刷新令牌获取新的访问令牌时，它将失败，因为他们的刷新令牌已被使用。受害者必须使用他们的凭据再次登录，这将重新颁发令牌并使攻击者窃取的令牌无效。
我回答了一个类似的问题，该问题最终被标记为与此问题重复。但是，我觉得我对这个问题的回答为刷新令牌如何提供额外的安全性提供了更有力的论据。简而言之，如果刷新令牌被泄露，则更容易检测到它并采取适当的措施，例如禁用身份验证令牌和刷新令牌，并强制用户使用其凭据再次登录。换句话说，在使用刷新令牌时，可以更快地关闭受损凭据。
除了公认的身份验证提供者的答案通常是与资源提供者不同的服务器（因此可能不需要资源提供者的 HTTPS），即使在它们都是使用 HTTPS 的同一服务器的情况下，最好有一个短期访问令牌和长期刷新令牌。
想一想：有多少地方处理刷新令牌？在客户端或浏览器上，它应该位于查找当前访问令牌的中心位置，如果该令牌已过期或请求失败，请改用刷新令牌（通常，如果您的服务提供 SDK，这是该 SDK 可以针对潜在的安全漏洞进行大量审查）。在身份验证提供程序上，它只在处理 refresh_token 授权类型的代码路径中处理。如果您想证明刷新令牌永远不会发送到日志文件或发送到外部存储库，那么它是一个非常小的且易于管理的代码集合，您需要仔细查看以验证这一点。
相反，访问令牌希望只在客户端的一个地方（再次）使用，但在资源提供者的任何地方使用。进入您的应用程序的每个 HTTP 请求都有 Authorization 标头中的标头。如果您想证明访问令牌从未放入日志文件，并且没有人放入恶意代码将您的访问令牌导出到https://myaccesstokenfarm.example.com，那么这是一个非常大的（边界在某些代码库中是不可能的）任务。
这里的一般安全原则是减少攻击面。刷新令牌可以像访问令牌一样从中间人攻击中提取，但是通过将攻击面限制在一台服务器上的一个 URL 并且只有一个执行代码路径，它更容易做到尽你所能确保特定资源的安全。
举个例子，如果你打开了 HTTPS 压缩，你的 API 可能容易受到 BREACH 攻击；但是您希望压缩以提高效率，因此您可以接受这种可能性。但是，在您的授权端点上，您关闭压缩并采取额外步骤以确保有多层防御已知攻击。