When implementing a Facebook server-side login, the documentation says that our server should supply a state string, which Facebook will send back to us during the callback. We can then check if the string matches, to prevent CSRF attack.
Since Rails already has a CSRF token that is unchanged during one session, is it a security risk to reuse it during Facebook or any 3rd party authorization process?
I think it might be okay, since the 3rd party does not have user's cookie, therefore the token will be useless.
I would suggest not sharing the CSRF token with 3rd party provider because you cannot know if the CSRF token will be visible to external attacker due the implementation of 3rd party provider. Note that even if you were able to verify that the CSRF token is not visible now, it might be visible in the future after 3rd party provider changes its implementation.
(If the CSRF token is visible to external attacker due to the 3rd party implementation, the attacker can get the matching CSRF token for the visitor's cookie and the launch a CSRF attack for your site. Sure, such attack will be harder than having no CRSF protection at all but you asked if it's a security risk.)
If you do not want to store additional state for the server you could create 3rd party specific CSRF value by using static 3rd party configurable secret and doing HMAC-SHA1 with the real Rails CSRF token and that secret. Use resulting hash as the 3rd party CRSF value. A slightly paranoid version could use salting plus separate secret for each 3rd party provider if you support many. The idea is to hide the real CSRF token even from 3rd parties.
I don't know how hard it will be to use custom CSRF verification for the 3rd party login process using Rails...