github-starred/better-auth
2
0
Fork 0
mirror of https://github.com/better-auth/better-auth.git synced 2026-05-22 14:21:55 -05:00
Code Issues 2.5k Packages Projects Releases 112 Wiki Activity

Expo + Google social integration not redirecting with auth code after picking/signing into Google account #1735

New Issue
Closed
opened 2026-03-13 08:59:31 -05:00 by GiteaMirror · 5 comments
GiteaMirror commented 2026-03-13 08:59:31 -05:00
Owner
Copy Link

Originally created by @skempisty on GitHub (Aug 18, 2025).

Is this suited for github?

  • Yes, this is suited for github

To Reproduce

  1. Create a Nextjs backend and configure better-auth with the Prisma + Postgresql adapter and Google social provider as specified in the server-side code below.

  2. Create an Expo frontend and configure the authClient using @better-auth/react and the @better-auth/expo/client plugin, ensuring expo-secure-store is integrated.

  3. Implement a login screen with a button that triggers the authClient.signIn.social({ provider: "google", callbackURL: "/" }) function.

  4. Run the application, press the "Sign In With Google" button, and complete the authentication flow in the browser that opens.

  5. After successful authentication, no further requests hit my server. Phone browser gets redirected to localhost:3000 (see screenshot).

Image

Extra context: I can attempt the same procedure from my web app and the request I get after successfully logging in on google looks like:

/api/auth/callback/google?state=DiGDuJT4eVpZ45dtxURqIyFLHXWPlZhr&code=4%2F0AVMBsJhMZ_btJbekpfxIzUO5PDZ24YpqVFzEwdVC6bypgFhjFSkVTlJf96LgPyp1dtx4Lg&scope=email+profile+openid+https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fuserinfo.email+https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fuserinfo.profile&authuser=0&prompt=none

which I think proves that my google integration is setup correctly (At least for web). This flow successfully creates the session and logs me in.

Current vs. Expected behavior

Current Behavior:
After completing Google OAuth authentication in the browser, the phone browser gets redirected to localhost:3000 instead of back to the Expo app. No callback requests reach the server, and the authentication session is not established in the mobile app.

Expected Behavior:
After Google OAuth authentication, the browser should redirect back to the Expo app using a custom URL scheme, trigger the callback to /api/auth/callback/google on the server, and successfully establish the authenticated session within the mobile app.

What version of Better Auth are you using?

1.3.7

System info

System:
    OS: macOS 14.6.1
    CPU: (8) arm64 Apple M1 Pro
    Memory: 180.20 MB / 16.00 GB
    Shell: 5.9 - /bin/zsh
Browsers:
    Chrome: 139.0.7258.128
    Safari: 17.6

Which area(s) are affected? (Select all that apply)

Client, Backend

Auth config (if applicable)

**Client-Side Config (`/lib/auth-client.ts`)**

import { createAuthClient } from "better-auth/react";
import { expoClient } from "@better-auth/expo/client";
import * as SecureStore from "expo-secure-store";

export const authClient = createAuthClient({
  baseURL: "http://192.168.1.205:3000", // Base URL of your Better Auth backend.
  basePath: "/api/auth",
  plugins: [
    expoClient({
      scheme: 'seent-dev',
      storagePrefix: "seent-auth",
      storage: SecureStore,
    }),
  ]
});

**Server-Side Config (`@/libs/auth.ts`)**

import { betterAuth } from "better-auth"
import { prismaAdapter } from "better-auth/adapters/prisma";
import { expo } from "@better-auth/expo";
import prisma from "./prisma";

export const auth = betterAuth({
  database: prismaAdapter(prisma, {
    provider: "postgresql",
  }),
  baseURL: process.env.BETTER_AUTH_URL || "http://localhost:3000",
  plugins: [expo()],
  trustedOrigins: [
    "http://localhost:3000",
    "seent-dev://",
    "seent://",
  ],
  emailAndPassword: {
    enabled: true,
  },
  socialProviders: {
    google: {
      clientId: process.env.GOOGLE_CLIENT_ID as string,
      clientSecret: process.env.GOOGLE_CLIENT_SECRET as string,
    },
  },
});

