Link Multiple Auth Providers to an Account

[sandbox-apps]

https://firebase.google.com/docs/auth/android/account-linking

[rodjoseph]

I think this would be great as well

[kiwicopple]

Hey @sandbox-apps - this is technically possible, as long as the user has the same email for all accounts (since this is the primary login mechanism).

For example

• user logs in with email 'test@email.com'
• user logs in with Facebook OAuth and their facebook account has the email 'test@email.com'

Both of these will return the same user uuid.

Is that what you're looking for?

[sandbox-apps]

Firebase has this setup where Example:

1. I signed up via email/password then login on app
2. Go to my profile then link social for example facebook
3. Even though facebook has different email address it can be linked

Another example:

1. I signed up via email/password then login on app
2. Go to my profile then link social for example twitter
3. Even though twitter has no email address it can be linked (via uid and providerId) see here: https://github.com/supabase/supabase/issues/2853

Result:

1. I can sign in via email/password
2. I can sign in via facebook and it will not create another account because it is already connected to a user even though they different email address returned during OAuth
3. I can sign in via twitter and it will not create another account because it is already connected to a user even though twitter has no email address returned during OAuth

Things also that we can keep in mind that..

1. If a user signed up with email/password with an email of test@gmail.com, user can still create an separate account via facebook/twitter if this social has the same email.
2. Unless link or merge, then it will create new account.
3. You can only link account if there is a user that is currently logged in on app/system to determine where would you append the additional data

[sandbox-apps]

Further more you can unlink provider via providerId with the currentUser

Firebase.auth.currentUser!!.unlink(providerId)
        .addOnCompleteListener(this) { task ->
            if (task.isSuccessful) {
                // Auth provider unlinked from account
                // ...
            }
        }

[eMeRiKa13]

I would love to have the workflow you describe @sandbox-apps!

It seems the "perfect" way to manage auth with 3rd party providers.

[didavid61202]

Hey @sandbox-apps - this is technically possible, as long as the user has the same email for all accounts (since this is the primary login mechanism).

For example

• user logs in with email 'test@email.com'
• user logs in with Facebook OAuth and their facebook account has the email 'test@email.com'

Both of these will return the same user uuid.

Is that what you're looking for?

Hi @kiwicopple, thanks for all your teams great work in supabase, lovin' it! Just want to mention that it would be great if we can link different provider to same account even if the email is different. Sometimes user use different email for different providers. And also able to unlink will be great if user want to have separated accounts event the email is the same. Thanks :)

[firatoezcan]

For anyone wanting to support this, you'd need to propose to https://github.com/netlify/gotrue as that is where the logic behind users and providers live. I don't know if Supabase runs a fork of it, but this is where the request should be going to

[henningko]

Adding another use case here, besides multiple auth paths: I want to store connections to 3rd party apps, e.g. a Twitter connection for retrieving a user's tweets. Else, I need to duplicate a lot of the OAuth logic and store it separately.

[diogoribeirodev]

Any updates on this

[kangmingtay]

Hi everyone, we currently don't have plans to support manual linking of accounts in the near future. Currently, gotrue only supports automatic linking of accounts based on the user's email.

[jdgamble555]

This could be done theoretically with a procedure and policies that updates the auth.users and auth.identities tables.

• You would basically delete the identity id in auth.identities, remove the provider in auth.users.raw_app_meta_data and auth.users.raw_user_meta_data.

Adding it would require logging out and back in with the provider assuming the email is the same. If you wanted to take that a step further, you could create another procedure with an http function that runs the full oAuth 2 protocol, then saves it manually. You could also theoretically add the missing option for signin with popup.

Of course, if someone does either of these two options, please share the code here.

J

[hf]

Hey everyone, we're aware of the need to customize the account linking logic and have some plans to make it happen via web hooks / triggers. However, this is not something we're going to be working on in the short term.

I'll be closing this issue as account linking is supported if the user has the same email in the social login providers.

[rlee1990]

I don't get the point of closing this and stating that account linking is suppoerted when its the same email but the point of this whole thread is to get support for when its NOT THE SAME EMAIL. Its a must have future in auth now and days. This should really be pushed up the priority list.

[sdaoud]

This is really a necessity for auth to be functional in a lot of cases. Automatic linking is too unpredictable and doesn't address the issues described here.

[kangmingtay]

