Can I use CSRF token as value for state parameter in OAuth flow?

Question

While implementing Azure OAuth flow I have used state parameter, Azure docs says about state param:

A value included in the request that is also returned in the token response. It can be a string of any content that you wish. A randomly generated unique value is typically used for preventing cross-site request forgery attacks. The value can also encode information about the user's state in the app before the authentication request occurred. For instance, it could encode the page or view they were on.

So, My web application is already generating such unique string and that is a CSRf token (UUID). So I used the same CSRF token (UUID) and passed to state parameter. When response comes from OAuth provider I have crossed with the CSRF token from session.

But, recently security team in my company said CSRF token should not used in this way. According to them

A CRSF token is a secret that should not be shared. Using it as a state value is therefore improper use of the CSRF token and introduces a (small) security risk.

But, if I look closely at other normal (non-Oauth) requests then the same CSRF token is passed in request header, so I asked them that if CSRF token is secret then why it is being passed in request header that could also "introduces a (small) security risk." the answer I received is not convincing. Hence asking this question on this large forum:

Can we use CSRF token as a value for state parameter in OAuth request? Is there any security risk involve if we use CSRF token as state parameter?

Gymnastics

If I don't understand why this would be a security risk (which I don't in your case) I would ask the security team to describe a possible attack that is enabled by it. – Consumerism

@HeikoTheißen Yes, I did asked this question and answer was, in this case CSRF token is being exposed in query parameter which is not recommended, malicious users can steal this token and perform CSRF for other non-oauth requests as I am using the same token. Their say is for OAuth request separate UUID should be generated,used and disposed once it's work is done. – Gymnastics

CSRF tokens are not a measure against malicious users, but against victimised users. They offer a protection for the user against themselves, you might say. Malicious users can always ignore that. I do not yet see the possible attack here. – Consumerism

Answer 1

It depends.

You can use the CSRF token publicly only if it has been implemented using the Double Submit Cookie (DSC) pattern. In this case, as you note, the token is passed in GET request headers.

However, if your site uses the Synchronizer Token Pattern (STP), then this token must be kept secret at all times.

In your situation, your company seems to be using the DSC pattern so it is fine to use its value for the state parameter. As a general rule though, I would say it is generally safer to create a new secret to avoid the potential issue based on the token pattern used.

Thesda