Additional context

No response

Originally created by @skempisty on GitHub (Aug 18, 2025). ### Is this suited for github? - [x] Yes, this is suited for github ### To Reproduce 1. Create a Nextjs backend and configure better-auth with the Prisma + Postgresql adapter and Google social provider as specified in the server-side code below. 2. Create an Expo frontend and configure the authClient using @better-auth/react and the @better-auth/expo/client plugin, ensuring expo-secure-store is integrated. 3. Implement a login screen with a button that triggers the authClient.signIn.social({ provider: "google", callbackURL: "/" }) function. 4. Run the application, press the "Sign In With Google" button, and complete the authentication flow in the browser that opens. 5. After successful authentication, no further requests hit my server. Phone browser gets redirected to localhost:3000 (see screenshot). ![Image](https://github.com/user-attachments/assets/499efedc-2720-4c6f-903a-7797f48d6312) Extra context: I can attempt the same procedure from my web app and the request I get after successfully logging in on google looks like: ``` /api/auth/callback/google?state=DiGDuJT4eVpZ45dtxURqIyFLHXWPlZhr&code=4%2F0AVMBsJhMZ_btJbekpfxIzUO5PDZ24YpqVFzEwdVC6bypgFhjFSkVTlJf96LgPyp1dtx4Lg&scope=email+profile+openid+https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fuserinfo.email+https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fuserinfo.profile&authuser=0&prompt=none ``` which I think proves that my google integration is setup correctly (At least for web). This flow successfully creates the session and logs me in. ### Current vs. Expected behavior **Current Behavior:** After completing Google OAuth authentication in the browser, the phone browser gets redirected to localhost:3000 instead of back to the Expo app. No callback requests reach the server, and the authentication session is not established in the mobile app. **Expected Behavior:** After Google OAuth authentication, the browser should redirect back to the Expo app using a custom URL scheme, trigger the callback to /api/auth/callback/google on the server, and successfully establish the authenticated session within the mobile app. ### What version of Better Auth are you using? 1.3.7 ### System info ```bash System: OS: macOS 14.6.1 CPU: (8) arm64 Apple M1 Pro Memory: 180.20 MB / 16.00 GB Shell: 5.9 - /bin/zsh Browsers: Chrome: 139.0.7258.128 Safari: 17.6 ``` ### Which area(s) are affected? (Select all that apply) Client, Backend ### Auth config (if applicable) ```typescript **Client-Side Config (`/lib/auth-client.ts`)** import { createAuthClient } from "better-auth/react"; import { expoClient } from "@better-auth/expo/client"; import * as SecureStore from "expo-secure-store"; export const authClient = createAuthClient({ baseURL: "http://192.168.1.205:3000", // Base URL of your Better Auth backend. basePath: "/api/auth", plugins: [ expoClient({ scheme: 'seent-dev', storagePrefix: "seent-auth", storage: SecureStore, }), ] }); **Server-Side Config (`@/libs/auth.ts`)** import { betterAuth } from "better-auth" import { prismaAdapter } from "better-auth/adapters/prisma"; import { expo } from "@better-auth/expo"; import prisma from "./prisma"; export const auth = betterAuth({ database: prismaAdapter(prisma, { provider: "postgresql", }), baseURL: process.env.BETTER_AUTH_URL || "http://localhost:3000", plugins: [expo()], trustedOrigins: [ "http://localhost:3000", "seent-dev://", "seent://", ], emailAndPassword: { enabled: true, }, socialProviders: { google: { clientId: process.env.GOOGLE_CLIENT_ID as string, clientSecret: process.env.GOOGLE_CLIENT_SECRET as string, }, }, }); ``` ### Additional context _No response_
GiteaMirror added the social-providerexpo labels 2026-03-13 08:59:31 -05:00
GiteaMirror commented 2026-03-13 08:59:34 -05:00
Author
Owner
Copy Link

