-
Couldn't load subscription status.
- Fork 556
Description
Bug report
- I confirm this is a bug with Supabase, not with my own application.
- I confirm I have searched the Docs and GitHub Discussions.
Describe the bug
When a user signs up with an OAuth provider (e.g. Google) and later sets a password via
await supabase.auth.updateUser({ password: 'password' })they can successfully log in with email/password, but the "email" provider is not added to the auth.identities table.
To Reproduce
-
Sign up with Google (OAuth) using Supabase Auth.
-
Call:
await supabase.auth.updateUser({ password: 'password' })
-
Inspect linked identities:
const { data: identities } = await supabase.auth.getUserIdentities();
-
Observe:
- Email/password login works
- No
"email"entry appears in the list of linked identities
Expected behavior
After updateUser({ password }), the "email" provider should be automatically linked and visible in the auth.identities table, just as when using linkIdentity() for OAuth providers.
System information
- OS: macOS
- Browser: Chrome
- Version of supabase-js: 2.50.3
- Version of Node.js: 22.8.6
Additional context
When calling updateUser({ password }), either the auth.identities table should be updated with the "email" provider, or linkIdentity({ provider: 'email' }) should be supported for the email provider.
This issue highlights a gap in Supabase Auth’s identity-linking lifecycle. Manual linking exists for OAuth-to-OAuth, but there is no supported mechanism to link the email provider after setting a password. Common workarounds include manual SQL inserts into auth.identities or tracking password capability in a custom table. A built-in fix or supported API for linking an email identity would resolve this inconsistency.