OAuth 2.0“状态”和OpenID“立即”参数之间的区别？为什么状态不能重用？

Question 1

OAuth 2.0定义了客户端应在请求中发送的“状态”参数，以防止跨站点请求攻击。在OpenID规范中提到“ nonce”。除了以ID令牌而不是查询参数返回“ nonce”这一事实外，它们似乎具有完全相同的目的。如果有人可以解释为什么他们分开

Question 2

国家和现时似乎是相似的。但是，如果您深入研究，您会发现它们具有不同的用途。

有状态可以保护最终用户免受跨站点请求伪造（CSRF）攻击。它是从OAuth 2.0协议RFC6749引入的。协议指出，

一旦从最终用户获得授权，授权服务器就会使用“状态” 参数中包含的所需绑定值将最终用户的用户代理重定向回客户端。绑定值使客户端可以通过将绑定值与用户代理的身份验证状态进行匹配来验证请求的有效性

这用于授权请求中。它使客户端能够验证授权响应没有被原始服务器auth更改和发送。请求已发送。简而言之，它允许客户端交叉检查授权请求和响应。

（详细说明：要接受授权代码响应，客户端需要接受来自授权服务器的响应（例如：在Web应用中，这可以通过重定向和将表单发布到后端来完成）。这意味着，我们的客户端应用具有一个开放的端点并接受请求。State参数通过将原始授权请求绑定到响应来保护此端点。这是CSRF保护。）

Nonce具有不同的目的。它将令牌与客户端绑定。它用作令牌验证参数，由OpenID Connect规范引入。

nonce-用于将客户端会话与ID令牌相关联并减轻重放攻击的字符串值。该值将未经修改地从身份验证请求传递到ID令牌。如果在ID令牌中存在，则客户端必须验证随机数声明值等于在身份验证请求中发送的随机数参数的值。如果在认证请求中存在，授权服务器必须在ID令牌中包括一个随机数声明，该声明值是在认证请求中发送的随机数值。授权服务器不应对所使用的随机数进行任何其他处理。随机数值是区分大小写的字符串

如您所见，nonce值源自授权请求，并且由客户端生成。并且如果包括现时，它将出现在令牌中。因此，客户端可以针对初始授权请求验证收到的令牌，从而确保令牌的有效性。

同样，根据流类型，随机数可以是必选参数。隐式流和混合流要求随机数值。这两个值都是由客户端应用程序生成和验证的。

为什么状态不能重用？

如果捕获到授权请求，则恶意方可以伪造授权响应。可以通过更改状态参数来避免这种情况。

Question 3

Nonce向浏览器回答了这个问题：这个ID令牌是否响应了我的初始请求？

请说明后端服务器的答案：同意真的来自我认为是谁吗？

因此，他们回答的问题类似，但针对的是不同的实体。

Question 4

我要说明他们的RFC。解释非常简单。

州

     An opaque value used by the client to maintain state between the request and callback.  The authorization server includes this value when redirecting the user-agent back to the client.  The parameter SHOULD be used for preventing
     cross-site request forgery

随机数

     The nonce parameter value needs to include per-session state and be unguessable 
     to attackers. One method to achieve this for Web Server Clients is to store a 
     cryptographically random value as an HttpOnly session cookie and use a 
     cryptographic hash of the value as the nonce parameter. In that case, the nonce 
     in the returned ID Token is compared to the hash of the session cookie to detect 
     ID Token replay by third parties. A related method applicable to JavaScript 
     Clients is to store the cryptographically random value in HTML5 local storage 
     and use a cryptographic hash of this value.

希望这能回答您的问题。

Question 5

除了以上针对state和的安全性方面的答案外nonce，如果您要实现自己的三足式OAuth2工作流程（客户端，中间件和诸如Facebook之类的联合身份提供者），则中间件有时可能需要一些上下文。例如，当来自FIP的响应在返回客户之前先回到中间件时，您可能需要更多地了解原始请求的详细信息（即，对FIP的原始请求）。由于您的中间件很可能是无状态的，因此如果没有任何帮助，它将无法回答该问题。那就是OAuth2的所在state您可以存储表示要在所有OAuth2跳转之间传递的状态的任何字符串，以便中间件（以及客户端）可以使用更多上下文。对于您的客户端，出于安全原因使用此密码。将nonce被用作OIDC规范纯安全原因的一部分。