Hi @rlee1990 and @sdaoud, I've pinned this issue to emphasise that this is definitely one of our top priorities going forward and we're working to make this happen gradually. If you've been keeping up with the updates on Supabase and gotrue, you may already know that automatic linking has always been the default way that gotrue links accounts. While we understand the advantages of manual linking that have been discussed in this thread, it's important to keep in mind that removing automatic linking altogether could create backward compatibility issues for existing users.

Furthermore, we've received feedback from many developers who appreciate the simplicity of automatic linking for UX purposes. While we recognise the benefits of manual linking, it's not something that we can expect everyone to switch to overnight.

I also want to reiterate that we'll eventually move to the model of manual linking accounts through a well-designed API. Currently, we are considering a few ideas to implement this:

1. Implement some form of webhooks so users can define the linking behaviour between accounts
2. Provide an API to support the following:
   • link newly created identities to existing users
   • unlink an identity from a user

@hf has already made some progress to simplify the account linking logic in this PR to make way for the use of webhooks to decide linking behaviour. Please feel free to drop any ideas you may have regarding this topic too as the team will be more than happy to discuss them in detail!

[rlee1990]

@kangmingtay using a webhook sounds like a nice approach. I get keeping automatic linking in place also. A webhook to help link an account is a useful option.

[jdgamble555]

I would say keep the automatic linking as the default option, but add a simple config option automatic linking: true that could be set to false.

Then just copy the ideas of link and unlink that Firebase uses or Auth0. Basic functions seem to be a good idea.

J

[kangmingtay]

@jdgamble555 we thought of that option too but it's not feasible to make it toggle-able since automatic linking requires the email to be unique for the algorithm to know which user to link the new identity to. For example:

(assuming automatic linking: false)

1. User 1 signs up with foo@example.com using google
2. User 2 signs up with foo@example.com using facebook (not linked to (1))
3. Toggle automatic linking: true
4. User 3 signs up with foo@example.com using twitter (no way of knowing whether to link User 3 to (1) or (2))

It has to be a one-way toggle or an option you select before you start building your app. Either you opt-in for automatic linking or resign to a manual linking API for eternity 🙃

[jdgamble555]

Hmmm, I definitely don’t like the eternity issue. 🤷🏻 Perhaps the simple answer is to automatically link with the first found profile, in reality the first document id record containing that email.

Any new profiles going forward would be automatic, but all profiles would have a link and unlink option after sign up. This puts the control back into the developer. So that boolean option is only concerning new signups, and the first found option. This solves any backwards compatible problems.

Linking is always available.

I should add this is also relevant for anonymous logins too, which is an entirely different feature.

😃 J

[ofekd]

@kangmingtay @hf Can you explain what modifications are needed to be done in the database to link two accounts together?

[baderdean]

Hello,

we need to achieve something similar. We have an app where the users, logged by social logins or not, could add other auth providers accounts with additional scope. The other accounts could be from the same auth provider.

Example: I'm logged in my Sales CRM as james@gmail.com with access to my contacts, then I want to import contacts from my other gmail account named james.pro@gmail.com without creating another account but linking the latter to the first.

As a quick (and dirty?) workaround, we have overriden Gotrue callback URI to point out to our backend. This way, we could either fetch token and do our business or redirect users back to Gotrue for user account creation.

Is it something planned to implement?

[empato-limited]

this is very important to use as well ... would help cross-device sing-ins ... for ex if i sign up / sign in with apple ... i will not be able to use that account in a non-ios enviroment

[aaroniker]

is there an estimation when this will be addressed?

[sebmor]

This seems to be a must-have feature for any auth solution. What site nowadays doesn't even let you connect multiple oauth providers with different emails?

[ARMATAV]

