在实现Azure OAuth流时，我使用了state参数，Azure文档中说state参数:
包含在请求中的值，该值也在令牌响应中返回。它可以是您希望的任何内容的字符串。随机生成的唯一值通常用于防止跨站点请求伪造攻击。该值还可以编码用户在身份验证请求发生之前在应用程序中的状态信息。例如，它可以对他们所在的页面或视图进行编码。
所以，我的web应用程序已经生成这样的唯一字符串，这是一个CSRf令牌(UUID)。所以我使用相同的CSRF令牌(UUID)并传递给state参数。当响应来自OAuth提供程序时，我已经从会话中交叉了CSRF令牌。
但是，最近我公司的安全团队说CSRF令牌不应该这样使用。根据他们
CRSF令牌是一个不应该被共享的秘密。因此，使用它作为状态值是对CSRF令牌的不当使用，并引入了(小的)安全风险。
但是，如果我仔细观察其他正常(非oauth)请求，那么在请求头中传递相同的CSRF令牌，所以我问他们，如果CSRF令牌是秘密的，那么为什么它在请求头中传递，这也可能"引入(小)安全风险"。我得到的答案并不令人信服。所以在这个大论坛上问这个问题:
我们可以使用CSRF令牌作为OAuth请求中state参数的值吗?如果我们使用CSRF令牌作为state参数，是否存在安全风险?
看情况。
您可以公开使用CSRF令牌，仅如果它是使用双重提交Cookie (DSC)模式实现的。在这种情况下，正如您注意到的，令牌是在GET请求头中传递的。
但是，如果您的站点使用同步令牌模式(STP)，那么这个令牌必须保密
在您的情况下，您的公司似乎正在使用DSC模式，因此可以将其值用于state参数。作为一般规则，我认为创建一个新的秘密通常更安全，以避免基于所使用的令牌模式的潜在问题。