OAuth account creation fails due to CSRF detection immediately after logging into Auth0 on same browser

SSO
1

We have configured the oauth2 plugin following the directions on Configure sign up and log in with Auth0 using the OAuth2 Basic Plugin.

The flow works as follows:

If they click Log In and then Use your dbt Community Account, the account is successfully created and they see the account creation dialog where they can set their username etc.

Loom video showing this in action:

I have enabled oauth2 debug auth and in the logs can see (oauth2_basic) Authentication failure! csrf_detected: OmniAuth::Strategies::OAuth2::CallbackError, csrf_detected | CSRF detected

My questions:

  1. Is this a Discourse issue or an Auth0 issue? I assume Discourse since a basically identical login flow for Slack works without issue.
  2. Why does this work on the Login page but not when login is triggered from the Auth0 side?
  3. The default CSRF error message implies that it happens when the browser changes, or when the login flow takes too long. Neither of those are the case, what else could be causing it?
4

Hi @joellabes - please can you check what URL youā€™ve entered in the ā€œApplication Login URIā€ Auth0 setting?

Screenshot 2022-12-20 at 10.35.50
Screenshot 2022-12-20 at 10.35.501956Ɨ388 47 KB

It should be {your forum}/auth/oauth2_basic. If you have /callback on the end, that could cause the issue you described.

2 Likes
5

Thanks @david - right now I donā€™t have anything in the Application Login URI box, but do have something in allowed callback URLs:

image
image2050Ɨ1268 254 KB

Should I put https://discourse.getdbt.com/auth/oauth2_basic in the Application Login URI field and leave https://discourse.getdbt.com/auth/oauth2_basic/callback in the Allowed Callback URLs field?

1 Like
6

You could try that, yes.

Can you share some more detail about how the ā€œGet help on the Community Forumā€ link is implemented? Where does the link go? I am currently assuming that the button is handled by Auth0, and that adding that new URL configuration will cause the button to correctly link to /auth/oauth2_basic to start the login flow.

1 Like
7

Sorry for the slow reply - just getting back after the Christmas break!

I did this:

but still get the same result.

That link points to https://dev-zb38hsho.us.auth0.com/samlp/5GpVvVgryMnBaNJFuLt5DW3bs89jO0hr, where dev-zb38hsho is our Auth0 instance ID and 5GpVvVgryMnBaNJFuLt5DW3bs89jO0hr is the Client ID for the Discourse Application in Auth0.

Visiting that link redirects to https://dev-zb38hsho.us.auth0.com/u/login?state=SESSION_SPECIFIC_TOKEN.

8

The key is that Discourse needs to start the authentication flow at /auth/oauth2_basic, then redirect to Auth0, then come back to /auth/oauth2_basic/callback.

I was hoping we could get Auth0 to trigger login by starting with the first URL, but it sounds like itā€™s jumping Discourse straight to the callback URL.

Could you update the button to point to /auth/oauth2_basic on the forum? That will start the authentication flow and immediately redirect to Auth0, so the overall UX should be the same.

4 Likes
9

Yes that works! It does pause on an interstitial page with a Continue button; is user interaction mandatory to safely trigger an OAuth flow or something?

image
image1486Ɨ736 34.8 KB

If thereā€™s a way to make it

then that would be a bonus but this is great! Thank you :pray:

10

That page is shown when there are multiple login methods on a site. If you disable ā€˜local loginsā€™ (username/password) then it should go straight through to the login process.

3 Likes
11

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.