不确定什么样的CSRF攻击会阻止＆＃34;状态＆＃34; OpenID Connect服务器流中的参数。有人可以举个例子吗？
答案 0 :(得分：6)
它可以防止攻击者产生虚假身份验证响应的攻击，例如：通过向客户端的重定向URI发送code作为基本客户端配置文件的一部分。例如：在对用户进行网络钓鱼之后，攻击者可能会以这种方式注入与当前用户关联的被盗code。 state会关联请求和响应，因此如果不知道请求中使用的state参数，则无法主动制作响应。
答案 1 :(得分：5)
通过比较授权请求和响应的state值，我们的想法是验证授权响应是否与请求相关。
到目前为止一切顺利;但是什么阻止对手使用来自良性用户的被盗授权代码伪造授权响应？ OpenID客户端无法验证授权代码是否与state值相关联。恕我直言，最好在授权请求中使用nonce字段，因为一旦授权代码被交换，这将在签名的id_token内回显。现在，OpenID客户端可以明确地将id_token（授权证明）与授权请求相关联。
这样，我们可以缓解CSRF和重播攻击。或者我在这里忽略了什么？
老实说，我有点困惑为什么OpenID Connect specs＆＃34;推荐＆＃34;使用state但保留nonce可选。
答案 2 :(得分：2)
该建议来自OAuth2，并且遵循该建议会阻止支持“ IdP发起”流程的功能。
OIDC完全是关于SSO进入RP（依赖方； AKA“客户端”）系统的原因，因为它们已在IdP（身份提供商； AKA“ Provider”）系统中进行了身份验证-并且存在一些后端信任设置在两个系统之间。
因此，您有一个“身份验证请求”。这是从RP到IdP的重定向；网址的查询字符串中包含“ scope = openid”。然后，您将获得“身份验证响应”；网址的查询字符串中包含“ code = XXXXX”。在这些GET请求的两者中，浏览器/最终用户在RP看来是匿名。只有在RP验证了后端的“代码”之后，RP才会向浏览器分配身份（身份验证）。
这意味着可以使用仅方式State来尝试防止CSRF是RP的应用程序在浏览器中存储该State值以唯一标识它。然后，当浏览器使用代码和状态进入RP时，可以确保浏览器先前曾尝试过身份验证请求。但是，RP不能保证本守则来自特定的要求；状态可以在该浏览器的上下文中重播。
这还意味着，代替使用State，RP可以通过检查HTTP“ Referrer”标头指示“身份验证响应”来自预期的IdP来减轻CSRF攻击。
以这种方式使用State有什么好处？
您缓解的唯一实际攻击媒介是使人A使用人B的密码登录SiteX而不是他们自己的密码的可能性。换句话说，从理论上讲，Alice可以让Bob跟随链接并以自己的身份登录Bob。
据我所知，在这一点上，您要么在iFrame中运行了OIDC交换-攻击者已经找到了某种方法来利用它-或您在浏览器的“同源策略”（也许CORS放宽了太多？）。在这两种情况下，与攻击者在这种情况下可能执行的其他操作相比，该攻击向量似乎都很少。哦，如果您遇到“跟随链接并删除数据”的情况，则与CSRF无关。站点如何实施以处理“深层链接”（即保留未经身份验证的请求的状态，以便在成功通过身份验证后稍后重播，这是最终用户的便利），这完全是一个问题。
以这种方式使用State会给您带来什么损失？
您不能支持由IdP发起的SSO。当浏览器/最终用户已经在IdP上并且想要SSO进入RP时，该IdP将无法在单个重定向中完成 。解决方案/解决方案必须涉及浏览器点击RP，然后返回IdP，然后最后再次返回RP。