The `.signUp()` method does NOT error if the email is already in use by a social login account.

[rochajulian]

Bug report

• [x] I confirm this is a bug with Supabase, not with my own application.
• [x] I confirm I have searched the Docs, GitHub Discussions, and Discord.

Describe the bug

I have social logins (Apple and Google) and email login enabled in my app. I also have the confirm email option enabled for email-based auth.

Scenario: Suppose that a user logs in with one of the provided social logins. Later on, for whatever reason, they decide to attempt and make an account with an email. They use the SAME email which is already attributed to their social login account.

Bug 1: The .signUp() method executes successfully in this case without error. It doesn't tell me that the email is already linked to an account which would help to me to then show a message to the user that they should just log in instead.

Bug 2: Since it executes successfully, the user SHOULD receive a confirmation email...but Supabase doesn't send it in this case...

Bug 3: Why is this behavior happening in the first place??? It seems so odd not to have a simple error code be triggered from the .signUp() method stating that the email already exists as part of a social login account.

To Reproduce

Steps to reproduce the behavior, please provide code snippets or a repository:

1. Allow any social login provider AND email login.
2. Enable the confirm email option.
3. Sign in to your app using said social provider.
4. Log out and try to make an account with an email.
5. Use the email that your social login uses.
6. See bugs mentioned above.

Expected behavior

The .signUp() method should tell me that the email is already in use by a social login account.

System information

• OS: macOS
• Version of supabase-js: 2.48.1

Additional context

Interestingly enough, I've noticed that if I do things the other way around, that is that if I first create an account with an email, verify it, and then later on attempt to login with a social provider with an account that uses the SAME email, Supabase will simply append the provider to the auth.users table.

This behavior makes sense for this case. But in the other case mentioned above, those behaviors are simply odd.

[GaryAustin1]

signUp is designed not to expose if the email already exists for security reasons. You could probe if a user with a given email is using the app.

I've seen them actually discuss the rational for security, but not going to track it down.

[ympek]

I'm using supabase/auth:v2.176.1 Docker image. I've hit mostly the same issue, but will add my two cents.

From my research, the user can perform the following:

• register via social login (github in my case)
• issue a password reset request (/recover route)
• set a password after clicking email link
• now user can obtain JWT for this account via email+password from now on just fine

However, the providers object still looks like this:

"app_metadata": {
			"provider": "github",
			"providers": [
				"github"
			]
		},

Effectively: the object state is inconsistent with the possibilities of signing in the user actually has (which is misleading for me as an admin and I think this is a bug).

Curious what are your thoughts on this. Should I block the possibility to (re)set password for oauthprovider-registered users on application level? Certainly we should have some possibility to add "email" provider to existing account later in the application lifetime, even if they originally registered with github/google/whatever.

[GaryAustin1]

[ympek]

Based on what you highlighted on the screenshot, I think you are mistunderstanding me. I am not talking about the provider but the providers.

The providers attribute indicates the list of providers that the user can use to login with.

That's where the bug is. By using reset password functionality, I can set myself a password and thus I can use email provider. Which is not listed in the providers array after the operation.

[GaryAustin1]

Got it. Then I would check other issues or generate a new issue for them (SB). This issue is not exactly on your topic.

[ympek]

Fair enough, thanks I'll prepare detailed report later

[nicolocardana]

Experiencing the same bug as OP. Cannot log in with email + password if an account is already created with one or more social logins and the confirmation email is active