我正在使用OAuth Playground来更好地理解OpenID Connect流程，并且它有关于验证state参数的内容：
用户被重定向回客户端，您会在URL中注意到一些其他查询参数：
?state=7ymOWcwttpCfDNcs&code=Tav2TPBjSNvR8aowA3oe由于攻击者有可能制作类似于此的GET请求，因此攻击者可以为您的应用程序提供垃圾授权码。您需要首先验证state参数是否与该用户的会话匹配，以便可以确保已发起请求，并且仅发送针对客户的授权代码。
基于此解释，看来我们使用state参数防止的唯一“攻击”是攻击者向其中发送我们的应用程序错误代码，然后根据授权服务器检查错误代码，然后被拒绝。
但是，这实际上并不会给攻击者带来太大的伤害，也不会给我们造成太大的伤害：我们只是向auth服务器发出了一些额外的http请求，如果我们立即拒绝了该请求，我们将不需要发出这些请求状态不匹配时的服务器。
我的问题是：我的理解正确吗，还是我错过了state正在阻止的更重要的攻击手段？
答案 0 :(得分：2)
我的问题是：我的理解正确吗
否
为什么？
OAuth 2.0规范为伪造重定向提供了一个可靠的例子。首先，从definition，
状态：推荐。客户端用来维护的不透明值 请求和回调之间的状态。
State帮助将授权请求与授权响应相关联，并防止跨站点请求伪造。认为您的客户端具有接收响应的重定向URL。如果恶意方使用有效的访问令牌（使用隐式流）重定向到您的客户端时该怎么办。如果此访问令牌允许访问有效资源，该怎么办又属于您使用的同一资源服务器中的恶意方。 OAuth 2.0 (RFC6749) give a solid example for this on bank account details。
针对客户端重定向URI的CSRF攻击允许攻击者 注入自己的授权码或访问令牌， 导致客户端使用与 攻击者受保护的资源，而不是受害者的受保护资源（例如， 受害人的银行帐户信息转移到受保护的资源 由攻击者控制）。
State参数可防止此类攻击。此外，我欢迎您阅读RFC6819 - Threat Model and Security Considerations。它包括许多采用OAuth 2.0时可能采取的攻击向量和计数器测量。它也包括有关CSRF attack and usage of state的部分。