Is it secure to use one CSRF token multiple times?

Question

I am new to the CSRF problem and I am studying how CSRF protection is implemented in popular applications like Facebook, Instagram etc. Now I am studying how CSRF protection is used in OAuth implementation.

Some services (Instagram, Todoist) allow to pass an additional argument when an OAuth authorization URL is requested. This argument is described in Instagram:

You may provide an optional state parameter to carry through a server-specific state. For example, you can use this to protect against CSRF issues.

When I elaborated with a different code the CSRF token in form at the page where the user (dis)allows access to his account, it is the same in all requests even if I provide a different value for code. Is this OK?

Do you have an idea how they transform code into CSRF token and how is this token used for CSRF protection? Please could you explain how it works?

EDIT1

I found that one CSRF token per session is probably not a problem and generating unique token per request leads to application problem (back-button etc), source - https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet

But still I don't know how is above mentioned code parameter used or transformed into CSRF token.

Answer 1

Do you have an idea how they transform code into CSRF token and how is this token used for CSRF protection? Please could you explain how it works?

You're mixing things up in your question.

From your instagram quote:

You may provide an optional state parameter to carry through a server-specific state. For example, you can use this to protect against CSRF issues.

Notice that it's the state parameter that's used for CSRF protection, and it's independent of the code and how that's exchanged for a token.

Basically, when the app sends the user off to Instagram to perform the authorization procedure, it needs a way to ensure the user that comes back with a code is the same one and not some attacker. That's where the state parameter fits in, the authorization server will reflect whatever value is in the state parameter back to the calling app, allowing it to function as a CSRF token.

The important bit is that through the whole code part of the process, the user-agent is acting as an intermediary between the app and the authorization server. The authorization server has a code for the app, but it is given to the user who then gives it to the app.

The exchange of the code for a token is not handled through the user-agent, the state parameter is no longer needed once the app has the code because it comunicates directly with the authorization server (ideally authenticated with an API key and secured with TLS).

The code is not exchanged for a "CSRF token", the code is exchanged for an access_token that allows the app to perform operations on the protected resource (the instagram account) on behalf of the user.

The CSRF token sent in the state parameter is the "client side" of your usual CSRF token (the one you put in a hidden input field on your forms).

Since the CSRF token will (by design) be sent in GET requests, it's advisable to make them unique and not reuse them. See the Disclosure of Token in URL from the OWASP article from your edit.

Answer 2

If, for convenience, you wanted to reuse your normal CSRF token (that you use in your app for POST requests) as a CSRF token in state param for OAuth2 authentications, then the least you can do is hash it with something like SHA-256 before sending it over. This way if the callback URL does get leaked, attackers won't be able to guess your normal CSRF token and so your POST routes would still be protected. This only works if your CSRF token is truly random! But of course the leaked callback URL is compromised at this point.