@dosubot[bot] commented on GitHub (Aug 18, 2025):

Hi @skempisty! I'm Dosu and I’m helping the better-auth team.

The redirect to localhost:3000 after Google sign-in in Expo is usually caused by a misconfiguration of the OAuth redirect URI and deep linking setup. For Expo + Better Auth, Google should redirect to your backend (e.g., http://192.168.1.205:3000/api/auth/callback/google), not directly to your app's custom scheme. The backend then completes the OAuth flow and redirects to your Expo app using the custom scheme deep link (like seent-dev://...), passing the session cookie as a query parameter. This is handled by Better Auth's Expo integration and requires the following setup:

  1. In the Google Cloud Console, register your backend callback URL (e.g., http://192.168.1.205:3000/api/auth/callback/google) as the authorized redirect URI—not your custom scheme deep link. Google does not allow custom schemes as redirect URIs "Google does not allow custom URI schemes".
  2. Make sure your Expo app's scheme (e.g., seent-dev) is set in app.json and matches the scheme in your Better Auth server config's trustedOrigins (e.g., seent-dev://) "Checklist for troubleshooting".
  3. The Expo client plugin automatically converts callback URLs starting with / to deep links using your scheme, and expects the backend to append the session cookie to the deep link "expoClient plugin deep link handling".
  4. After sign-in, check that the deep link reopening your app contains a cookie query parameter. If missing, the backend may not be appending it due to a trustedOrigins mismatch "Backend plugin appends cookie to deep link".
  5. Confirm that SecureStore is saving the cookie (e.g., seent-auth_cookie). If the session is still null, call await authClient.getSession() after redirect to force a refresh "Session refresh workaround".

If you still see the browser redirecting to localhost:3000, double-check the redirect URI registered with Google and the scheme/trustedOrigins setup. For local dev, using a domain like lvh.me or your LAN IP instead of localhost can help avoid redirect issues "Localhost redirect URI issues".

If the deep link is missing the cookie, or SecureStore isn't saving it, log the full deep link URL and the cookie value after sign-in to help pinpoint where the flow is breaking "Deep link and cookie troubleshooting".

To reply, just mention @dosu.

How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other  Chat with Dosu Join Discord Share on X

@dosubot[bot] commented on GitHub (Aug 18, 2025): <!-- Greeting --> Hi @skempisty! I'm [Dosu](https://go.dosu.dev/dosubot) and I’m helping the better-auth team. <!-- Answer --> The redirect to `localhost:3000` after Google sign-in in Expo is usually caused by a misconfiguration of the OAuth redirect URI and deep linking setup. For Expo + Better Auth, Google should redirect to your backend (e.g., `http://192.168.1.205:3000/api/auth/callback/google`), not directly to your app's custom scheme. The backend then completes the OAuth flow and redirects to your Expo app using the custom scheme deep link (like `seent-dev://...`), passing the session cookie as a query parameter. This is handled by Better Auth's Expo integration and requires the following setup: 1. In the Google Cloud Console, register your backend callback URL (e.g., `http://192.168.1.205:3000/api/auth/callback/google`) as the authorized redirect URI—not your custom scheme deep link. Google does not allow custom schemes as redirect URIs ["Google does not allow custom URI schemes"](https://github.com/better-auth/better-auth/issues/3781#issuecomment-3151732646). 2. Make sure your Expo app's scheme (e.g., `seent-dev`) is set in `app.json` and matches the scheme in your Better Auth server config's `trustedOrigins` (e.g., `seent-dev://`) ["Checklist for troubleshooting"](https://github.com/better-auth/better-auth/discussions/3982#discussioncomment-14096720). 3. The Expo client plugin automatically converts callback URLs starting with `/` to deep links using your scheme, and expects the backend to append the session cookie to the deep link ["expoClient plugin deep link handling"](https://github.com/better-auth/better-auth/blob/06b1da293e615b3670643be4a015f415fb561170/packages/expo/src/client.ts). 4. After sign-in, check that the deep link reopening your app contains a `cookie` query parameter. If missing, the backend may not be appending it due to a trustedOrigins mismatch ["Backend plugin appends cookie to deep link"](https://github.com/better-auth/better-auth/blob/06b1da293e615b3670643be4a015f415fb561170/packages/expo/src/index.ts). 5. Confirm that SecureStore is saving the cookie (e.g., `seent-auth_cookie`). If the session is still null, call `await authClient.getSession()` after redirect to force a refresh ["Session refresh workaround"](https://github.com/better-auth/better-auth/issues/3711). If you still see the browser redirecting to `localhost:3000`, double-check the redirect URI registered with Google and the scheme/trustedOrigins setup. For local dev, using a domain like `lvh.me` or your LAN IP instead of `localhost` can help avoid redirect issues ["Localhost redirect URI issues"](https://github.com/better-auth/better-auth/issues/3781). If the deep link is missing the cookie, or SecureStore isn't saving it, log the full deep link URL and the cookie value after sign-in to help pinpoint where the flow is breaking ["Deep link and cookie troubleshooting"](https://github.com/better-auth/better-auth/issues/3711#issuecomment-3139342052). <!-- Dosu Comment Footer --> *To reply, just mention [@dosu](https://go.dosu.dev/dosubot).* --- <sup>How did I do? [Good](https://app.dosu.dev/response-feedback/c3f2718c-eb4f-403f-9c25-4621906daa81?feedback_type=great_response) | [Irrelevant](https://app.dosu.dev/response-feedback/c3f2718c-eb4f-403f-9c25-4621906daa81?feedback_type=irrelevant_answer) | [Incorrect](https://app.dosu.dev/response-feedback/c3f2718c-eb4f-403f-9c25-4621906daa81?feedback_type=incorrect_sources) | [Verbose](https://app.dosu.dev/response-feedback/c3f2718c-eb4f-403f-9c25-4621906daa81?feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/c3f2718c-eb4f-403f-9c25-4621906daa81?feedback_type=hallucination) | [Report 🐛](https://app.dosu.dev/response-feedback/c3f2718c-eb4f-403f-9c25-4621906daa81?feedback_type=bug_report) | [Other](https://app.dosu.dev/response-feedback/c3f2718c-eb4f-403f-9c25-4621906daa81?feedback_type=other)</sup>&nbsp;&nbsp;[![Chat with Dosu](https://dosu.dev/dosu-chat-badge.svg)](https://app.dosu.dev/cdda13d9-dd27-4d31-b09a-5d8bec92de21/ask?utm_source=github)&nbsp;[![Join Discord](https://img.shields.io/badge/join-5865F2?logo=discord&logoColor=white&label=)](https://go.dosu.dev/discord-bot)&nbsp;[![Share on X](https://img.shields.io/badge/X-share-black)](https://twitter.com/intent/tweet?text=%40dosu_ai%20helped%20me%20solve%20this%20issue!&url=https%3A//github.com/better-auth/better-auth/issues/4070)
GiteaMirror commented 2026-03-13 08:59:35 -05:00
Author
Owner
Copy Link

@skempisty commented on GitHub (Aug 18, 2025):

@dosu

In the Google Cloud Console, register your backend callback URL (e.g., http://192.168.1.205:3000/api/auth/callback/google) as the authorized redirect URI—not your custom scheme deep link. Google does not allow custom schemes as redirect URIs https://github.com/better-auth/better-auth/issues/3781#issuecomment-3151732646.

Using the IP address like that in a google authorized redirect url isn't allowed. See screenshot

Image

Besides, having "http://localhost:3000/api/auth/callback/google" as a authorized redirect URL does work for my web app so I'm not sure this is the problem - and my mobile app does let me get to the google signin screen.

Make sure your Expo app's scheme (e.g., seent-dev) is set in app.json and matches the scheme in your Better Auth server config's trustedOrigins (e.g., seent-dev://) https://github.com/better-auth/better-auth/discussions/3982#discussioncomment-14096720.

The app's scheme is set properly, however I am using a "app.config.js" rather than a app.json file. As I wrote, "seent-dev://" is part of my trustedOrigins. For context, originally I was actually seeing that the provided scheme wasn't matching and I was getting a console warning for it, but now I've corrected that and I get no warning about it anymore. I had an issue where the Info.plist had outdated schemes which was resolved with a rebuild.

The Expo client plugin automatically converts callback URLs starting with / to deep links using your scheme, and expects the backend to append the session cookie to the deep link "expoClient plugin deep link handling".

My server is not receiving any request after completing sign-in on the Google side, so I'm not sure if this part is functioning correctly.

After sign-in, check that the deep link reopening your app contains a cookie query parameter. If missing, the backend may not be appending it due to a trustedOrigins mismatch "Backend plugin appends cookie to deep link".

Again, my server isn't receiving any request.

Confirm that SecureStore is saving the cookie (e.g., seent-auth_cookie). If the session is still null, call await authClient.getSession() after redirect to force a refresh https://github.com/better-auth/better-auth/issues/3711.

Again, my server isn't receiving any request.

If you still see the browser redirecting to localhost:3000, double-check the redirect URI registered with Google and the scheme/trustedOrigins setup. For local dev, using a domain like lvh.me or your LAN IP instead of localhost can help avoid redirect issues https://github.com/better-auth/better-auth/issues/3781.

I don't think this is the issue - I am not getting that "Access blocked: This app's request is invalid" screen. I get the google login screen as expected and I'm able to select my account. After I do that however, my webview browser goes to localhost and my server receives no requests.

@skempisty commented on GitHub (Aug 18, 2025): @dosu > In the Google Cloud Console, register your backend callback URL (e.g., http://192.168.1.205:3000/api/auth/callback/google) as the authorized redirect URI—not your custom scheme deep link. Google does not allow custom schemes as redirect URIs https://github.com/better-auth/better-auth/issues/3781#issuecomment-3151732646. Using the IP address like that in a google authorized redirect url isn't allowed. See screenshot <img width="493" height="110" alt="Image" src="https://github.com/user-attachments/assets/a71e520f-b27a-480f-ae86-8cc3016525f9" /> Besides, having "http://localhost:3000/api/auth/callback/google" as a authorized redirect URL does work for my web app so I'm not sure this is the problem - and my mobile app does let me get to the google signin screen. > Make sure your Expo app's scheme (e.g., seent-dev) is set in app.json and matches the scheme in your Better Auth server config's trustedOrigins (e.g., seent-dev://) https://github.com/better-auth/better-auth/discussions/3982#discussioncomment-14096720. The app's scheme is set properly, however I am using a "app.config.js" rather than a app.json file. As I wrote, "seent-dev://" is part of my trustedOrigins. For context, originally I was actually seeing that the provided scheme wasn't matching and I was getting a console warning for it, but now I've corrected that and I get no warning about it anymore. I had an issue where the Info.plist had outdated schemes which was resolved with a rebuild. > The Expo client plugin automatically converts callback URLs starting with / to deep links using your scheme, and expects the backend to append the session cookie to the deep link ["expoClient plugin deep link handling"](https://github.com/better-auth/better-auth/blob/06b1da293e615b3670643be4a015f415fb561170/packages/expo/src/client.ts). My server is not receiving any request after completing sign-in on the Google side, so I'm not sure if this part is functioning correctly. > After sign-in, check that the deep link reopening your app contains a cookie query parameter. If missing, the backend may not be appending it due to a trustedOrigins mismatch ["Backend plugin appends cookie to deep link"](https://github.com/better-auth/better-auth/blob/06b1da293e615b3670643be4a015f415fb561170/packages/expo/src/index.ts). Again, my server isn't receiving any request. > Confirm that SecureStore is saving the cookie (e.g., seent-auth_cookie). If the session is still null, call await authClient.getSession() after redirect to force a refresh https://github.com/better-auth/better-auth/issues/3711. Again, my server isn't receiving any request. > If you still see the browser redirecting to localhost:3000, double-check the redirect URI registered with Google and the scheme/trustedOrigins setup. For local dev, using a domain like lvh.me or your LAN IP instead of localhost can help avoid redirect issues https://github.com/better-auth/better-auth/issues/3781. I don't think this is the issue - I am not getting that "Access blocked: This app's request is invalid" screen. I get the google login screen as expected and I'm able to select my account. After I do that however, my webview browser goes to localhost and my server receives no requests.
GiteaMirror commented 2026-03-13 08:59:35 -05:00
Author
Owner
Copy Link

@dosubot[bot] commented on GitHub (Aug 18, 2025):

This happens because Google only allows redirect URIs that are public domains or localhost—not private IPs or custom schemes. On mobile, when the OAuth flow tries to redirect to localhost:3000, the device can't reach your backend, so the callback never hits your server and the Expo flow can't complete. This is a platform limitation, not a Better Auth bug.

For local development, you need your backend to be accessible from your mobile device using a domain Google accepts. The usual solutions are: use a tunneling service like ngrok to expose your backend and register the ngrok HTTPS URL as your Google redirect URI, or use a local domain like lvh.me mapped to 127.0.0.1 (if your device can resolve it and reach your machine). Private IPs (like 192.168.x.x) are not accepted by Google for OAuth redirect URIs, even if they work for direct API calls.

If you can't use a tunnel or public domain, you won't be able to complete the OAuth flow on mobile with Google. As a workaround for local dev, you could use native Google sign-in in Expo and send the ID token to your backend for verification, but that's a different flow.

Checklist: make sure your backend is reachable from your device, use a valid public domain or tunnel for the redirect URI, confirm your trustedOrigins and scheme config, and verify that after sign-in, the deep link contains the cookie parameter and SecureStore is saving it. The Expo plugin and Better Auth backend are designed to handle the deep link/cookie flow, but only after the backend receives the OAuth callback from Google—which requires a valid, reachable redirect URI.
Expo plugin code reference | Backend plugin code reference

To reply, just mention @dosu.

How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other  Chat with Dosu Join Discord Share on X

@dosubot[bot] commented on GitHub (Aug 18, 2025): <!-- Answer --> This happens because Google only allows redirect URIs that are public domains or localhost—not private IPs or custom schemes. On mobile, when the OAuth flow tries to redirect to `localhost:3000`, the device can't reach your backend, so the callback never hits your server and the Expo flow can't complete. This is a platform limitation, not a Better Auth bug. For local development, you need your backend to be accessible from your mobile device using a domain Google accepts. The usual solutions are: use a tunneling service like ngrok to expose your backend and register the ngrok HTTPS URL as your Google redirect URI, or use a local domain like `lvh.me` mapped to `127.0.0.1` (if your device can resolve it and reach your machine). Private IPs (like `192.168.x.x`) are not accepted by Google for OAuth redirect URIs, even if they work for direct API calls. If you can't use a tunnel or public domain, you won't be able to complete the OAuth flow on mobile with Google. As a workaround for local dev, you could use native Google sign-in in Expo and send the ID token to your backend for verification, but that's a different flow. Checklist: make sure your backend is reachable from your device, use a valid public domain or tunnel for the redirect URI, confirm your trustedOrigins and scheme config, and verify that after sign-in, the deep link contains the `cookie` parameter and SecureStore is saving it. The Expo plugin and Better Auth backend are designed to handle the deep link/cookie flow, but only after the backend receives the OAuth callback from Google—which requires a valid, reachable redirect URI. [Expo plugin code reference](https://github.com/better-auth/better-auth/blob/06b1da293e615b3670643be4a015f415fb561170/packages/expo/src/client.ts) | [Backend plugin code reference](https://github.com/better-auth/better-auth/blob/06b1da293e615b3670643be4a015f415fb561170/packages/expo/src/index.ts) <!-- Dosu Comment Footer --> *To reply, just mention [@dosu](https://go.dosu.dev/dosubot).* --- <sup>How did I do? [Good](https://app.dosu.dev/response-feedback/2aeecd21-a317-4834-b405-fe1ccf598679?feedback_type=great_response) | [Irrelevant](https://app.dosu.dev/response-feedback/2aeecd21-a317-4834-b405-fe1ccf598679?feedback_type=irrelevant_answer) | [Incorrect](https://app.dosu.dev/response-feedback/2aeecd21-a317-4834-b405-fe1ccf598679?feedback_type=incorrect_sources) | [Verbose](https://app.dosu.dev/response-feedback/2aeecd21-a317-4834-b405-fe1ccf598679?feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/2aeecd21-a317-4834-b405-fe1ccf598679?feedback_type=hallucination) | [Report 🐛](https://app.dosu.dev/response-feedback/2aeecd21-a317-4834-b405-fe1ccf598679?feedback_type=bug_report) | [Other](https://app.dosu.dev/response-feedback/2aeecd21-a317-4834-b405-fe1ccf598679?feedback_type=other)</sup>&nbsp;&nbsp;[![Chat with Dosu](https://dosu.dev/dosu-chat-badge.svg)](https://app.dosu.dev/cdda13d9-dd27-4d31-b09a-5d8bec92de21/ask?utm_source=github)&nbsp;[![Join Discord](https://img.shields.io/badge/join-5865F2?logo=discord&logoColor=white&label=)](https://go.dosu.dev/discord-bot)&nbsp;[![Share on X](https://img.shields.io/badge/X-share-black)](https://twitter.com/intent/tweet?text=%40dosu_ai%20helped%20me%20solve%20this%20issue!&url=https%3A//github.com/better-auth/better-auth/issues/4070)
GiteaMirror commented 2026-03-13 08:59:36 -05:00
Author
Owner
Copy Link

@skempisty commented on GitHub (Aug 18, 2025):

@dosu

Yes you're right, I had tried so many things that I thought for sure this was a BetterAuth issue. Turns out I had tried adding an Ngrok url, but I just neglected to add the /api/auth/callback/google part on both the Google Cloud side and on the better auth socialProviders.google.redirectURI side.

Adding https://<MY_NGROK_URL>/api/auth/callback/google to both places, where that Ngrok url redirects to localhost:3000 did the trick.

I'll close this issue - thank you for the help!

@skempisty commented on GitHub (Aug 18, 2025): @dosu Yes you're right, I had tried so many things that I thought for sure this was a BetterAuth issue. Turns out I had tried adding an Ngrok url, but I just neglected to add the `/api/auth/callback/google` part on both the Google Cloud side and on the better auth socialProviders.google.redirectURI side. Adding `https://<MY_NGROK_URL>/api/auth/callback/google` to both places, where that Ngrok url redirects to localhost:3000 did the trick. I'll close this issue - thank you for the help!
GiteaMirror commented 2026-03-13 08:59:37 -05:00
Author
Owner
Copy Link

@Dosbodoke commented on GitHub (Aug 31, 2025):

Did you managed to solve this on a development environment? Was the only solution to use NGROK to have a https domain?

@Dosbodoke commented on GitHub (Aug 31, 2025): Did you managed to solve this on a development environment? Was the only solution to use NGROK to have a https domain?
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
adapter
astro
awaiting external contributor
blocked
breaking
breaking change
bug
c-devops
core
credentials
database
dependencies
devops
devtools
docs
documentation
duplicate
elysia
enhancement
enterprise
expo
express
fastify
good first issue
help wanted
hono
identity
infra
integration
invalid
javascript
locked
maintenance
need-more-information
needs: info
needs: repro
nextjs
nuxt
oauth
organization
P0
payments
perf
platform
plugin
pull-request
Mirrored from GitHub Pull Request
 question
ready
regression
remix
security
social-provider
solid
stale
svelte
tanstack-start
tracking
version-bump
vue
wontfix
No Label expo social-provider
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/better-auth#1735
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?