OAuth 2：状态是否应过期？

问题描述

对于将state参数用于OAuth协议的服务，客户端可以在协议的第1步和第3步之间维持状态：

1. 使用state
将用户从客户端重定向到服务
2. 用户同意范围
3. 使用授权码和state
将用户重定向回客户端。

是否有充分的理由为步骤1和3之间的延迟设置最大值？具体可以通过将到期日期设置为state来实现。 OAuth 2流程应该相当迅速地完成似乎是合理的（例如，在步骤1的一年后到达步骤3会很奇怪），因此，我很想在{{ 1}}。对此是否有任何安全性或功能最佳实践？如果否，则到期状态是否有明显的缺点？

解决方法

首先，state是授权请求中的推荐参数，而不是必需参数。因此它可能根本不包含在内。

state参数是客户端用来维护请求和回调之间状态的不透明值。建议使用此参数来防止CSRF攻击，请参阅section 10.12 of the Oauth2 RFC。

我从未见过该州的有效期。用户可以导航到客户端，重定向到授权服务器，然后在登录屏幕上使计算机休眠。当用户唤醒计算机时，他们可以完成登录并重定向回客户端。如果客户仍然了解状态，即使几天后，我也看不出为什么它会失败。

另一方面，颁发的授权代码的寿命有限。发行后，应在几分钟内使用，并且只能使用一次。