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

Question

在 OAuth 2.0 规范的Section 4.1.2 中，有如下一组语句：

授权码必须过期 发布后不久，以减轻泄漏的风险。一种 10 分钟的最大授权代码生命周期是 推荐的。客户端不得使用授权码 不止一次。如果使用授权码超过 一次，授权服务器必须拒绝请求并且应该 撤销（在可能的情况下）之前基于 那个授权码。

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

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

Answer 1

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

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

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

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

OAuth 2.0 也涵盖了您的用例。如果您需要在应用程序的整个生命周期中获取多个访问令牌，您应该使用refresh tokens。

刷新令牌通常在同一流程中与访问令牌一起发布并交付给您的应用程序。您可以将刷新令牌视为“具有长有效期的授权码”。 The spec says:

因为刷新令牌通常是用于 请求额外的访问令牌，刷新令牌绑定到 发给它的客户。

绝对最好将刷新令牌存储在服务器端（例如，使用您所说的 ACID 数据库），但没有人可以阻止您使用例如用于此目的的安全 cookie，并完全避免服务器端存储。

Answer 2

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

o 授权端点 - 客户端用于获取 来自资源所有者的授权，通过用户代理重定向。

o 令牌端点 - 客户端用于交换授权代码以获取访问令牌，通常带有客户端身份验证。 Reference

同样根据Sec 3.2.1

客户端身份验证至关重要 当授权码被传输到重定向时 通过不安全通道或重定向 URI 具有 未完整注册。

Reference

要实现上述目标，它遵循五个步骤

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

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

(B) 授权服务器对资源所有者进行身份验证（通过 用户代理）并确定资源所有者是否 授予或拒绝客户端的访问请求。

(C) 假设资源所有者授予访问权限，则授权 服务器使用 之前提供的重定向 URI（在请求中或在 客户注册）。重定向 URI 包含一个 授权码和客户提供的任何本地状态 早一点。

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

(E) 授权服务器验证客户端，验证 授权码，并确保重定向 URI 收到的匹配用于重定向客户端的 URI 步骤 (C)。如果有效，授权服务器会回复 访问令牌和可选的刷新令牌。