supabase/auth

Oauth fails when no email is linked to account

lunandd opened this issue ยท 24 comments

Feature request

Problem

Supabase Oauth relies on the assumption that users signing in with Oauth providers have an email linked to their account, which isn't always the case.

Solution

It would be nice if phone numbers could be used instead of email when using Oauth.

Example

An example is Facebook. If users haven't linked an email to their account they're screwed. This may turn off some from my app/website and lead them to using an alternate app/website

Related to this: supabase/supabase#2853

I'll move this to the GoTrue repo so that the auth team can comment ๐Ÿ‘

@kangmingtay - the related issue here has a lot of discussion. I'll leave it in the supabase repo for now but can shift it here if you prefer (or close this as a duplicate)

jtgi commented

Adding a +1 here. Ran into this adding Discord login. I'm working on crypto/web3 use cases so asking for email is unfortunately a no go.

Anything we can do to help? +1 as well for this

+1. Facing issue with Twitter Oauth when there is no email linked with the user account.

supabase/supabase#2853

Seems like this issue makes Supabase auth unusable for a large chunk of users...unfortunate because it's a big part of the value proposition.

I spent ages trying to debug this. I think in the meantime there should either be a) a big red flag in the docs on potentially effected providers (ran into it with Twitter in my case), or just flat out disabling those providers until there's a fix. Because it means that any provider where an email isn't guaranteed could fail randomly in production after testing during dev.

oespn commented

I'm experiencing the same issue. My accounts DO have emails so I think the root cause here is missing middleware to handle the additional request for the email from the API.

This maybe helpful:
https://auth0.com/rules/get-twitter-email

+1 for this, ran into the same issue with Twitter OAuth

Hi everyone! We've started to work on this issue and are aware that this is not ideal for anyone who wants to oauth as the primary login mechanism. The PR is mentioned above and feel free to ask any questions / add in your thoughts. We will do this in phases for each provider instead of all at once. The first phase will include twitter and facebook for now.

Currently, the main question I have is:

  1. Should a user who signs in with the oauth provider without an email address be automatically confirmed?

@kangmingtay I think if you are trusting a third party to vouch for their identity there is no reason to confirm them again. Maybe that is simplistic

Agree about confirmation, to me the whole point of oauth is handing off validation to a trusted 3rd party

Any updates on this PR? thanks :)

hey everyone, i've left a reply on the PR to explain why we have decided not to move forward with it yet: #414 (comment)

I'm glad there was work done for this.

Is there a workaround better than putting in a fake auto-confirmed email like user75555@oauthfakedomain.com?

Thanks for taking a look at this, @kangmingtay. I'm happy to brainstorm suggestions in the meantime. Still, regarding my project, this is a severe hold-up, and the feasible workaround is to revert to Firebase/some other provider until this is solved.

hf commented

@RichardAwoyemi Really sorry to hear that. We're working on quite a few things in the enterprise space this year and it's unlikely we'll be able to get to this. We are very aware of the issue and it is high on our agenda, but can't promise any timelines yet.

Any update in 2024? :) Thank you for your open source work by the way! ๐Ÿš€

I'd love to see this fixed as well.