OAuth "state" 是否减轻了任何真正危险的攻击？
Does OAuth "state" mitigate any genuinely dangerous attacks?
我使用 OAuth Playground 来更好地理解 OpenID Connect 流程，它对验证 state 参数有这样的说法：
The user was redirected back to the client, and you'll notice a few additional query parameters in the URL:
?state=7ymOWcwttpCfDNcs&code=Tav2TPBjSNvR8aowA3oe
Since it's possible for an attacker to craft a GET request that looks similar to this, an attacker could provide your application with junk authorization codes. You need to first verify that the state parameter matches this user's session so that you can be sure you initiated the request, and are only sending an authorization code that was intended for your client.
根据这个解释，似乎我们用状态参数阻止的唯一 "attack" 是攻击者向我们的应用程序发送错误代码，我们对照授权服务器检查错误代码，然后我们被拒绝了。
但是，这实际上并没有给攻击者带来多大的伤害，也没有给我们带来太大的伤害：我们只是向 auth 服务器发出一些额外的 http 请求，如果我们拒绝了请求，我们就不需要发出这些请求了当状态不匹配时立即在我们的服务器上。
我的问题是：我的理解是否正确，或者我是否遗漏了 state 正在阻止的更重要的攻击向量？
我的问题是：我的理解是否正确
没有
为什么？
OAuth 2.0 规范提供了一个关于伪造重定向可以做什么的可靠示例。首先，来自definition、
state : RECOMMENDED. An opaque value used by the client to maintain
state between the request and callback.
状态有助于将授权请求与授权响应关联起来，防止跨站请求伪造。认为您的客户有一个接收响应的重定向 URL。如果恶意方使用有效的访问令牌（使用隐式流时）重定向到您的客户端怎么办。如果此访问令牌允许访问属于您使用的同一资源服务器中的恶意方的有效资源，该怎么办。 OAuth 2.0 (RFC6749) give a solid example for this on bank account details.
A CSRF attack against the client's redirection URI allows an attacker
to inject its own authorization code or access token, which can
result in the client using an access token associated with the
attacker's protected resources rather than the victim's (e.g., save
the victim's bank account information to a protected resource
controlled by the attacker).
状态参数可防止此类攻击。此外，我也欢迎您阅读 RFC6819 - Threat Model and Security Considerations. It include many attack vectors and counter measurements one could take when adopting OAuth 2.0. It include a section about CSRF attack and usage of state。
我使用 OAuth Playground 来更好地理解 OpenID Connect 流程，它对验证 state 参数有这样的说法：
The user was redirected back to the client, and you'll notice a few additional query parameters in the URL:
?state=7ymOWcwttpCfDNcs&code=Tav2TPBjSNvR8aowA3oeSince it's possible for an attacker to craft a GET request that looks similar to this, an attacker could provide your application with junk authorization codes. You need to first verify that the state parameter matches this user's session so that you can be sure you initiated the request, and are only sending an authorization code that was intended for your client.
根据这个解释，似乎我们用状态参数阻止的唯一 "attack" 是攻击者向我们的应用程序发送错误代码，我们对照授权服务器检查错误代码，然后我们被拒绝了。
但是，这实际上并没有给攻击者带来多大的伤害，也没有给我们带来太大的伤害：我们只是向 auth 服务器发出一些额外的 http 请求，如果我们拒绝了请求，我们就不需要发出这些请求了当状态不匹配时立即在我们的服务器上。
我的问题是：我的理解是否正确，或者我是否遗漏了 state 正在阻止的更重要的攻击向量？
我的问题是：我的理解是否正确
没有
为什么？
OAuth 2.0 规范提供了一个关于伪造重定向可以做什么的可靠示例。首先，来自definition、
state : RECOMMENDED. An opaque value used by the client to maintain state between the request and callback.
状态有助于将授权请求与授权响应关联起来，防止跨站请求伪造。认为您的客户有一个接收响应的重定向 URL。如果恶意方使用有效的访问令牌（使用隐式流时）重定向到您的客户端怎么办。如果此访问令牌允许访问属于您使用的同一资源服务器中的恶意方的有效资源，该怎么办。 OAuth 2.0 (RFC6749) give a solid example for this on bank account details.
A CSRF attack against the client's redirection URI allows an attacker to inject its own authorization code or access token, which can result in the client using an access token associated with the attacker's protected resources rather than the victim's (e.g., save the victim's bank account information to a protected resource controlled by the attacker).
状态参数可防止此类攻击。此外，我也欢迎您阅读 RFC6819 - Threat Model and Security Considerations. It include many attack vectors and counter measurements one could take when adopting OAuth 2.0. It include a section about CSRF attack and usage of state。