How to pass custom state after the CSRF refactoring?

[fedme]

Hi!

I have noticed that after #82 the state query parameter is set internally by Ueberauth to perform CSRF validation.

The question now is, can we still pass custom state data during the OAuth process? Does anyone know how?

It seems that whatever you pass via the state query param gets overwritten with Ueberauth's CSRF token. This breaks our app logic, which uses state to know where to redirect users after login.

Thanks!

[yordis]

@fedme would you mind suggesting some changes in ueberauth where we configure the state token creation?

[fedme]

Hey @yordis, thanks for getting back to me!

I am not sure my Elixir skills are yet at the point where I can contribute a change of this kind.

But I am thinking maybe I can use a cookie to store my custom state between the request and callback (instead of using the state query parameter). That should be possible, right?

[yordis]

@fedme well, it depends on how Google OAuth2 handles the CSRF token. Do you know?

Chaging this line,

ueberauth_google/lib/ueberauth/strategy/google.ex

Line 32 in ee6f9dd

|> with_state_param(conn)

to should do the trick, and pass the token to the right configuration

That function just read the state, https://github.com/ueberauth/ueberauth/blob/5c297f1d7574a034b2117a4f6ffb3075ca66d359/lib/ueberauth/strategies/helpers.ex#L178 and add it to the configuration, but you don't have to use it.

Also, I notice that maybe, we need to disable CSRF attack for this provider.

Will get back to you on this late today hopefully

[fedme]

Thanks for your help @yordis!

As a workaround, I did manage to use the session cookie to store my custom state (instead of using the state query parameter).

See the following code that shows how I managed to do it:

defmodule MyAppWeb.AuthController do
  use MyAppWeb, :controller
 
  plug(Ueberauth, providers: [:google_custom])

  @provider_config {Ueberauth.Strategy.Google, [default_scope: "email profile"]}

  def request(conn, %{"provider" => "google", "custom_state" => custom_state) do
    # Store custom state in the session
    conn
    |> put_session(:auth_custom_state, custom_state)
    |> Ueberauth.run_request("google", @provider_config)
  end

  def callback(conn, params) do
    %{assigns: %{ueberauth_auth: auth}} =
      conn
      |> Ueberauth.run_callback("google", @provider_config)

    # Get custom state back from session
    auth_custom_state = get_session(conn, :auth_custom_state)

    IO.inspect(auth_custom_state, label: "Auth custom state")
  end
end

With that code, I am able to start the OAuth flow passing some custom state in the URL (e.g. https://localhost:4000/auth/google?custom_state=some_values_here) and then take it back from the session in the callback function.

It seems to work well as a workaround, so maybe there is no need to make any changes to the library?

[yordis]

Hey @fedme

It seems that Google OAuth2 does support state param, I would suggest stopping using such thing for other things than security reasons as Ueberauth is trying to do at the moment.

https://developers.google.com/identity/protocols/oauth2/web-server

[yordis]

I am closing this, strongly recommend refactoring your side, and use something else for your intention.

[fernandofleury]

@yordis just to understand correctly, state is a valid part of Google's OAuth2 spec, but will this ueberauth plugin re-introduce support to pass it through? Or am I missing something?

[yordis]

@fernandofleury the latest integration will inject a state into the URL, to avoid CSRF attacks.

His issue is that we overwrite the value of such state key, so he lost his value to do other stuff he was trying to do, so it conflicts with state coming from the CSRF attack.

[danturn]

it does seem a bit confusing to overwrite it in ueberauth imo, the google spec does explicitly suggest using it for "directing the user to the correct resource" as fernando is doing in his original code?

would it make sense to add the csrf (e.g. use a map that gets serialised) to the user provided state inside ueberauth and then strip it out when passing it back to the application code?

[chazu]

This is also a hindrance for us - the state parameter is not meant solely to be used for security purposes.

[Hanspagh]

Sounds like we might need to reopen this again

[apognu]

Would you consider opening this again?

It is really blocking when we need to pass a custom state, either because it's used for another thing than security purposes, or because we need to pass the CSRF nonce generated by another, external, tool (that breaks because of this)?

Defaulting to using Ueberauth's own CSRF is good, but breaks workflows if there are no escape hatches. A simple way to tap into the ignore_csrf_attack attribute would be interesting.