Currently have a working web app with auth0 identity. I want to add social login FB, Google, Apple for the purposes of creating new account and logging into existing ones. The social account create process seems straight forward. My concern is should I create a way to leverage social login that will enable access to existing accounts in the event the email address is the same?
For example consider I am known to my app as: user@internet.co.in
That email address is also my facebook account email.
If I try to social login should that just allow me to access that account? That seems like a security loophole without having to first authorize/connect that identity to my existing account? If I need to enable a user to “connect” social to their account, that is where I am in need of some guidance.
Is it acceptable or best practice that I only allow social login for new accounts being created using social login vs entering a password when creating an account? When an account has been created using a social login - should that user be able to self-service reset their password or are they restricted to using their social login? If they are not able to social login have they simply lost access to their account?
If you’ve implemented social login, how are you handling these situations?
Regarding your question, that’s a design decision. The default behaviour we provide is separate accounts that come from different connections. This means that user@internet.co.in could have N accounts if they use N different connections to log in to your application. All those accounts would have the same email address, user@internet.co.in
That’s the default behaviour, but sometimes, our customers choose to “merge” all those accounts. That’s called Account Linking and there are two ways of implementing it:
User-initiated account linking: allow your users to link their accounts using an admin screen in your app.
Suggested account linking: identify accounts with the same email address and prompt the user in your app to link them.
I encourage you to read User Account Linking to learn more about this topic and some detailed examples.
Is it acceptable? Yes. Is it best practice? I wouldn’t say it’s a best practice, I would say it’s a design decision as valid as not using Account Linking.
By default (no Account Linking involved), no, a Social user won’t be able to reset any other account’s password, even if it belongs to the same email address. Those user’s credentials are actually managed by the social IdP (for example, password reset should be done via social IdP and not via Auth0).
Yes, if there’s no account linking, that user can only log in via social login. If they have forgotten their password, they should go to their social IdP and use their forgotten/reset password service.
I’m having the same issue and questions. Wonder how @babyyoda solved it.
I also don’t know how I can identify if a user comes from Social Login or if it is a normal Login/Signup.
Is it a good idea to check the sub: param in the user data that comes along with the session? I could check the provider info for a “Auth0|” text - so I know it comes from a “normal” login/signup. But wonder if this could change in the future.
We’ve got social login working for facebook, google and apple. The first year we used auth0 it was just standard username/password. Adding social brought some twists - users who socially login have an account in Auth0 for that, users who login via username/pw have an account.
If you examine users created in your tenant using each method, social vs un/pw, you will see the user id: value changes. Users created with un/pw start with auth0|, where facebook starts with facebook|, apple with apple| and google with google-oauth2|.
The “sub” subject in the JWT will also display this user id value.