Ah this just managed to kick me off of using the auth system in Supabase for a project; really wish a link function existed :(

[aaroniker]

@hf any update on this? 🙏🙂

[hf]

We are working on it! Sorry for the delay... it's not a simple feat as we need to make sure not to break any existing behavior, while allowing for an API that we won't have to go back to in 5 months time.

[aaroniker]

We are working on it! Sorry for the delay... it's not a simple feat as we need to make sure not to break any existing behavior, while allowing for an API that we won't have to go back to in 5 months time.

@hf Thanks for the update, that's awesome!! ✨ any rough ETA?

[kangmingtay]

Hey everyone, just an update, we've merged in 2 PRs that will make manual linking possible very soon:

1. Link an oauth identity to a user: https://github.com/supabase/gotrue/pull/1317
2. Unlink an oauth identity: https://github.com/supabase/gotrue/pull/1315

We'll need some time to roll this feature out to all projects on Supabase but if you are self-hosting, you should be able to use this new feature with the latest version of gotrue. The target ETA for getting this out to all projects is by LWX

The corresponding client library bindings will also be added to the js library in this PR: https://github.com/supabase/gotrue-js/pull/814

The process for linking / unlinking an identity will look something like this:

// assume user is already logged in and authenticated

// link the current user to a google identity
// this works very similar to signInWithOAuth() and will redirect the user to google to complete the oauth flow 
// once the oauth flow has been completed, the user will be redirected back to the app with the identity linked
const { data, error } = await supabase.auth.linkIdentity({ provider: 'google' })

// fetch all identities linked to the current user
const { data: { identities } } = await supabase.auth.getUserIdentities()

const googleIdentity = identities.find(identity => identity.provider === 'google')

// unlink an identity
await supabase.auth.unlinkIdentity(googleIdentity)

[ARMATAV]

This plus a fix for expiring tokens in @supabase/ssr will be a life saver

[evelant]

@kangmingtay I'm migrating from Firebase Auth to Supabase Auth now that there is anonymous account support. I'm on react-native but the docs for linking seem to assume web. What is the correct auth API to use to link an anonymous account to a credential retrieved from a native social auth provider?

For example the docs suggest using supabase.auth.linkIdentity({ provider: 'google' }) stating that "the user will be redirected to Google to complete the OAuth2.0 flow" which probably won't work on react native, it seems to be assuming web. Some of the provider documentation like google auth demonstrate signing in using a token fetched from the native auth flow (react-native-google-sign-in) using supabase.auth.signInWithIdToken but there is no mention of linking the credential to an anonymous account.

The workflow I'm trying to replicate from Firebase auth is that new users always get an anonymous account and at some later point in time are prompted to link a real credential so they don't lose their progress. It seems like maybe the supabase client is missing a linkIdentityWithIdToken method?

[f-bog]

@kangmingtay I'm migrating from Firebase Auth to Supabase Auth now that there is anonymous account support. I'm on react-native but the docs for linking seem to assume web. What is the correct auth API to use to link an anonymous account to a credential retrieved from a native social auth provider?

For example the docs suggest using supabase.auth.linkIdentity({ provider: 'google' }) stating that "the user will be redirected to Google to complete the OAuth2.0 flow" which probably won't work on react native, it seems to be assuming web. Some of the provider documentation like google auth demonstrate signing in using a token fetched from the native auth flow (react-native-google-sign-in) using supabase.auth.signInWithIdToken but there is no mention of linking the credential to an anonymous account.

The workflow I'm trying to replicate from Firebase auth is that new users always get an anonymous account and at some later point in time are prompted to link a real credential so they don't lose their progress. It seems like maybe the supabase client is missing a linkIdentityWithIdToken method?

I'm in the same boat, and managed to get it to work using linkIdentity, however I'm using expo-web-browserand expo-auth-session in my app to achieve this.

        const { data, error } = await supabase.auth.linkIdentity({
          provider: "apple",
          options: {
            redirectTo,
          },
        });
        if (error) throw error;

        WebBrowser.openBrowserAsync(data.url);

I feel like there's a bit of wonkiness to this though. If the anonymous user attempts to link to a google (or apple account) with one that is already used.. it seems to fail silently, and I'm not able to display any meaningful message to the client app.

Edit: Just found the fix for my problem above, had to read the url from the Linking.addEventListener event.. My bad!

[lawinski]

Thanks for implementing account linking! :) Referring to @evelant message and #1645 issue, I think it would be helpful to add support for linking accounts via id token. If someone has implemented mobile native login, they are currently forced to start the linking process in a web view. While this isn’t a major issue, native login offers a better user experience, and I’m sure many developers would prefer to keep things consistent in their apps. After looking at the code, it seems like linking accounts via an id token shouldn’t be too difficult, but it would be great if one of the maintainers could share their thoughts on whether this is a good approach or what the plans are for improving account linking.

[JonathanLab]

Bumping a request for a linkIdentityWithIdToken function or similar functionality 👍

This would perform the following action:

• Take the existing (possibly anonymous) user
• Link the provider to the existing user using an OIDC ID token for that provider

My use case for this feature:

• Currently I have an Apple OIDC ID token acquired using expo-apple-authentication
• There's no way to link the Apple provider to the previously created anonymous user using this OIDC ID

Attempted alternatives:

• Using linkIdentity is not great since this requires the use of a WebView in the app instead of using the native auth implementation provided by expo-apple-authentication
• signInWithIdToken creates an entirely new user, even if you're already signed in as an (anonymous) user, which is undesired for my use case