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?
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?
@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.
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:
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?
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.
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”?
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.
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?).