Allow configuration of OAuth2 redirect domain in hosted supabase console

[heysailor]

Feature request

Is your feature request related to a problem? Please describe.

In the OAuth 2 authentication flow, a user is redirected to the supabase.co domain in the callback step. Google in particular shows this to the user with the message 'Enter your password to continue to supabase.co' - which is confusing for the user, given they are coming from a domain with a different name and probably don't know what supabase is (a pity, of course!).

The second problem is identified in this issue: Unable to use Google OAuth in production - we are unable to verify a Google OAuth2 client, as we can't verify the supabase.co domain which must be included in a list of allowed callbacks. Therefore we must use an unverified client - with a limit on users.

Describe the solution you'd like

When supabase.co/auth/v1/authorize is called for an OAuth2 flow, it sets the callback to [myproject].supbase.co/v1/auth/callback - but it would solve the above problems if the callback was configurable to a proxy, eg auth.[mydomain]/callback

I already mask the supabase.co project auth API (via a Vercel rewrite) - so for example, authentication requests go through auth.[mydomain]/authorize - which is then proxied to [myproject].supabase.co/auth/v1/authorize. This is handy for React Native, which asks the user if it's OK to proceed to auth.[mydomain] before opening a browser to complete an authentication session - which would be confusing to users if it asked to go to supabase instead.

It appears the underlying GoTrue server is configured to use a callback URL with a EXTERNAL_X_URL environment variable which is presumably set to [myproject].supbase.co/v1/auth/callback.

If the Supabase console allowed setting the callback location to an URL that proxies to the GoTrue server, that would solve the above problems - users would not get confused about what they are logging into, and Google verification would be possible.

Describe alternatives you've considered

...supporting custom domains globally for a Pro plan!

[awalias]

hey! have moved this to the gotrue repo.

you're spot on in your assessment of the solution @heysailor :)

once we add the option to the dashboard you should be able to set some proxy URLs

for this one:

Therefore we must use an unverified client - with a limit on users.

I believe it's only needed to verify if you are using restricted or sensitive scope, and there is also a mechanism for having the requirement waived if you are using a platform (like supabase). Regardless, it should also be solved by the solution you proposed 👍

[heysailor]

Thanks @awalias

I believe it's only needed to verify if you are using restricted or sensitive scope, and there is also a mechanism for having the requirement waived if you are using a platform (like supabase). Regardless, it should also be solved by the solution you proposed 👍

You're correct, verification is only needed for restricted or sensitive scopes - although also if you want to display a logo on the consent page, so it's nice to have. Can't see anywhere an allowance for using a platform.

Proxy support, or custom domains, would be ace. Cheers

[kachar]

We're falling in the same scenario and we're unable to verify the supabase callback domains during google auth consent screen verification:

The only info we're were able to gather on the topic from Google was:

Note: If you are using a third party service provider and your domain is owned by them, then you need to provide a detailed justification for us to validate it.

https://support.google.com/cloud/answer/9110914?hl=en#how-smooth&zippy=%2Chow-can-i-make-sure-the-verification-process-is-as-streamlined-as-possible

[vamonke]

I'm currently on the Free plan of supabase but I'll gladly upgrade to Pro plan just for this feature 🥺

[wyatt]

The only info we're were able to gather on the topic from Google was:

Note: If you are using a third party service provider and your domain is owned by them, then you need to provide a detailed justification for us to validate it.

Have you found any way to provide said justification. I'm in the process of verifying, and I can't see any way to submit a justification for using a 3rd party domain

[heysailor]

For those coming to this later: It’s not terribly well documented on the Google side - you only need to verify a domain with them if you have a custom icon. If you already have an icon, it’s quite tricky to remove it, yes truly. There are some hacks to achieve it, but I found it was simplest to remove the project and make a new one.

[wyatt]

After a bit of back and forth with Google, explaining what Supabase was, and why I needed those domains verified, they finally verified my site. I referenced the link @kachar mentioned, and now I've got a verified OAuth page in production.

IT CAN BE DONE! 🎉🎉🎉

[EmilePW]

@wyatt - I've just been through the same back and forth explaining what Supabase is and had my verification request rejected (after 7 fairly unhelpful template emails from Google). I'm going to try and resubmit with the icon removed as @heysailor suggested; was there anything else in particular you did to get it through?

[heysailor]

Ugh that sounds hard work!

I didn't try to get verification - I just made a new project, without an OAuth icon, which therefore didn't need verification.

This situation of not needing verification is covered in the Google OAuth FAQ listed here - check under the "When does my app need to be verified by Google?" section. If you don't do any of the things listed there, you're free as a bird.

[EmilePW]

@heysailor Oh I see - in my case I'm using sensitive scopes so I'll still need some kind of verification. I'm just going to try again anyway - seems like there's some randomness depending on whose reading the application so I'll just hope it works this time.

@wyatt - did you have sensitive scopes in your case?

[EmilePW]

For anyone whose found this thread and has the same problem as me where verification is required, the way I got around it was to create two separate OAuth clients; one for Supabase with the basic scopes so that it doesn't require verification (and no logo added, as above) and another with my own domain with the sensitive scopes. This way you can still easily integrate Google OAuth with Supabase for login/signup and then have incremental auth where you ask for permission with the second client as necessary.

[dhruvbhatia7]

This is great @EmilePW, thanks for the insight. I'll try the 2 client strategy when I need to access sensitive scopes later.

[jordn]

Does anyone have a solution to the first problem: getting the Google Oauth flow to say to continue to MYDOMAIN.COM rather than the scary looking supabase app name?

I am hoping to migrate a substantial app over to supabase but this is a blocker for me as I think this message would scare users away

[connorlindsey]

Can confirm that users find this sketchy 😅 would be amazing to get this resolved, even if it's a hacky solution to start

[LittlePouch]

I also got feedback that the "random letter domain" makes users feel uncomfortable to log in

[tourbillonlabs]

Does this help you? supabase/supabase#2925 (comment)

I've had two apps approved using the steps I described and it now shows "to continue to ". When you get to the bit about removing the supabase items in "under Authorised Domains, ensure only your owned domains are in the list. If you see Supabase, clear the field and delete that line item" I really do mean clear that field. Put your cursor in, highlight and delete the text so there's nothing in it, and then hit the trash button.

[LittlePouch]

@tourbillonlabs Thanks, I'm trying that. I started the verification, we'll see how it goes. But I must say this is process quite confusing,

[tourbillonlabs]

@LittlePouch Yeah. Swiftness of the process does seem to depend on which agent you get. My first attempt took 17 emails total and it's because they kept canned response-ing me and the wording was so subtle that I missed what they were getting at. Once I figured out the Authorised domains thing it went quickly. The second time I ticked all the boxes ahead, and only the button branding caught me out. But after I fixed that, success. I did reference the previously approved app in the application, so I'm not sure if that expedited as well.

Good luck!

[Benjamin-Dobell]

Just discovered this issue. I've implemented a solution at #725

I should note there's no UI component required for the solution. Rather you provide the proxy URL as an option of your signInWithOAuth call. In my case this is much more preferable than an additional option in Supabase as I've actually got the same server/app handling multiple domains and I want to be able to make this decision at runtime.

supabase/auth-js#466

[J0]

Hey all,

We now offer custom domains as an add on for our Pro plan. Going to close this issue for now but let me know if there are still unresolved concerns.

Thanks!

[laygir]

too bad this landed as a monthly paid add-on instead of a new feature for already paying pro plans customers 🐻