在OAuth 2.0规范的Section 4.1.2中,有以下句子集:
授权码必须到期 发布后不久,以减少泄漏的风险。一个 最长授权代码的生命周期为10分钟 推荐的。客户端不得使用授权码 不止一次。如果使用的授权代码超过 一次,授权服务器必须拒绝请求,并且应该 撤销(如果可能)以前基于发行的所有令牌 授权码。
我的问题是为什么授权码只能使用一次?这似乎迫使授权服务器的实现者使用ACID数据库,这引入了可伸缩性问题。放宽这种约束可以完全省去存储。
我可以看到,允许重新使用身份验证代码意味着如果恶意代理可以获取未过期的代码,他们就可以访问受保护的资源。但OAuth 2.0要求对某些交易进行TLS并为所有人推荐TLS,这样可以降低代码被盗的风险,并且假设有一个可以在渠道上收听的代理,这个要求会引入拒绝服务的可能性(代理可以简单地提交)他们发现的任何身份验证代码。)根据具体情况,DoS可能比违反保密规定更大或更小的威胁。
答案 0 :(得分:3)
希望这有助于找到问题的原因: 授权过程使用两个授权服务器端点 (HTTP资源):
o授权端点 - 由客户端用来获取 来自资源所有者的授权通过用户代理重定向。
o令牌端点 - 由客户端用于交换授权码以获取访问令牌,通常使用客户端身份验证。 Reference
客户端身份验证至关重要 授权代码传输到重定向时 不安全通道上的端点或重定向URI具有的端点 没有完整注册。
为实现上述目标,需要遵循五个步骤
图中所示的流程包括以下步骤:
(A)客户端通过指导资源所有者来启动流程 用户代理到授权端点。客户包括 其客户端标识符,请求的范围,本地状态和a 授权服务器将发送的重定向URI 一旦访问被授予(或被拒绝),用户代理就会返回。
(B)授权服务器验证资源所有者(通过 用户代理)并确定资源所有者 授予或拒绝客户的访问请求。
(C)假设资源所有者授予访问权限,授权 服务器使用以下命令将用户代理重定向回客户端 前面提供的重定向URI(在请求中或在期间) 客户注册)。重定向URI包括 授权代码和客户端提供的任何本地状态 早。
(D)客户端从授权请求访问令牌 服务器的令牌端点,包括授权码 在上一步收到。在提出请求时, 客户端使用授权服务器进行身份验证客户端 包括用于获取授权的重定向URI 验证码。
(E)授权服务器验证客户端,验证客户端 授权代码,并确保重定向URI 收到匹配用于重定向客户端的URI 步骤(C)。如果有效,授权服务器将回复 访问令牌和(可选)刷新令牌。
答案 1 :(得分: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,完全避免服务器端存储。