Help with CSRF on Rodauth + Omniauth - API Only (Secure cookie)

[AlexeyMatskevich]

Greetings! I've set up a new application using the latest versions of everything. In the context of my question, I've configured Rails, Rodauth-rails, and Rodauth-omniauth. (I once implemented Argon2 integration in Rodauth and migration mechanisms and was pleasantly surprised by the integration in Rodauth-rails—thanks to the author!)

In our application, we don’t plan to use multiple domains, so we intend to use cookies for user identification. As I understand, this is well-supported by Omniauth itself and, seemingly, also by Rodauth and Rodauth-rails, though I might be mistaken. Ideally, I would like to enable CSRF protection to generally reduce the potential risks associated with using cookies.

I’ve seen there is a guide for using Omniauth in JSON (i.e., API) mode and saw mentions of built-in CSRF protection without using an external gem. However, I couldn’t find any information in the documentation or discussions on how to use CSRF protection in API mode.

In a discussion similar to this one link, I encountered the following error:

Started GET "/auth/github/callback?code=...&state=..." for 127.0.0.1 at 2024-10-31 23:28:28 +0500
  ActiveRecord::SchemaMigration Load (1.2ms)  SELECT "schema_migrations"."version" FROM "schema_migrations" ORDER BY "schema_migrations"."version" ASC /*application='RailsBackend'*/
D, [2024-10-31T23:28:28.653328 #3049637] DEBUG -- omniauth: (github) Setup endpoint detected, running now.
D, [2024-10-31T23:28:28.653372 #3049637] DEBUG -- omniauth: (github) Callback phase initiated.
E, [2024-10-31T23:28:28.656543 #3049637] ERROR -- omniauth: (github) Authentication failure! csrf_detected: OmniAuth::Strategies::OAuth2::CallbackError, csrf_detected | CSRF detected
Started GET "/favicon.ico" for 127.0.0.1 at 2024-10-31 23:28:28 +0500

At this stage, I don’t understand how to correctly enable CSRF protection and assume it should be implemented in the Rails way through X-CSRF-Token.

Moreover, I believe there are two distinct phases for CSRF tokens:

1. The authorization session—POST /auth/github request and the callback GET /auth/github/callback?code=...&state=... where, as I understand it, a CSRF token is needed to avoid the vulnerability described here, although I don’t fully understand the nature of this vulnerability to know why exactly a CSRF token is needed in this context.

2. The issuance of a CSRF token after authorization.

I will elaborate on the second phase. When the backend is a public API, as I understand it, it’s not enough to simply issue a CSRF token since it could easily be obtained, rendering it ineffective. Therefore, it would likely be correct to issue the CSRF token only during authentication.

Currently, I'm not entirely sure how this should work, and I couldn't immediately find any guidance or recommendations in the Rodauth/Rodauth-rails documentation—on how to issue a CSRF token in API mode or in similar edge cases. I believe this question likely relates directly to Rodauth itself, stemming from its initial design for server-side rendering, with API mode support provided by the community.

[AlexeyMatskevich]

Strangely, this solution #17 (comment) doesn't allow me to get rid of the error, I was planning to use this at least as a temporary measure.

Started POST "/auth/github" for 127.0.0.1 at 2024-11-01 01:07:58 +0500
D, [2024-11-01T01:07:58.348066 #3085463] DEBUG -- omniauth: (github) Setup endpoint detected, running now.
D, [2024-11-01T01:07:58.348131 #3085463] DEBUG -- omniauth: (github) Request phase initiated.
Started GET "/auth/github/callback?code=...&state=..." for 127.0.0.1 at 2024-11-01 01:08:05 +0500
D, [2024-11-01T01:08:05.620654 #3085463] DEBUG -- omniauth: (github) Setup endpoint detected, running now.
D, [2024-11-01T01:08:05.620679 #3085463] DEBUG -- omniauth: (github) Callback phase initiated.
E, [2024-11-01T01:08:05.622222 #3085463] ERROR -- omniauth: (github) Authentication failure! csrf_detected: OmniAuth::Strategies::OAuth2::CallbackError, csrf_detected | CSRF detected
Started GET "/favicon.ico" for 127.0.0.1 at 2024-11-01 01:08:05 +0500

[janko]

What method of handling unverified requests are you using in protect_from_forgery? If it's :null_session, that would explain the behavior you're seeing:

1. CSRF token wasn't valid in the request/authorize phase, and Rails continues the request, but uses a null session
2. omniauth-oauth2 attempts to store the "state" (random string) into the session, but that doesn't get persisted
3. in the callback phase, the state is read from the URL and compared to the state from session, which is missing
4. omniauth-oauth2 concludes that the mismatch means it's a CSRF issue and fails

In that case, you have to figure out why the CSRF check failed for the request phase. Rails should read it from X-CSRF-Token header, which means rodauth-omniauth will as well in combination with rodauth-rails. Any chance the Origin header check failed, which is also part of Rails' CSRF protection? Do you see anything in the Rails logs for the request phase?

[janko]

It's worth noting that I haven't yet updated rodauth-omniauth to utilize it, that's in my TODO list 🙂 But all the features that ship with Rodauth features are supported.

[AlexeyMatskevich]

I any recomendation about ?

Do I understand correctly that the developer determines how to initially provide the CSRF token to the client?

[janko]

Right, yes, that sounds correct 👍🏻 I don't have much experience with a SPA + API architecture, so I don't know how the CSRF token is typically given to the client in this scenario.

[AlexeyMatskevich]

I plan to issue a token after successful authorization, I think I saw in discussions how this is done.
That is, in my architecture it will not be possible to request a token again without re-authorization. I think that in the case when the token is available simply via API, this will make a CSRF request more possible for attackers.

[janko]

My recent research led me to conclude that JSON APIs aren't actually vulnerable to CSRF attacks, so the most recent version of Rodauth now disables CSRF protection for JSON APIs by default. In this case, you don't need to deal with CSRF tokens 😉

[AlexeyMatskevich]

Lack of a cookie received at the POST /auth/:provider_name step on the client results in Authentication Error! csrf_detected: OmniAuth::Strategies::OAuth2::CallbackError, csrf_detected | CSRF detected at the callback step when your strategy is based on omniauth-oauth2