为什么OAuth 2.0规范阻止重新使用授权码？

Question

在OAuth 2.0规范的Section 4.1.2，有以下一组句子：它发出来减轻泄漏的风险后

授权代码必须不久到期 。 A 10分钟的最大授权码寿命是 推荐。客户端不得多次使用授权码 。如果一次使用授权码超过 ，授权服务器必须拒绝该请求，并且应该撤销（如果可能的话）以前根据 授权该授权码的所有令牌。

我的问题是为什么只能使用授权码一次？这似乎迫使授权服务器的实施者使用ACID数据库，该数据库引入了可伸缩性问题。放松这个约束条件将允许完全放弃存储。

我可以看到，允许重新使用授权码将意味着如果恶意代理可以获得未到期代码，他们可以获得对受保护资源的访问权限。但OAuth 2.0要求TLS处理一些交易，并为所有交易推荐它，这样可以降低代码盗窃的风险，并且假设有一个代理可以监听信道，这个要求引入了拒绝服务的可能性（代理可以简单地提交他们发现的任何授权码）。根据具体情况，DoS可能比违反保密要求更大或更小。

Answer 1

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

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

ö令牌端点 - 使用的客户端与客户端认证交换授权代码访问令牌，通常。 Reference

另外，作为每Sec 3.2.1

客户机认证时的授权码被通过不安全信道或时发送到重定向 端点是临界 URI已 未登记在充分重定向。

Reference

为了实现上述它遵循五步

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

（A）客户端通过引导启动流的资源主人的 授权端点的用户代理。客户端包括 其客户端标识符，请求范围，本地状态以及授权服务器在授予（或拒绝）访问权后将向其发送 用户代理的重定向URI。 （B）授权服务器（通过 用户代理）认证资源所有者并确定资源所有者是否授予或拒绝客户端的访问请求。

（C）假设资源所有者授予访问权限，授权 服务器重定向的用户代理返回到使用 重定向URI前面提供（在请求中或在 客户端注册）的客户端。重定向URI包括一个 授权码和客户端 提供的任何本地状态。

（d）客户端通过包含在先前步骤中接收到的授权码 请求从授权服务器 的令牌端点的接入令牌。当提出请求时， 客户端向授权服务器进行认证。客户端 包括重定向URI，用于获取验证的授权代码 。

（E）授权服务器验证客户端，验证 授权码，并确保URI 接收重定向匹配URI用于将客户端重定向在 步骤（C）。如果有效，则授权服务器以 响应访问令牌，并且可选地使用刷新令牌。

Answer 2

授权码通过用户的代理（例如网络浏览器）传送到客户端。这造成了某些威胁（例如，应用程序可能容易受到XSS或其他攻击），可能使攻击者窃取令牌。此外，OAuth 2.0用户库doesn't mandate usage of SSL/TLS in communication between user agent and authorization server，它只是推荐为“应该”，那么令牌可能被从运输被盗：

的授权码的传输应该通过一个安全的 渠道进行，客户端应该要求如果URI标识网络资源，则使用TLS及其 重定向URI。

使部分受限授权码的有效性减轻这些威胁，攻击者需要在有限的时间内完成整个攻击并防止原有的请求者从交换代码必须成功（这将使所做后续尝试攻击者徒劳无益，因为令牌已被使用）。

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

OAuth 2.0还涵盖了您的使用案例。如果您需要能够在应用程序的整个生命周期中获得多个访问令牌，则应使用refresh tokens。

刷新令牌通常会与相同流中的访问令牌一起发布并传送到您的应用程序。您可以将刷新标记视为“有效期长的授权码”。 The spec says：

由于刷新令牌通常被持久用于 请求额外的访问令牌凭证，刷新令牌被绑定到客户 其所发出。

最好在服务器端存储刷新令牌（例如，在状态下使用ACID数据库），但没有人会阻止您使用例如。一个用于此目的的安全cookie，并完全避免服务器端存储。