Configure sign up and log in with Auth0 using the OAuth2 Basic Plugin

[Discourse]

If you are using Auth0 as your identity provider this guide will show you how to setup authentication using the Discourse OAuth2 Basic Plugin.

Initial Steps

1. Create an Auth0 account if you don’t already have one
2. Install the Discourse OAuth2 Basic Plugin. This plugin is already installed if you are on the Business Plan if you are on the Standard Plan just ask us to upgrade you to Business!

Configure Auth0

1. Applications → Create Application
2. Give your client a name like “Discourse”, click on “Regular Web Application”, click “Create”
3. Ignore the Quick Start tab, and click the Settings tab
4. Under Allowed Callback URLs set it to: https://<your_discourse_url>/auth/oauth2_basic/callback
5. At the bottom click on “Advanced Settings”
6. On the OAuth tab turn off OIDC Conformant
7. On the Endpoints tab you will see all the urls we will copy over to Discourse in the next section.
8. Save Changes

Configure Discourse

Now inside of your Discourse site copy over the following Auth0 values into your Discourse settings:

1. oauth2 client id → <Client ID>
2. oauth2 client secret → <Client Secret>
3. oauth2 authorize url → https://<domain>.auth0.com/authorize
4. oauth2 token url → https://<domain>.auth0.com/oauth/token
5. oauth2 user json url → https://<domain>.auth0.com/userinfo
6. oauth2 json user id path → sub
7. oauth2 json username path → nickname
8. oauth2 json name path → name
9. oauth2 json email path → email
10. oauth2 json avatar path → picture
11. oauth2 enabled →
12. oauth2 authorize options → scope
13. oauth2 scope → openid profile email
14. oauth2 button title → 'with Auth0`

That’s it! Now you will have an Auth0 button on the Discourse sign-up/sign-in page.

Here is a gif of it in action:

Last edited by @JammyDodger 2024-05-26T07:26:23Z

Check document

Perform check on document:

[charchar]

When I attempt to do this, everything appears to work fine until the actual login. When they finish putting all of the information in, they are taken to our forum and are only shown an error message that reads “Sorry, there was an error authorizing your account. Perhaps you did not approve authorization?” with no other options.

The only difference I notice between your instructions and what I have entered is that for authorize url, I am using https://rosen.auth0.com/oauth/authorize as Auth0 instructs instead of https://rosen.auth0.com/authorize, which sends the user to the Discourse signup view rather than the Auth0 app. Am I missing a step?

Side note: I am experiencing this issue with all logins related to Auth0 (social included) but want to just sort out the Auth0 part first, as our social logins work fine through Discourse (with both Discourse and Auth0 URIs input).

[blake (Blake Erickson)]

Inside of Auth0 if you look at your endpoints it should say just be https://<client>.auth0.com/authorize:

What happens if you change it to just “/authorize” and remove the “oauth” part?

[charchar]

Ahh, perhaps I was mistaken by what would occur. Once I do that, it auto fills the Discourse account registration with the e-mail of my Auth0 account. Is this what should happen? I thought it was just using my Auth0 e-mail address to create a Discourse account rather than logging me in using Auth0. When I do it with oauth/authorize, it pops up an Auth0 box that let’s me enter in my Auth0 credentials there. Below is what I see when I click the button using https://<client>.auth0.com/authorize

[blake (Blake Erickson)]

In your Discourse site settings there also is a checkbox for “oauth2 email verified” that you can check, and then the user doesn’t have to enter in an email.

You might already be signed into auth0 which is why maybe it didn’t pop up an auth0 login screen? You might need to try this in a different browser or try your web browser in incognito mode.

[charchar]

Yes, that worked, thanks!

[sirideain]

Hi, I tried setting this up and I do get the Auth0 button for logging in, but it isn’t filling in the fields correctly. The screenshot below is what I see every time. I verified the fields are filled out based on your initial post and what Auth0 shows for a sample JSON. Any thoughts on why the fields wouldn’t be filled in?

[Max_Colvin]

