supabase: Twitter OAuth signup fails if user has no email on their twitter account

Bug report

Describe the bug

If a twitter user doesn’t have their email address connected to their twitter account, supabase’s twitter OAuth integration fails on signup with the message "Error getting user email from external provider’.

To Reproduce

I used the nextjs-auth-tailwind example and selected ‘twitter’ as the OAuth provider.

Then set up my supabase project and followed the steps to add twitter OAuth.

When I sign up with a twitter account that has an email address connected, it works fine.

When I try and sign up with a twitter account that doesn’t have an email address, I’m redirected back to the homepage with

?error=server_error&error_description=Error+getting+user+email+from+external+provider

appended to the URL. This is the same error that appears if you try and sign up with a fully-verified twitter account but don’t have ‘request email’ enabled.

I have obviously enabled ‘request email address’ in my twitter OAuth settings, as supabase also fails if this isn’t done. That said, it would be nice for this not to be necessary. Is this possible? Seems like it’d also fix this ‘bug’.

Expected behavior

For the user to sign up normally. My app doesn’t need a user’s email, just their twitter account.

Additional context

I’m not sure if this is by design, but it is semi-breaking for my app as many twitter users don’t have an email address. My app needs to be able to connect to the user’s twitter account to look up lists and tweets on their behalf, and I can’t do this if they don’t have a verified twitter account.

Perhaps there may be a temporary fix if I’m able to change what supabase does under the hood to convert the twitter authorization to a supabase user. I’m not too familiar with supabase so not too sure how to do this. That said, would like it to work regardless (but understand it may break supabase based on design decisions).

If this isn’t expected to be a super difficult fix, would appreciate being pointed in the right direction and can try and fix it myself (if it’s even considered a bug)

About this issue

Original URL
State: closed
Created 3 years ago
Reactions: 7
Comments: 16 (3 by maintainers)

Most upvoted comments

TLDR: all those who dont have email address on every social auth provider cannot use social auth provider right now.

+13

sandbox-apps on Aug 17, 2021

For me the issue with GitHub was because of a missing permission inside the GitHub Application. Just set the “email access” field to “read only” and it works as supposed.

+11

maximkott on Dec 16, 2021

I have also investigated this but have no time to post and explain. But here it is.

Problems:

Some External Auth Provider doesn’t require or provider email address
Supabase looks like extremely rely on email as Unique Identifier of User (Very problematic)

To explain: External auth provider nowadays doesn’t require email for their sign up process. Example FB and Twitter doesn’t require email, some user can sign up using phone numbers. Does this cause the bug explained by @fortydegrees above. This is very critical as I have encounter this issue when using firebase where I use security rules to require email but not knowing that emails are only really optional. The result? 1 to 3 stars rating from angry user for those who cant sign up because they dont have email address on their auth provider while others can sign up. This gives a bad impression to the app. And those people who cannot sign up are less likely to comeback again.

What is problematic here? If supabase heavily rely on user email as a unique identifier of user from external auth. They are doing it wrong. External providers return UID instead that must be the one to be used instead of email as a identifier. Now, I wonder if supabase is really saving the external provider auth uid or just the email. Because if its not, then all the existing user has no UID saved on supabase

In comparison with Firebase The user class of firebase auth has a list of provider field which is structured like this

displayName → String? (The users display name.)
email → String? (The users email address.)
phoneNumber → String? (Returns the users phone number.)
photoURL → String? (Returns a photo URL for the user.)
providerId → String (The federated provider ID.)
uid → String (The user's unique ID.)

Note: all question mark are optional/nullable because firebase doesnt expect other providers to return this from authentication instead they focus on providerId and uid.

providerId values are: ‘facebook’, ‘twitter’, ‘google’, ‘github’, ‘apple’, etc… while uid values are the uid of the user from the external providers.

What is the importance of this two fields? Now if we signed in via facebook for example -> we can look up on this fields uid and providerId

To know more about this: https://pub.dev/documentation/firebase_auth/latest/firebase_auth/User-class.html

I feel like you feel overconfident about one liner sign up/sign in process and overlook this kind of mistakes.

sandbox-apps on Aug 17, 2021

I’m facing a similar issue: I want to use the Twitter OAuth Provider, but I don’t want my users to be forced to show me their email address.

camiaei on Oct 27, 2021

One way to turn this bug into a feature request could be to let us choose what supabase does with the received data from the OAuth provider - like what data to request and store about the user. I assume this is similar to what firebase does, e.g. being able to map fields to our supabase auth system.

fortydegrees on Aug 17, 2021