我正在使用OAuth Playground来更好地了解OpenID Connect流程，它对验证state参数有这样的说法：
用户已重定向回客户端，您会注意到 URL 中有一些其他查询参数：
?state=7ymOWcwttpCfDNcs&code=Tav2TPBjSNvR8aowA3oe由于攻击者可以手工创建与此类似的 GET 请求，因此攻击者可能会向应用程序提供垃圾授权代码。您需要首先验证 state 参数是否与此用户的会话匹配，以便您可以确定您发起了请求，并且只发送了用于客户端的授权代码。
基于这种解释，似乎我们使用 state 参数防止的唯一"攻击"是攻击者向我们的应用程序发送错误代码，我们根据授权服务器检查错误代码，然后被拒绝。
但是，这实际上并没有给攻击者带来太大伤害或伤害我们：我们只是向身份验证服务器发出一些额外的http请求，如果我们在状态不匹配时立即在我们的服务器上拒绝该请求，我们就不需要发出这些请求。
我的问题是：我的理解是否正确，还是我错过了state正在防止的更重要的攻击媒介？
我的问题是：我的理解是否正确
不
为什么？
OAuth 2.0 规范提供了一个关于伪造重定向可以做什么的可靠示例。首先，从定义上看，
状态： 推荐。 客户端用来维护的不透明值 请求和回调之间的状态。
状态有助于将授权请求与授权响应相关联，并防止跨站点请求伪造。认为您的客户端有一个接收响应的重定向 URL。如果恶意方使用有效的访问令牌(使用隐式流时(重定向到客户端，该怎么办？如果此访问令牌允许访问属于您使用的同一资源服务器中的恶意方的有效资源，该怎么办？OAuth 2.0 (RFC6749( 在银行账户详细信息上给出了一个很好的例子。
针对客户端重定向 URI 的 CSRF 攻击允许攻击者 注入自己的授权代码或访问令牌，这可以 导致客户端使用与 攻击者的受保护资源而不是受害者的资源(例如，保存 受害者的银行帐户信息到受保护的资源 由攻击者控制(。
状态参数可防止此类攻击。此外，我欢迎您浏览RFC6819 - 威胁模型和安全注意事项。它包括许多攻击媒介和采用OAuth 2.0时可以采取的计数器测量。它还包括有关CSRF攻击和状态使用的部分。