Did you find out why the fields are not being filled in? I am having the same problem. I can supply the full logs, but here is a snippit edited to remove some confidential info:

info: {“id”=>nil, “name”=>nil}
extra: {}
OAuth2 Debugging: user_json_url: https://______.auth0.com/userinfo
OAuth2 Debugging: user_json: {}

[sirideain]

I did not figure out what was going on. I gave up for the moment as it was more an experiment than anything.

[leog (Leo Giovanetti)]

Just FWI, I got to a clean solution for using Auth0 SSO seamlessly. Hope it helps someone achieve a better integration as it did for myself

Discourse SSO with Auth0 🚀

[shahidmir (shahid)]

Hi Leo

I followed your article and got the SSO working in this manner. However, on speaking to Auth0, it appears that due to the redirect away from the rule (into discourse), Auth0 does not consider this a completed login, and hence not a true SSO, rather a redirect.

So when I login to discourse via this method, then immediately go off to another area of my web application (not discourse, that also requires login via Auth0), the lock widget opens up but the user login info is not remembered and has to be re-entered (so there is no session info stored from the previous login to discourse, as it was not considered a login). Hope that makes sense?

Did you tackle this issue?

[blake (Blake Erickson)]

@sirideain

Hi, I tried setting this up and I do get the Auth0 button for logging in, but it isn’t filling in the fields correctly.

@Max_Colvin

Did you find out why the fields are not being filled in?

