Google and signInWithOAuth issues

[amcelroy]

I think there may be a bug or issue with the signInWithOAuth function.

Summary: When using signInWithOAuth using Google as the provider the tokens aren't being passed to the redirectTo link, and therefore the server endpoint, on a successful login.

Versions: "@supabase/supabase-js": "^2.42", "@supabase/auth-helpers-sveltekit": "^0.12.0"

Steps to reproduce:

1. Configure a Google cloud key following the directions here
2. Configure Supabase providers using the link provided in 1.
3. Configure a SvelteKit login +page.svelte that has the function tied to a button or link:

async function googleSignIn(){
  const { data, error } = await supabase.auth.signInWithOAuth({
	  provider: 'google',
	  options: {
		  queryParams: {
			  access_type: 'offline',
			  prompt: 'consent',
		  },
		  redirectTo: `http://localhost:5173/auth/callback`,
	  },
  });
}

4. Configure a +server.ts at the callback route. I used this tutorial. Set a breakpoint on the const code = ... line.
5. Launch a debug and try to login using Google. When the re-direct event happens, the breakpoint in 4 should fire.
6. Inspect the URL and note that there are no parameters passed with the link.

Why I think this is a bug?

Comment out the redirectTo line and add an onMount function to the login page created in step 3:

onMount(async () => {
console.log(window.location);
});

Reload the page and try logging in again. The console should report the URL with the Google OAuth response tokens:

Aren't these tokens supposed to be passed to the +server.ts endpoint and exchanged as in the example?

I have tried on both Chrome and Firefox using both http and https localhost servers. I have also added the redirectTo link to the callback URLs located in the project dashboard.

[encima]

Thanks for opening! Can you confirm a few things to help debug this:

• You have set the Redirect URL in GCloud to your project's callback?
• You mention 2 pages: page.svelte and server.ts, can you provide your directory structure?
• Have you followed the client setup guide before the guide in 1?

[amcelroy]

I should also mention that the Magic Email Link workflow is working with my own SMTP server, so there is a working login workflow and I have been able to access the database and do some basic testing to make sure one user can't access another users's data, so the API endpoints and getSession seem to be working as intended.

* You have set the Redirect URL in GCloud to your project's callback?

I think so, this is what my current credential callbacks look like. It is currently configured for https, but didn't work when configured with http either.

* You mention 2 pages: page.svelte and server.ts, can you provide your directory structure?

Sure, it is inherited from this tutorial to get started..

