I’ve seemed to stumbled upon what seems like a bug.
Create 2 connections in your tenant: Google & a DB connection
Create an app using the 2 connections
(for the login page I simply used universal login)
in Auth0 look at your “Users” you have none
Launch the login screen & login with Google
Auth0 > Users: Now has 1 user in the Google connection
Take note of the user ID (e.g. “google-oauth2|1234”)
Go back to your app and log out
Use the “forgot your password” which will switch to the form that accepts an email address
Enter in the email of your google account
I would expect to NOT get an email for this account since it is a social account. So technically the email address I entered should not exist as the password reset should only apply to users in a DB connection (as per my reading of the docs).
Go check your email inbox and you will have gotten a “reset your password” email from Auth0
This seems wrong, but hey, you got an email, so why not move forward.
Click the “Reset Password” button
You’ll load up the change password page from Auth0
Auth0 > Users still only has 1 user
Set a password and confirm it
Auth0 > Users still only has 1 user
Now back at the login screen, instead of logging in with google, enter your google email & the password you just created
TADA. You logged in!
If you look at Auth0 > Users you now have a new user created under the DB connection. They seem to be a copy of the social one as the user ID is the same ID as the social one prefixed with “auth0|”.
I first wondered if our tenant had some odd auto-linking/merging feature enabled. So I tried the above with a new tenant and was able to reproduce it as well. This seems like a bug to me, if it is expected behavior can anyone point me at documentation that explains this so I can come up with a plan in our app to deal with these duplicate accounts.
Where if a user is created via Google connection and the user clicks “forgot your password” and puts in an email address, we get a success response “WE’VE JUST SENT YOU AN EMAIL.”, but no email is actually sent.
We are trying to create the behavior you are experiencing since we don’t mind having duplicate users. To us, it is more important to have a good user experience rather than to frustrate users by saying a reset password email is sent when it really isn’t.
The issue within our applications this was originally causing grief for went away when we changed our internal link from the Auth0 User ID (my preference) to the Auth0 email address. So the duplicate accounts on Auth0 would still link to the same account within our product. So the issue I described above wasn’t a bother to me anymore.
That said.
No, I never got a response to that. It’s almost 2 years old now. Your steps make it sound like they may have addressed my issue by not sending the email during a forgot password flow. Which is correct. It shouldn’t.
As far as Auth0 simply saying “we sent you an email” even though they didn’t. This is a gray area in the login land. One the one hand it’s confusing to the user to say they did something but did not. On the other hand its a security feature.
If the form told the user details about the account they entered it could be used by anyone to siphon user emails out of your system. You’ll see similar tactics on login pages. A failed login should not tell the end user “the password was wrong” or “that email does not exist in our system”. As helpful as those are to the user, they’re easy vectors for someone to collect information about your users.
Auth0 is going the secure route, which they should. Hopefully you don’t have too many users actually fall into this case.