Howdy!
I’m looking into adding social login - currently our hosted pages are custom so we don’t have the built in lock support.
I have a couple of questions about custom setup in this case:
If we enable social providers in the dashboard, can we see that list somehow in the config inside of the hosted page?
Just to verify - since we’re not using the lock, we will have to custom add all of the social buttons?
Hey @anja, welcome back!
There is a FAQ here about emulating lock’s social features, that may help you. I haven’t implemented this strategy myself, but I imagine this would solve the problem. Let me know if it works/doesn’t.
In terms of seeing your social connections; you can use the management api to get a list of those connections. Look here for that.
Hope this helps!
@dan.woda thank you I’m happy to be back expanding our Auth0 setup!
Thank you for the links, I’ll keep you posted on our progress with those approaches, I’m currently just working on the spike to figure out our social login game plan 
Another question did pop up today - when a user chooses a social provider, they successfully login in, and get redirected to the url provided. On that redirect, do the custom database action scripts get hit? id) getUser, login, verify, etc…
I can see that users get created based on the connection, but we want to be able to verify against our database as well.
That custom database login script is specific to that database. If they are logging in using a social provider that would be considered a separate connection from a custom DB.
Depending on what you want to accomplish during those scripts, rules would likely be the best route for simple verification. Rules are run on each successful login/authentication, regardless of connection type. You could write a rule to verify that user against your own database. Then, if they are not in your DB, you could limit access, disable account, require further action etc.
Another robust option would be to use account linking to link that users social and custom DB accounts. This gives you access to all the information from both sources. More on that here. Keep in mind, this requires the user to share the same email in both the custom DB and the social provider.
Does that answer your question?
Ah nice, that answered my questions! Thank you, we were suspecting Rules would be our friends like always 
Will definitely reach out with anymore questions and findings!
@dan.woda are there any Auth0 examples of social login in the hosted pages without using the Lock? We have completely custom pages, and it appears we will have to support all api’s from the social providers we enable in order to use them - does this mean we do not have access to the clientid/secret we setup in the social tab?
Hi @anja,
I’m not able to find any examples of this implementation, but the cdn mentioned in the FAQ I linked above should provide that info if I am not mistaken. The management api at GET /api/v2/connections should provide clientId and secret as well.
Does that answer your question?
@dan.woda I’ve started implementing social login and have added a rule that just checks if the user exists in our DB. I’ve added logs and can see that the rule gets hit correctly - if a user is trying to sign up but they already exist it goes to the callback returning an error, but when that happens auth0 redirects to the callbackURL (with the error embedded in the url) instead of staying on the hosted page and displaying it. Do the rules not communicate back to the hosted pages if something goes wrong in them? For this rule in specific we want the errors to be displayed in the hosted pages, is there an extra step that’s missing in how we handle the errors?
Sorry for the delay.
I think this topic address your issue:
@dan.woda yep I took that same approach, where in my callback component I look to see if it’s actually an error or not then trigger login/signup flow as needed. We’re currently setting the mode in our front end for LogIn or SignUp, and we use this in our rules to determine whether to trigger MFA or not. Since there is one landing page for hosted login, if the user is in the SignUp mode but clicks to Log In because they have an account, we update the page to show the login inputs and dialog instead. When this switch is made, mode doesn’t update so we have a param called flow that tracks this change. In case of social provider login, webAuth.authorize does not seem to persist this param - is there any way to do this? I’ve tried adding mode directly into the webAuth.authorize payload object, and tried adding random params as well to see if anything persists but it doesn’t. This is what that call looks like with mode in it but it does not persist the change to the rules:
webAuth.authorize({ response_type: 'code', connection: 'facebook', client_id: clientID, redirect_uri: callbackURL, mode: flow }, function (err) { if (err) { displayError(err); } });
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.