@sirideain @Max_Colvin I’m really sorry that I’m only now addressing this, but sometime since my original post (Jun '17) and Oct '17 Auth0 made some changes to their dashboard and to the json schema that is returned.

I just pushed a fix to address this:

ADD: can now walk json that contains arrays

The json returned now looks something like this with an identities array:

{
        "email": "test@example.com",
        "user_id": "auth0|123456789",
        "identities":[{
                "user_id": "123456789",
                "provider": "auth0",
                "connection": "Username-Password-Authentication",
                "isSocial": false
        }]
}

The problem is that we can’t key off of the root user_id because it contains the authentication provider before the <auth-provider>|<user_id>, and it could be auth0, twitter, facebook, etc depending on which one the user signed-up/logged-in with, but it needs to be unique which is why we are now grabbing the user_id contained inside of the identities array.

So now inside of your discourse site settings you can configure oauth2_json_user_id_path to be identities.[].user_id

Also inside of the Auth0 dashboard when you setup a new application be sure that “Use Auth0 instead of the IdP to do Single Sign On” is turned off:

because it is now on by default, but should be off for doing oauth.

[shahidmir (shahid)]

its fine, i can get around that by returning my id as part of the app_metadata.
I have 2 issues remaining in this regards, and will start looking now, if you have info on these please could you direct me to the right approach:

1- Im guessing once ive logged in to discourse successfully via oauth2 plugin, after logging out when i retry a login, the auth0 lock widget remembers the user and offers option to login by just clicking email address link. This process fails as no json is returned, and im assuming the correct scopes are not being passed to the auth0 end point, though those scopes are defined inside discourse? (FIXED - seems to work now, using the scopes specified in the oauth2 plugin scope config. Only issue i have seen is that the json is now restricted to just the ID, and not the email nor other details, only in the silent case).

2- On successful authentication, a popup box appears in discourse asking user to choose/change nickname and username. Can this be bypassed?

thanks

[blake (Blake Erickson)]

@shahidmir

1- Im guessing once ive logged in to discourse successfully via oauth2 plugin, after logging out when i retry a login, the auth0 lock widget remembers the user and offers option to login by just clicking email address link. This process fails as no json is returned, and im assuming the correct scopes are not being passed to the auth0 end point, though those scopes are defined inside discourse? (FIXED - seems to work now, using the scopes specified in the oauth2 plugin scope config. Only issue i have seen is that the json is now restricted to just the ID, and not the email nor other details, only in the silent case).

Is this still an issue? I know your edit says fixed, but then you say there is another issue and I don’t understand what that is?

Either way, once I got everything working again creating a user with an already logged in auth0 user works just fine:

@shahidmir

2- On successful authentication, a popup box appears in discourse asking user to choose/change nickname and username. Can this be bypassed?

Not that I’m aware of using oauth. This is most likely possible using sso though.

@shahidmir I’m not sure if you are still having any other issues with auth0, but if you are please just post them in this topic. Thanks!

[shahidmir (shahid)]

Hi blake
It is not working exactly as it is for you.

1- When i login to discourse and enter the username/password, auth0 authentication completes fine and populates the “create account” screen in discourse.

2- second scenario: new account in auth0 created. User then logs into web app, then comes to login to discourse (so discourse record not yet created). The auth0 login box pops up with the credentials pre-populated. Accept these credentials, auth0 authenticates and sends user back to the “create account” screen in discourse, but none of the fields are pre-populated.
Looking at the discourse logs, the json from the /userinfo endpoint is coming back empty in this scenario.

[blake (Blake Erickson)]

@shahidmir

It is not working exactly as it is for you.

This means something somewhere isn’t configured correctly, my first guess is in the auth0 dashboard somewhere. Can you tell me what your settings are for your application under “Advanced Settings” → “OAuth”?

I think you may need to turn off “OIDC Conformant”.

[leog (Leo Giovanetti)]

Hi @shahidmir,
I didn’t have this problem, Auth0 always considered the user being logged in on my use cases, and it is still working fine right now.

@shahidmir

So when I login to discourse via this method, then immediately go off to another area of my web application (not discourse, that also requires login via Auth0)

I’m pretty sure you can’t expect the user to be logged in a different area as you mention. Take a look at this thread.

[shahidmir (shahid)]

Hi @leog, thanks for the link, will check it out now…

Just to give u more detail:

1. My webapp is running in aws under domain ‘http://mydomain.com’.
2. Discourse is also hosted in aws under same domain, but served through cloudfront, using different path ie. “http://mydomain.com/discourse-forum”.

WORKING SCENARIO

1. Click login on “http://mydomain.com”. Lock widget opens up with no credentials. Enter credential and all good, logged in.
2. Now go to discourse by changing url to “http://mydomain.com/discourse-forum”. Clock login and lock widget opens up with credentials pre-populated because of step 1.

NOT WORKING SCENARIO

1. Click login on “http://mydomain.com/discourse-forum”". Lock widget opens up with no credentials. Enter credential and all good, logged in.
2. Now go to webapp by changing url to “http://mydomain.com/”. Click login and lock widget opens up again with NO credentials because according to auth0 step 1 did not complete due to redirect, hence no user login record.

Will take a look at the link you provided, thanks.

PS: In auth0, I am using:

• single tenant
• single API as audience
• one client application for login to http://mydomain.com
• separate client application for login to http://mydomain.com/discourse-forum
• After successful authentication, it is an auth0 rule which sends client back to either “http://mydomain.com” or to “http://mydomain.com/discourse-forum” depending on the calling client id.

[RCheesley (Ruth Cheesley)]

I have a query on this from a UX perspective.

When a user clicks to sign up using the Auth0 (set up as the OAuth2 method) account, and authenticate or create an account, they are dropped back to the Discourse ‘create account’ form - and a user is created successfully in Auth0. The password field is hidden on the create account form, but no other fields are pre-populated.

I’d expect that the fields such as email and name would be pre-populated as the user in Auth0 has these fields available.

I’m not sure if I am missing something, but it is a pretty bumpy user experience and could be error prone (e.g. which email gets notifications, the Auth0 user account or the email they enter on the new user form?).

Ruth

[blake (Blake Erickson)]

Hi Ruth, thanks for posting your question, I moved it to this topic to keep things in one place.

@RCheesley

I’d expect that the fields such as email and name would be pre-populated as the user in Auth0 has these fields available.

If everything is setup correctly those fields will be pre-populated. So now we need to figure out what might be different with your current setup.

Can you to into your Auth0 application settings and then “Advanced Settings” → “OAuth” and turn off “OIDC Conformant” and see if that helps?