My app is using email addresses as unique identifiers for users. It also allows users to log in via social connections, i.e. Google Oauth. I want to disable password-based login when a user logs in with Google. Is it possible to somehow configure this in Auth0?
(Note that I want to do this on a per-user basis, rather than globally disable database connections.)
Or, more generally, is there a generalized way to control “which methods of auth should be available for a specific user”?
This is a complex question and a unique approach.
The more standard approach is “account linking”, so that it doesn’t matter if a user uses their username/password or their social login, they get the same account.
A slightly confusing take is to allow both types of account for the same email address, but they are not linked. They are completely different accounts in spite of having the same identifier. If your backend cannot handle this you have a security issue - there are account takeover attacks. This approach is the OOTB approach, if you use Auth0 without any customization.
I think the approach you are taking would be complex and problematic, given the constraints of social accounts (we have no way to block a particular email being used for social, we can only react after it is used).
Hi John, thanks for bringing up the account linking issue.
To clarify, by “user” I meant the concept in my own backend, where there’s a one-to-one correspondence between email address and account, regardless of the method of auth. (I want to treat my own datastore as the source of truth, rather than relying on Auth0’s users table.)
I think I’m looking for something similar to home realm discovery. Like, can we do something like:
- User enters in their email address
- Auth0 checks to see if there exists an account for that email address + Google Oauth
- If so, Auth0 directs the user to login with Google Oauth, and doesn’t even allow email + password as an option. (So I guess if I’m not linking accounts, it would in effect prevent the email + password account from being used again in the future.)
This is the scenario I was talking about earlier: if you use email as the key, you are susceptible to takeover attacks. In you backend, it is much better to have a unique GUID for user ID instead of email. Then the rest of the problems you are facing become simpler.
What is the mechanism of the takeover attack? Is it not enough to display a message when a user logs in for the first time with Google Oauth into an unverified account that already existed with email + password?
Some variation of this:
Legit User signs in with gmail social.
Evil hacker registers user with legit user’s gmail address, evil hacker now knows password
The two accounts are linked, either with Auth0’s linking mechanism or because your backend uses email as a primary key
Evil hacker now has access to legit user’s account.
That’s a very terse summary, be aware that there are many variations on this. Using email as the key is the red flag for this.