While digging into #118, I discovered that signing in with Google appears to delete the user's existing password, or in any case removes the email/password provider, without any warning.
I don't recall reading this in the docs, and I think we should either not destroy this information, or we should provide a visible warning to the user, as well as to developers who use Google sign-in + email/password auth.
We recently went to great lengths to import a large number of user accounts from a legacy auth system using the auth:import tool, preserving each user's password from the old database to provide a seamless transition. In fact, for this purpose I requested pbkdf2-sha256 hash support on the Firebase google group, and it was added a couple of months later (which was fantastic, btw!).
I would prefer (and expect) users to be able to sign in with Google while also maintaining a password for their account on my site. The UX and docs led me to believe that we could use the same email address account with multiple auth providers, and AFAIK does not mention that adding an additional auth provider can remove an existing provider.
Steps to reproduce on https://fir-ui-demo-84a6c.firebaseapp.com/?mode=select:
firebase.auth().fetchProvidersForEmail("YOUR_EMAIL").then(console.log). This should log ["google"] to the console. firebase.auth().signInWithEmailAndPassword("YOUR_EMAIL", "YOUR_PASSWORD").catch(console.log), which will log the error {code: "auth/wrong-password", message: "The password is invalid or the user does not have a password."}Hi @mhuebert, this is actually the expected behavior and mentioned in the documentation. As Google is (almost always) authoritative for the email address (i.e. as an Identity Provider, it can assert that the user signing in is also the owner of the email address), this account takes precedence over the email+password account, as long as the email of the Firebase account has not been verified.
Does that make sense? This is for security reasons, to allow the owner of the email address to take back control of an account that could have been created with its own email address.
Hi @TMSCH,
Thanks for the explanation. Even after hearing you say that, I can read and re-read the linked passage and not come away with the same understanding. Maybe the implications could be described more clearly...
Google serves as both an email and social identity provider. Email IDPs are authoritative for all email addresses related to their hosted email domain while social IDPs assert email identities based having done a one time confirmation of the email address. A user logging in with Google will never cause this error when their account is hosted at Google even if they signed up for their account with a password or a social IDP.
Is a developer reading that text supposed to come away with the understanding that "the password for an account without a verified email address will be deleted upon sign-in with Google"? Or maybe I am still looking at the wrong place.
In any case, the bit about emailVerified is a big help, because it means (a) this won't affect email/password accounts under normal circumstances, and (b) I know how to fix this for my users (it looks like I should have set that field during import).
I do agree that the verified owner of a Gmail account should be able to 'take back' control of an account created previously or by someone else.
@mhuebert I agree, this could be more explicitly said. Would that solve your issue?
Yes, if the behaviour was explained clearly I could have
anticipated/avoided the problems we had here with this.
Thanks!
On Tue, Apr 4, 2017 at 8:05 PM Thomas Césaré-Herriau <
[email protected]> wrote:
@mhuebert https://github.com/mhuebert I agree, this could be more
explicitly said. Would that solve your issue?—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/firebase/firebaseui-web/issues/122#issuecomment-291583801,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAKFZ9bN4grsOw0dyw8EEnPitGuYPgqvks5rsoZ0gaJpZM4My0TW
.
Hello!
I am facing a similar issue with FirebaseUI Auth for Android.
I'm developing a screen where users can manage their account and update their profile.
But I'm wondering, in which situations can users update their password? If a user signs in with Google/Facebook/Twitter, can he update his password within the app? Or he does not have an app password in this case? Should the app show an option to user update the password only when he signs with email and password?
Thanks!
You can add a password to an account regardless if the user signed in with an OAuth provider. The user will have 2 ways to sign in to the same account (email/pass or OAuth sign in).
if you use all of the recommended parameters for user import, but exclude the salt-seperator option, on login firebase auth for web responds with:
{
"code": "auth/wrong-password",
"message": "The password is invalid or the user does not have a password."
}
Should I create a new issue for this?
Most helpful comment
Hi @TMSCH,
Thanks for the explanation. Even after hearing you say that, I can read and re-read the linked passage and not come away with the same understanding. Maybe the implications could be described more clearly...
Google serves as both an email and social identity provider. Email IDPs are authoritative for all email addresses related to their hosted email domain while social IDPs assert email identities based having done a one time confirmation of the email address. A user logging in with Google will never cause this error when their account is hosted at Google even if they signed up for their account with a password or a social IDP.Is a developer reading that text supposed to come away with the understanding that "the password for an account without a verified email address will be deleted upon sign-in with Google"? Or maybe I am still looking at the wrong place.
In any case, the bit about
emailVerifiedis a big help, because it means (a) this won't affect email/password accounts under normal circumstances, and (b) I know how to fix this for my users (it looks like I should have set that field during import).I do agree that the verified owner of a Gmail account should be able to 'take back' control of an account created previously or by someone else.