Social Login (OAuth) User Metadata, Invite Shortcomings

[shellscape]

Bug report

I'm opening this as a bug because I view it as a rather large oversight, rather than a feature request.

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

Describe the bug

Both the social login system and the invite system seem to have a pretty big hole. The invite system can't use the social login for confirmation, and the social login system doesn't appear to provide any mechanism to provide custom user metadata for insertion into raw_user_meta_data when the auth.user record is created.

The latter need exists because the invites system can't use a social login, so we need some method of conveying metadata - like an invite code we hand roll - into the social login process for new users. We've considered multiple redirect, but that's very sloppy and doesn't play well with webhooks or triggers on auth.users.

The documentation site is just absolutely woeful (https://supabase.com/docs/reference/javascript/auth-signinwithpassword just states the type name with no information about the properties nor link to the type), but the types for the package here outline what's possible and what isn't with regard to user metadata during signup processes.

Nearly all of the signIn/signUp methods include the data option, as can be seen in the types: https://github.com/supabase/gotrue-js/blob/eb96536a441d21fae75d25ab6de346808c6e6044/src/lib/types.ts#L389-L395

Even the Invite and Magic Link methods include the data options: https://github.com/supabase/gotrue-js/blob/eb96536a441d21fae75d25ab6de346808c6e6044/src/lib/types.ts#L539-L544

Except of course, for signInWithOAuth: https://github.com/supabase/gotrue-js/blob/eb96536a441d21fae75d25ab6de346808c6e6044/src/lib/types.ts#L440-L453

Now, granted that allowing the invite system to utilize social/oauth logins would probably be a massive lift, we could in theory get around that by providing metadata to a data option to signInWithOAuth which could contain an invite code with instructions for any webhooks or triggers on the auth.users table.

What about redirectTo then? Well, that's certainly less than optimal. If we were able to use data the workflow would look like this:

• call signInWithOAuth with data: { inviteCode }
• social login process completes
• auth.users is updated with new user record
• a trigger is executed and public.profiles is updated nearly instantaneously with data from the inviteCode

Using redirectTo the process takes a completely different shape, without the same speed or fidelity:

• call signInWithOAuth with redirectTo containing a query param with an inviteCode
• social login process completes
• auth.users is updated with new user record
• client is redirected back to the application to an interstitial page
• interstitial page calls an API to update the use that was created, transmitting the inviteCode to update public.profiles
• interstitial page waits for a response, and then redirects to the signup-successful page

It's pretty clear that the power and utility of supabase is being neutered by the latter process. Additional redirects aren't a great user experience and are prone to error.

I've been a big proponent of supabase for a few years now publicly and with companies that I've worked for, and this has the potential to convince the leadership for this particular project to look elsewhere for solutions - something I'm pushing back against strongly. That's not intended to be negatively motivating in any way; I simply want to convey the severity of concern around this particular issue. I hope maintainers here will give this earnest consideration.

To Reproduce

n/a

Expected behavior

The data option to exist and be function for SignInWithOAuthCredentials

Screenshots

n/a

System information

• OS: [e.g. macOS, Windows] MacOS Ventura
• Browser (if applies) [e.g. chrome, safari]
• Version of supabase-js: latest
• Version of Node.js: 18.15.0

Additional context

Add any other context about the problem here.

[kangmingtay]

Hey @shellscape, thanks for taking the time to provide such a detailed write-up of the issue. There's actually already some existing code in gotrue which handles processing invites for an oauth signin. This isn't well-documented yet, and definitely has a different intended behaviour since it was mainly carried over from the original netlify gotrue repo.

If you want the invite email sent to the user to include a link that allows them to sign in with oauth, the current workaround would be to create a customised link through the email template. For example:

<p><a href="https://project_ref.supabase.co/auth/v1/authorize?provider=azure&invite_token={{ .TokenHash }}">Accept the invite</a></p>

There are a few limitations to this approach:

1. The provider is fixed, which means that the invitee is forced to use that specific oauth provider to accept the invite.
2. The invited email has to match the email used by the oauth provider. This is mainly for security reasons. For example, it would be misleading behaviour to send the invite link to foo@example.com and observe bar@example.com accept the invite link through sign in with google.

Granted, this isn't great in terms of DX. You should be able to choose which oauth provider to sign in with. You can get around this by doing the following:

<p><a href="{{ .SiteURL }}/accept-invite?invite_token={{ .TokenHash }}">Accept the invite</a></p>

This approach redirects the user, upon clicking the link, to a page in your application. This would, ideally, be your sign-in page with your chosen list of oauth providers. You can grab the invite_token from the query parameter and append it to the following url: https://project_ref.supabase.co/auth/v1/authorize?provider={provider}&invite_token={invite_token} where the project_ref is your supabase project ref and the provider is based on the provider selected by the user. This would be my preferred method of accepting an invite link through an oauth sign-in currently.

However, it's definitely not ideal yet because of the following problems:

1. You need to create a page in your app to handle parsing the invite_token
2. You need to create the url (https://project_ref.supabase.co/auth/v1/authorize?provider={provider}&invite_token={invite_token}) on your own.

(1) can be solved when we implement hosted pages for auth while (2) can be solved very easily - i'll add an invite_token to the SignInWithOAuthCredentials type so that you can call the signInWithOAuth() method instead.

TLDR: You will need to do the following:

1. Modify the email link sent in your invite email template to redirect the user to your sign-in page with the invite_token as the query parameter
2. Call the signInWithOAuth() method with the provider and invite_token

Let me know what you think of this approach and if you have any feedback about it.

Edit: PR #682 contains a react example with the invite token changes for signInWithOAuth - you can reference this for your implementation if necessary

[kangmingtay]

As for sending custom user metadata through signInWithOAuth, i think it should be possible to send it via the state query param during the oauth2.0 flow. To keep this consistent with signInWithOtp() and signUp(), we will only allow sending the custom user metadata the first time the user is created through signInWithOAuth. Subsequent attempts to update the user_metadata should be done with supabase.auth.updateUser().

Currently, you can also handle this with a 2 step approach:

1. Call the supabase.auth.signInWithOAuth() method with the redirectTo option set to a page in your app that prompts to user to fill in some custom metadata.
2. Call the supabase.auth.updateUser()method with the custom user_metadata

[mlawlerau]

I too think it would be nice to be able to send custom user metadata through signInWithOAuth.

[albertonii]

I also had the same problem as @kangmingtay mentioned.
Each time a user is created a fuction in Supabase is triggered to create new table rows when sign up with Email - Password.
But in SignInWithOAuth (using Google in my case) there is always an error while creating the user because there is no raw_user_meta_data // raw_app_meta_data information, this is achieved through data object included in .signIn( ) supabase call (I'm using NextJS and @supabase/supabase-js @supabase/ssr libraries).

Including this data object in the method will help us all :)

[sk0le]

Hello, I'm having the same request. I need to pass some stuff with signInWithOAuth. Could you please tell me if this has been added? Thanks.