* Have you followed the [client setup guide](https://supabase.com/docs/guides/auth/server-side/creating-a-client) before the guide in 1?

No, I didn't see this page and some of the code looks a bit different. All of these were already configured from the starter project (see above).

hooks.server.ts

export const handle: Handle = async ({ event, resolve }) => {
  event.locals.supabase = createSupabaseServerClient({
    supabaseUrl: PUBLIC_SUPABASE_URL,
    supabaseKey: PUBLIC_SUPABASE_ANON_KEY,
    event,
  })

  /**
   * A convenience helper so we can just call await getSession() instead const { data: { session } } = await supabase.auth.getSession()
   */
  event.locals.getSession = async () => {

    let user = await event.locals.supabase.auth.getUser();

    const {
      data: { session },
    } = await event.locals.supabase.auth.getSession()
    return session
  }

  return resolve(event, {
    filterSerializedResponseHeaders(name) {
      return name === 'content-range'
    },
  })
}

Root layout, +laytout.ts:

// src/routes/+layout.ts
import { PUBLIC_SUPABASE_ANON_KEY, PUBLIC_SUPABASE_URL } from '$env/static/public'
import { createSupabaseLoadClient } from '@supabase/auth-helpers-sveltekit'

export const load = async ({ fetch, data, depends }) => {
  depends('supabase:auth')

  const supabase = createSupabaseLoadClient({
    supabaseUrl: PUBLIC_SUPABASE_URL,
    supabaseKey: PUBLIC_SUPABASE_ANON_KEY,
    event: { fetch },
    serverSession: data.session,
  })

  const {
    data: { session },
  } = await supabase.auth.getSession()

  return { supabase, session }
}

Root +layout.server.ts

// src/routes/+layout.server.ts
export const load = async ({ locals: { getSession } }) => {
    return {
      session: await getSession(),
    }
}

[Pierre-Saigot]

I have the same issue. I've properly set my 'redirectTo'; it even appears in the URL once on accounts.google.com. I've also properly configured my 'Redirect URLs' in Supase. But no matter what I do, it still redirects me to my Site URL after logging in, no matter what.

[lewsmith]

Was having the same issue.

Not sure if your issues are the same, but, initially I set my Redirect URLs in Supabase to the full domain + /auth/callback this always ended up with being redirect to https://site-url-domain/?code=... instead of the expected https://redirect-domain/auth/callback?code=...

The only way I managed to stop this is to remove the /auth/callback from the Redirect URL's (in Supabase) and replace with **. So instead of https://redirect-domain/auth/callback I use https://redirect-domain/**

Been working fine ever since.

[amcelroy]

I've tried using the ** approach and the token is still being stripped out by the time the +server.ts script is executed on the redirect. May I ask what versions of the Supabase libraries you are using? Are you using SvelteKit?

  "@supabase/auth-ui-svelte": "^0.2.9",
  "@supabase/ssr": "^0.3.0",
  "@supabase/supabase-js": "^2.42",

[lewsmith]

I've tried using the ** approach and the token is still being stripped out by the time the +server.ts script is executed on the redirect. May I ask what versions of the Supabase libraries you are using? Are you using SvelteKit?

  "@supabase/auth-ui-svelte": "^0.2.9",
  "@supabase/ssr": "^0.3.0",
  "@supabase/supabase-js": "^2.42",

@amcelroy I'm not using SveltKit, my app is built on remix. The versions I'm using are:

"@supabase/supabase-js": "2.42.1",
"@supabase/ssr": "^0.3.0",

[limaneto]

Was having the same issue.

Not sure if your issues are the same, but, initially I set my Redirect URLs in Supabase to the full domain + /auth/callback this always ended up with being redirect to https://site-url-domain/?code=... instead of the expected https://redirect-domain/auth/callback?code=...

The only way I managed to stop this is to remove the /auth/callback from the Redirect URL's (in Supabase) and replace with **. So instead of https://redirect-domain/auth/callback I use https://redirect-domain/**

Been working fine ever since.

Been facing the same issue, in my case the wildcard approach does not work, what supabase version you had there?

[hirayamahiroto]

Supabase OAuth Setup

1. Specifying the Callback URL
   When setting up OAuth with Supabase, it's crucial to specify the correct callback URL. This URL should point to a route in your application that will handle the authentication response.

2. Supabase Dashboard Configuration
   In the Supabase Dashboard, you need to whitelist the callback URL:

Navigate to Authentication -> URL Configuration
In the "Redirect URLs" section, add the exact URL you specified in the redirectTo option.
This step is crucial for security, as Supabase will only redirect to whitelisted URLs.

Supabase DadshBord Image

async function handleSocialLogin() {
    alert('handleSocialLogin');
    setIsLoading(true);
    setError(null);
    try {
      const { data, error } = await supabase.auth.signInWithOAuth({
        provider: 'google',
        options: {
          redirectTo:  `${window.location.origin}/api/auth/callback`,
          queryParams: {
            access_type: 'offline',
            prompt: 'consent',
          },
        },
      });
      if (error) throw error;
      alert(data);
    } catch (error) {
      console.error('Unexpected error:', error);
      setError(`An unexpected error occurred: ${error}`);
    } finally {
      setIsLoading(false);
    }

[yauri-io]

I'm experiencing exactly the same issue.
The redirection always go back to the '/' of the URL, doesn't matter what is the setting.

@hirayamahiroto thank you for the guide, but it is still not fixing the problem in my case.
In your screenshot, what is the content of the site URL? I guess it is http://loclahost:3000 ?

Update
For some reason, now it is working. I believe it is more related to the configuration in the Supabase redirect URL
This is my current setting

[hirayamahiroto]

@yauri-io

To allow all URLs after the domain:

https://{domain}/**
This configuration allows any path or subdirectory after the specified domain.

For example,

if you set https://example.com/**, it would allow https://example.com/anypath,
https://example.com/foo/bar, and so on.

To allow only specific links:

https://{domain}/{specific endpoint}
This method specifies individual endpoints.

For example:

https://example.com/api/auth/callback
https://example.com/login
https://example.com/dashboard

By adding these individually to the allowlist, you can restrict redirects to only the specified URLs.

This approach allows you to balance security and flexibility. Allowing all paths is convenient but increases security risks. On the other hand, allowing only specific URLs is more secure but requires updating the configuration each time you add a new endpoint.
It's important to choose the appropriate method based on your application's requirements and security policies.

Reference: https://supabase.com/docs/guides/auth/redirect-urls#use-wildcards-in-redirect-urls

[yauri-io]

@yauri-io

To allow all URLs after the domain:

https://{domain}/**

This configuration allows any path or subdirectory after the specified domain.

For example,

if you set https://example.com/**, it would allow https://example.com/anypath,

https://example.com/foo/bar, and so on.

To allow only specific links:

https://{domain}/{specific endpoint}

This method specifies individual endpoints.

For example:

https://example.com/api/auth/callback

https://example.com/login

https://example.com/dashboard

By adding these individually to the allowlist, you can restrict redirects to only the specified URLs.

This approach allows you to balance security and flexibility. Allowing all paths is convenient but increases security risks. On the other hand, allowing only specific URLs is more secure but requires updating the configuration each time you add a new endpoint.

It's important to choose the appropriate method based on your application's requirements and security policies.

Reference: https://supabase.com/docs/guides/auth/redirect-urls#use-wildcards-in-redirect-urls

Yes it is working now, thank you!

[BhandarkarPawan]

I had this issue as well. After spending the better part of a weekend trying to debug this, I finally managed to fix it as follows (I use Next.js)

1. Deleting the OAuth Credentials and creating new ones.
2. Ensure the minimum example works and I can login using email and pass
3. Add the Google auth function as follows (I use a client component for this)

  async function signInWithGoogle() {
    try {
      const redirectUrl = `${
        window.location.origin
      }/auth/callback?next=${encodeURIComponent(next || "/")}`;
      const { error } = await supabase.auth.signInWithOAuth({
        provider: "google",
        options: {
          redirectTo: redirectUrl,
        },
      });

      if (error) {
        throw error;
      }
    } catch (error) {
      toast({
        title: "Please try again.",
        description: "There was an error logging in with Google.",
        variant: "destructive",
      });
    }
  }

4. Here's my credential redirect URLs -
   

5. My Supabase (I understand the wildcard makes the first one redundant, but at his point I just want this to work and I'm too scared to remove it lol)
   

Things are finally working fine, but I honestly think the key here was to create new Google OAuth Credentials.

[Hallidayo]

Hi everyone, due to inactivity on this issue I've moved the issue over to discussions/enhancements.

[jpvarbed]

I still have this problem. I can't use supabase + svelte + google auth. I think the problem is with supabase as I never get the code

[junkaiman]

It is pretty much seems to be triggering an implicit flow instead of code flow. Seems like a skill issue for both of us @jpvarbed :(

hi @FaizPrasla , i got the same issue today. how can we explicitly use code flow instead of implicit flow?

[FaizPrasla]

Ok here do this it will save you hours I burnt hopefully. I am using NEXTJS

My issue was I was using supabase-js in the client file that's when when supabase was redirecting back to localhost it was giving me a fragment http://localhost:5173/auth/callback?next=%2F#access_token=eyJhbGciOiJIUzI instead of a code. After fixing step 1 I was able to get ->
http://localhost:5173/auth/callback?next=%2F?code.

1. /supabase/client make sure to have import { createBrowserClient } from "@supabase/ssr"; REMOVE import { createClient } from "@supabase/supabase-js" if you have this.

` /supabase/client code.
import { createBrowserClient } from "@supabase/ssr";

export const supabase = createBrowserClient(
process.env.NEXT_PUBLIC_SUPABASE_URL!,
process.env.NEXT_PUBLIC_SUPABASE_ANON_KEY!
);
`
2. Add the server and middleware file in supbase same the config instructions on supbase ssr instructions.

3. Google authorized domain add supabase domin. Add redirects as well for supabase redirect URL and localhost/auth/callback.

4. Supabase redirect auth(in supbase redirect url) -> Here as well add your localhost:3000/auth/callback or you can wildcard it localhost:3000/**

[junkaiman]

Thanks for your answer! I think I found out that I set wrong EXTERNAL_GOOGLE_REDIRECT_URI in my selfhosted supabase. It should be https://supabase.example.com/auth/v1/callback instead of nextjs api route https://example.com/api/v1/auth/callback.

[jilink]

@FaizPrasla I don't even know how to thank you, you just saved me after hours and hours of looking, asking chatgpt and not understanding what I did wrong ... Thanks! I wish you the best

[BradleyR87]

Thank you so much @FaizPrasla.. This is still the fix for Oauth on chrome in 2026

[yogithesymbian]

2026 i have same issue still not solved . local is work like a charm on my server its just shown as Web server is returning an unknown error