Case:
User had previously registered using Oauth. They subsequently forgot that they used oauth, and instead try to sign in using email and password. The password doesn’t exist in the databse, because they used Oauth.
My solution:
When the user tries to sign in using email and password, it checks the user in the database. If any of the Oauth objects contains a value, trigger a “Access denied” precondition with error message: “Try logging in again using your social media account.”
Your thoughts?
Is this best practice? Are there any security concerns revealing to the caller that they indeed do have an Oauth account already registered? If so, what is a better option?
hey adam, Suggesting social login is innovative! I like it, esp if you’re not making a promise that it’s there.
It’s common to keep the email address as the primary identifier for the user, even in social auth situations. The user logs in with social, which provides an email address as part of the ID token you get in the authentication code flow. Then you can allow the user to “I forgot my password” based on that email address, which allows one to log in either way.
The reverse also works. I’ve signed in using user/pass, and then later when they introduce social, I can log in with the social because it’s all keyed by the email address.
The key security question is whether they have logged in with this email address before. It’s more secure to not let them know, but it’s a better service experience if you do. We always balance these things. Many service will say “bad password” or “bad username” separately. That exposes information, but not too much.