为什么OAuth 2.0规范会阻止授权代码的重复使用？

在OAuth 2.0规范中，有以下一组句子：

授权码必须过期 发布后不久，将降低泄漏风险。A. 授权代码的最长生存期为10分钟 推荐。客户不得使用授权代码 不止一次。如果授权码的使用次数超过 一次，授权服务器必须拒绝请求，并且应该 撤销（如果可能）以前基于 那个授权码

我的问题是为什么授权码只能使用一次？这似乎迫使授权服务器的实现者使用ACID数据库，这会带来可伸缩性问题。放松这一限制将允许完全免除存储

---

我可以看出，允许重新使用身份验证代码意味着，如果恶意代理可以获得未过期的代码，他们就可以访问受保护的资源。但是OAuth 2.0对某些事务强制使用TLS，并建议所有事务使用TLS，这降低了代码被盗的风险，并且假设有一个代理可以监听通道，这一要求引入了拒绝服务的可能性（代理可以简单地提交他们发现的任何身份验证代码）拒绝服务可能比违反保密性的威胁更大或更小，这取决于具体情况。

希望这有助于找到问题的原因： 授权过程使用两个授权服务器端点 （HTTP资源）：

o授权端点-客户端用于获取 通过用户代理重定向从资源所有者获得授权

o令牌端点-由客户端用于交换访问令牌的授权码，通常具有客户端身份验证。

也按照

客户端身份验证至关重要 将授权码传输到重定向服务器时 端点通过不安全的通道或重定向URI 没有全部登记

要实现上述目标，需要以下五个步骤

图中所示的流程包括以下步骤：

（A） 客户端通过引导资源所有者的 将用户代理添加到授权端点。客户包括 其客户端标识符、请求的作用域、本地状态和 授权服务器将向其发送请求的重定向URI 一旦授予（或拒绝）访问权限，用户代理将返回

（B） 授权服务器验证资源所有者（通过 用户代理），并确定资源所有者 授予或拒绝客户端的访问请求

（C） 假设资源所有者授予访问权限，则授权 服务器使用 先前提供的重定向URI（在请求中或在 客户注册）。重定向URI包括 授权代码和客户提供的任何当地州 早些时候

（D） 客户端从授权服务器请求访问令牌 服务器的令牌终结点，包括授权代码 在上一步中收到。在提出请求时 客户端通过授权服务器进行身份验证。客户 包括用于获取授权的重定向URI 验证代码

（E） 授权服务器验证客户端，验证 授权代码，并确保重定向URI received与中用于重定向客户端的URI匹配 步骤（C）。如果有效，授权服务器将使用

---

访问令牌和（可选）刷新令牌。

授权代码通过用户代理（如web浏览器）交付给客户端。这会造成某些威胁（例如，应用程序可能容易受到XSS或其他攻击），可能使攻击者窃取令牌。另外，OAuth 2.0库只建议使用“应该”，因此令牌可能会从传输中被盗：

授权代码的传输应通过安全的网络进行 和客户机应要求使用TLS及其 重定向URI（如果URI标识网络资源）

限制授权代码的有效性部分缓解了这些威胁，因为攻击者需要在有限的时间内执行整个攻击，并且必须成功阻止原始请求者交换代码（这将使攻击者后续的尝试无效，因为令牌已被使用）

可能的DOS攻击可以通过定期轮换客户端凭据或在可疑攻击时更改它们来缓解，因为任何想要为访问令牌交换授权代码的人在这样做时仍然需要能够提供客户端凭据（当然公共客户端除外）。这些凭证必须通过TLS呈现给授权服务器，因此攻击者可能无法以与授权代码相同的方式嗅探它们

OAuth2.0还涵盖了您的用例。若您需要能够在应用程序的整个生命周期中获得多个访问令牌，则应该使用

刷新令牌通常与同一流中的访问令牌一起发布和交付到应用程序。您可以将刷新令牌视为“具有长有效期的授权代码”。：

因为刷新令牌通常是用于 请求其他访问令牌时，刷新令牌将绑定到 向其发出该证书的客户机

当然最好将刷新令牌存储在服务器端（例如，在您声明的情况下使用ACID数据库），但是没有人可以阻止您