Hi,
Our application is configured with log-in and sign-up Loc.
for social users - How can my system tell that the signed up for the service (i.e. click on sign up tab and click on “Sign up with Google”) or just performed log-in with google?
I would like to avoid cases which users mistakenly logged in with a new Google user, and my system will translate it to a new signup.
My expectation is that Auth0 LOC will reject social login of non-existing users
Hey there @assaf.shlomi! I want to make sure I am understanding the question correctly so please let me know if I missed your desired result.
If you would like to allow social sign ups and merge them into username/password accounts we have a useful document here on linking the accounts:
If you would like to disable social signup, we have go into those details in this document:
or if you want to allow signups only for those users that already have a exisiting username/password account you can leverage rules with a combination of linking users by email Auth0 and Auth0 Actions in a single rule and use the first as a condition for the disabled social signup.
Once again, if I missed the mark of the desired goal please let me know and I would be happy to take another look!
Hi,
I’ll describe the problem again:
Scenario:
I was expecting that if I’m in the login tab of the LOCK and logging in with Google, Auth0 will not pass the login if the user doesn’t exist.
Google will approve the authentication, but Auth0 should reject it.
I wanted to follow up with you @assaf.shlomi after working with our TSE team.
In the event you would like to disable social sign-ups, you can use the disable social sign up rule as we previously spoke about in this doc here. However there is not a way for Auth0 to determine if the end user has another account. In example there might be people with the same name or similar email addresses, and auto-logging in people for another account could pose a security risk.
Of course as we previously spoke, if you want to add social logins for username/password accounts, this can be accomplished through the linking user accounts feature found here.
No. I do not want to disable social signup. I want that Auth0 will distinguish between social signup and social login.
If a new user tries to log in with social before signing up, AUTH0 should response with Error and will ask the user to signup first.
Today, when a user logs in with Social without signing up, AUTH0 treats it as signup.
I tried testing what I believe is the use case you are referring to and you are correct, there is no difference between “Log In” and “Sign Up” for a Social user. I used the Auth0 default python demo app and “logged in” using a google account that was not already in my tenant and I was both “signed up” and “logged in” at the same time. Maybe there is a technical difference but it appears there’s no functional difference between “log in with google” vs “sign up with google”.
You should however still get a pop up asking for permission to access your user details at the social provider if you have not used the given social account before.
Aside: When I tried “sign up with google” I got a CSRF error, but that may be a configuration issues. This was just using the 01-login demo app.
Hey @assaf.shlomi I wanted to touch base and see if Mark’s response was able to help give you some added insight? Please let me know if you still have any questions on the subject!
Hi,
Thanks. I understand from the response that Auth0 do not have any solution for my problem - If a new user will log-in using social, Auth0 will treat is as “sign up” instead of rejecting the log-in.
I’m bumping this because I think it’s a bug, and I think Assaf just gave up. 
To re-iterate the problem I am seeing, which is a slightly different scenario but has the same underlying issue:
The problem is that there should be a separation between SIGNUP and LOGIN. If a user tries to LOGIN with an account that does not exist (social or otherwise) I would expect that Auth0 should return an error message (in the Lock UI or to the native client) and message the user something like:
There is no active account associated with that {{email account|Google profile|Microsoft profile|etc}}. Would you like to Sign Up?
Like Assaf, I want to keep Social Signup enabled… but I want to force users through a signup workflow. Should this work in Auth0?
You should be able to force any such user through a signup process with a rule:
IF user.app_metadata.onboarded != true THEN redirect to onboarding flow
(^^^ not a developer!)
I doubt it’s a bug but rather a design choice, since it’s a consistent pattern. Same rules apply for passwordless login (they’re both treated as login, even if the user didn’t exist before). As @James.Morrison mentioned multiple times, Auth0 provides rules for this so you could make auth0 reject the login, as @assaf.shlomi desired.
The rule-based restriction worked for us 
@James.Morrison, could you guide us a bit further regarding how to use auth0.js to create/merge accounts upon a social login/signup? Is there any downside/security risk to keeping this sort of user-management client-side with auth0.js or would it be best to handle it through our API? …I’d imagine we’d have to redundantly call an endpoint upon each login then, which doesn’t align well with a stateless REST API imo.
There’s no visible difference between a signup and a login of a social user. If there’s some action required to be performed during a first login, something like what @markd mentioned should work.
As for Assaf’s original requirement (Lock rejecting social login for non-existing users), I’m afraid there’s no straight-forward way to do that with Lock itself. However, you can always reject the login from a rule, or simply proceed to link the two accounts.
With regards to linking, our generally recommended flow here is to use a rule to link the users, like this one: https://github.com/auth0/rules/blob/master/src/rules/link-users-by-email.js
Or the account link extension: https://auth0.com/docs/extensions/account-link
The latter also prompts the users to choose whether or not to link.
If you’d rather DIY, you can do it with Auth0.js too. There’s a small writeup here that might shed some light: https://auth0.com/docs/migrations/guides/account-linking#link-current-user-accounts-with-auth0-js
One important thing to note is that if one of the accounts being linked is a database account, you should make sure that its email is verified. Otherwise Bob can create a database account with Alice’s email, and link himself to Alice’s existing social account - thus essentially impersonating Alice. If you’re doing this in a browser context, make sure you consider this.
Hi
I would expect that my application would get an indication if the user came from signup flow or login flow. If we had the indication we could verify in our DB if the user exists, and if not, we would ask him to signup first.
The reason it is important is that many people holds more that one google account - one is personal and one for other needs. Sometimes someone else logs in to google from your laptop. Once the user clicks login, Google authenticate the user (especially if your browser is already logged in to Google), and our app treat it as a new signup, and provision a new tenant.
If my app would know that the login sourced from signup request, it could reject the login and not yo provision a new tenant
Hello @assaf.shlomi,
Google users are, in a sense, already signed up, whether they have logged in to your app or not. You have agreed to use Google as your IdP which means you’ve agreed to leave user account creation and management up to Google. With no other controls in place, enabling a social login means allowing all users in that service access to your app.
That said, you can achieve what you are trying to do with rules or hooks. Create a rule that checks whether a user already exists in your database or not, and if not you can deal with them however you like. You can also add an attribute to flag fully onboarded users and use that attribute in the rule to skip database lookups for such users. E.g., add the following to a fully onboarded user:
{
"app_metadata": {
"onboarded": true
}
}
Create a rule that executes the following logic:
if user.app_metadata.onboarded == true:
skip the rest of this rule
else:
if the user is in my database:
process this user (e.g., add "onboarded": true)
else:
deal with users who are not in my database
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.