github-starred/better-auth
2
0
Fork 0
mirror of https://github.com/better-auth/better-auth.git synced 2026-05-23 07:18:56 -05:00
Code Issues 2.5k Packages Projects Releases 112 Wiki Activity

[GH-ISSUE #7240] [Expo/Android] OAuth session not persisting after moving backend to subdomain #10767

New Issue
Closed
opened 2026-04-13 07:06:35 -05:00 by GiteaMirror · 3 comments
GiteaMirror commented 2026-04-13 07:06:35 -05:00
Owner
Copy Link

Originally created by @skempisty on GitHub (Jan 10, 2026).
Original GitHub issue: https://github.com/better-auth/better-auth/issues/7240

Is this suited for github?

  • Yes, this is suited for github

To Reproduce

Environment

Platform: Android (iOS and web work fine)
Setup: React Native/Expo app with Next.js backend
Using: @better-auth/expo client plugin with expo-secure-store

Problem

Google OAuth stopped working on Android after moving the backend from root domain (seen-t.com) to subdomain (app.seen-t.com). iOS and web continue to work correctly.
What changed

Before (working): Backend hosted at https://seen-t.com
After (broken on Android): Backend hosted at https://app.seen-t.com

No code changes were made - only the domain changed.

Symptoms

OAuth flow completes successfully - session is created in database
Redirect back to app happens (browser closes automatically)
But authClient.useSession() returns null on Android
iOS works perfectly with the same setup

What I've tried

Explicitly setting baseURL: "https://app.seen-t.com" on server config
Verified assetlinks.json is correct and passes Google's validation
Confirmed Android app has correct intent filters for app.seen-t.com
Users are on latest build with correct configuration

Suspected cause

Something related to how cookies or session tokens are handled differently on Android when using a subdomain. Possibly:

Cookie domain configuration needed for subdomains?
Cross-subdomain cookie settings?
The expo client plugin not properly handling the redirect/token on Android when the domain is a subdomain?

Current vs. Expected behavior

Current behavior:
On Android, after completing Google OAuth:

User selects Google account in browser
OAuth completes successfully - session is created in the database (confirmed via server logs)
Browser closes automatically and app opens (deep link works)
User lands on the feed screen but is NOT authenticated
authClient.useSession() returns null
User must attempt login again (which also fails the same way)

Expected behavior:
After OAuth completes and the app opens via deep link:

The session token should be stored in SecureStore
authClient.useSession() should return the valid session
User should be authenticated and see their personalized feed

What version of Better Auth are you using?

1.3.7

System info

{
  "system": {
    "platform": "darwin",
    "arch": "arm64",
    "version": "Darwin Kernel Version 23.6.0: Mon Jul 29 21:14:30 PDT 2024; root:xnu-10063.141.2~1/RELEASE_ARM64_T6000",
    "release": "23.6.0",
    "cpuCount": 8,
    "cpuModel": "Apple M1 Pro",
    "totalMemory": "16.00 GB",
    "freeMemory": "0.15 GB"
  },
  "node": {
    "version": "v22.21.1",
    "env": "development"
  },
  "packageManager": {
    "name": "npm",
    "version": "10.9.4"
  },
  "frameworks": [
    {
      "name": "next",
      "version": "16.0.10"
    },
    {
      "name": "react",
      "version": "^18"
    }
  ],
  "databases": [
    {
      "name": "@prisma/client",
      "version": "6.9.0"
    }
  ],
  "betterAuth": {
    "version": "^1.3.7",
    "config": null
  }
}

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

Client, Backend

Additional context

This exact configuration worked when the backend was hosted on the root domain (seen-t.com)
After moving to a subdomain (app.seen-t.com) with no code changes, Android OAuth broke
iOS and web continue to work perfectly with the subdomain
The session IS created server-side (verified in database), so the issue is client-side session token storage/retrieval on Android only

Originally created by @skempisty on GitHub (Jan 10, 2026). Original GitHub issue: https://github.com/better-auth/better-auth/issues/7240 ### Is this suited for github? - [x] Yes, this is suited for github ### To Reproduce **Environment** Platform: Android (iOS and web work fine) Setup: React Native/Expo app with Next.js backend Using: @better-auth/expo client plugin with expo-secure-store **Problem** Google OAuth stopped working on Android after moving the backend from root domain (seen-t.com) to subdomain (app.seen-t.com). iOS and web continue to work correctly. What changed Before (working): Backend hosted at https://seen-t.com After (broken on Android): Backend hosted at https://app.seen-t.com No code changes were made - only the domain changed. **Symptoms** OAuth flow completes successfully - session is created in database Redirect back to app happens (browser closes automatically) But authClient.useSession() returns null on Android iOS works perfectly with the same setup **What I've tried** Explicitly setting baseURL: "https://app.seen-t.com" on server config Verified assetlinks.json is correct and passes Google's validation Confirmed Android app has correct intent filters for app.seen-t.com Users are on latest build with correct configuration **Suspected cause** Something related to how cookies or session tokens are handled differently on Android when using a subdomain. Possibly: Cookie domain configuration needed for subdomains? Cross-subdomain cookie settings? The expo client plugin not properly handling the redirect/token on Android when the domain is a subdomain? ### Current vs. Expected behavior **Current behavior:** On Android, after completing Google OAuth: User selects Google account in browser OAuth completes successfully - session is created in the database (confirmed via server logs) Browser closes automatically and app opens (deep link works) User lands on the feed screen but is NOT authenticated authClient.useSession() returns null User must attempt login again (which also fails the same way) **Expected behavior:** After OAuth completes and the app opens via deep link: The session token should be stored in SecureStore authClient.useSession() should return the valid session User should be authenticated and see their personalized feed ### What version of Better Auth are you using? 1.3.7 ### System info ```bash { "system": { "platform": "darwin", "arch": "arm64", "version": "Darwin Kernel Version 23.6.0: Mon Jul 29 21:14:30 PDT 2024; root:xnu-10063.141.2~1/RELEASE_ARM64_T6000", "release": "23.6.0", "cpuCount": 8, "cpuModel": "Apple M1 Pro", "totalMemory": "16.00 GB", "freeMemory": "0.15 GB" }, "node": { "version": "v22.21.1", "env": "development" }, "packageManager": { "name": "npm", "version": "10.9.4" }, "frameworks": [ { "name": "next", "version": "16.0.10" }, { "name": "react", "version": "^18" } ], "databases": [ { "name": "@prisma/client", "version": "6.9.0" } ], "betterAuth": { "version": "^1.3.7", "config": null } } ``` ### Which area(s) are affected? (Select all that apply) Client, Backend ### Additional context This exact configuration worked when the backend was hosted on the root domain (seen-t.com) After moving to a subdomain (app.seen-t.com) with no code changes, Android OAuth broke iOS and web continue to work perfectly with the subdomain The session IS created server-side (verified in database), so the issue is client-side session token storage/retrieval on Android only
GiteaMirror added the locked label 2026-04-13 07:06:35 -05:00
GiteaMirror commented 2026-04-13 07:06:39 -05:00
Author
Owner
Copy Link

@dosubot[bot] commented on GitHub (Jan 10, 2026):

This is a common issue when moving to a subdomain with Expo/Android and Better Auth. The most likely cause is that the session token is not being handed off or stored correctly after OAuth, due to subdomain-specific cookie and redirect handling on Android.

Here’s what to check and try:

  1. Deep Link Cookie Parameter: After OAuth, the backend must append the session token as a cookie query parameter to the deep link URL. The Expo client extracts this and saves it in SecureStore. If the deep link is missing the cookie parameter, the session will not persist. This usually means a mismatch in trustedOrigins or callback URL config on the backend. Log the deep link URL after sign-in to confirm the cookie parameter is present. If it’s missing, review your backend config and ensure your app’s scheme is listed in trustedOrigins (details, details).

  2. Backend Cookie Domain and Attributes: For cross-subdomain session sharing, set crossSubDomainCookies in your Better Auth config:

    advanced: {
  crossSubDomainCookies: {
    enabled: true,
    domain: '.seen-t.com', // leading dot required
  },
  defaultCookieAttributes: {
    sameSite: 'none',
    secure: true,
    httpOnly: true,
  },
}

    This ensures cookies are valid across subdomains and survive OAuth redirects (reference, reference).

  3. Trusted Origins: Make sure all possible frontend origins (including your app’s scheme, e.g., yourapp://, and exp:// for Expo Go) are listed in trustedOrigins in your Better Auth config (reference).

  4. Force Session Refresh: In Better Auth v1.3.7 and later, after social sign-in, session data is not always immediately available via useSession() on mobile. Call await authClient.getSession() right after sign-in to force a session refresh and store the session data (reference, reference).

  5. Expo Plugin Initialization: Ensure the Expo plugin is initialized before any sign-in attempt, and that your app’s scheme matches what’s in trustedOrigins (reference).

  6. Inspect SecureStore: Log the contents of SecureStore after sign-in to confirm the session token is being saved. If it’s not, the issue is likely with the deep link or plugin setup (reference).

  7. Recent Fixes: There have been recent fixes for cookie parsing and handling in both the backend and the Expo client. If possible, consider upgrading to the latest Better Auth and @better-auth/expo versions for improved reliability (reference, reference).

If you follow these steps and still see the issue, share the deep link URL after OAuth and the SecureStore contents after sign-in to help pinpoint where the flow is breaking.

To reply, just mention @dosu.

How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other

Chat with Dosu Open in Cursor Join Discord Share on X

<!-- gh-comment-id:3732114568 --> @dosubot[bot] commented on GitHub (Jan 10, 2026): <!-- Answer --> This is a common issue when moving to a subdomain with Expo/Android and Better Auth. The most likely cause is that the session token is not being handed off or stored correctly after OAuth, due to subdomain-specific cookie and redirect handling on Android. Here’s what to check and try: 1. **Deep Link Cookie Parameter**: After OAuth, the backend must append the session token as a `cookie` query parameter to the deep link URL. The Expo client extracts this and saves it in SecureStore. If the deep link is missing the `cookie` parameter, the session will not persist. This usually means a mismatch in `trustedOrigins` or callback URL config on the backend. Log the deep link URL after sign-in to confirm the `cookie` parameter is present. If it’s missing, review your backend config and ensure your app’s scheme is listed in `trustedOrigins` ([details](https://github.com/better-auth/better-auth/issues/6936), [details](https://github.com/better-auth/better-auth/issues/3711)). 2. **Backend Cookie Domain and Attributes**: For cross-subdomain session sharing, set `crossSubDomainCookies` in your Better Auth config: ```ts advanced: { crossSubDomainCookies: { enabled: true, domain: '.seen-t.com', // leading dot required }, defaultCookieAttributes: { sameSite: 'none', secure: true, httpOnly: true, }, } ``` This ensures cookies are valid across subdomains and survive OAuth redirects ([reference](https://github.com/better-auth/better-auth/issues/5611), [reference](https://github.com/better-auth/better-auth/discussions/5670)). 3. **Trusted Origins**: Make sure all possible frontend origins (including your app’s scheme, e.g., `yourapp://`, and `exp://` for Expo Go) are listed in `trustedOrigins` in your Better Auth config ([reference](https://github.com/better-auth/better-auth/issues/3711)). 4. **Force Session Refresh**: In Better Auth v1.3.7 and later, after social sign-in, session data is not always immediately available via `useSession()` on mobile. Call `await authClient.getSession()` right after sign-in to force a session refresh and store the session data ([reference](https://github.com/better-auth/better-auth/issues/1443), [reference](https://github.com/better-auth/better-auth/issues/6582)). 5. **Expo Plugin Initialization**: Ensure the Expo plugin is initialized before any sign-in attempt, and that your app’s scheme matches what’s in `trustedOrigins` ([reference](https://github.com/better-auth/better-auth/issues/6936)). 6. **Inspect SecureStore**: Log the contents of SecureStore after sign-in to confirm the session token is being saved. If it’s not, the issue is likely with the deep link or plugin setup ([reference](https://github.com/better-auth/better-auth/issues/6936)). 7. **Recent Fixes**: There have been recent fixes for cookie parsing and handling in both the backend and the Expo client. If possible, consider upgrading to the latest Better Auth and @better-auth/expo versions for improved reliability ([reference](https://github.com/better-auth/better-auth/issues/6483), [reference](https://github.com/better-auth/better-auth/pull/6990)). If you follow these steps and still see the issue, share the deep link URL after OAuth and the SecureStore contents after sign-in to help pinpoint where the flow is breaking. <!-- 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/493a8ce2-49bb-49db-bba5-afd5245906c4?feedback_type=great_response) | [Irrelevant](https://app.dosu.dev/response-feedback/493a8ce2-49bb-49db-bba5-afd5245906c4?feedback_type=irrelevant_answer) | [Incorrect](https://app.dosu.dev/response-feedback/493a8ce2-49bb-49db-bba5-afd5245906c4?feedback_type=incorrect_sources) | [Verbose](https://app.dosu.dev/response-feedback/493a8ce2-49bb-49db-bba5-afd5245906c4?feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/493a8ce2-49bb-49db-bba5-afd5245906c4?feedback_type=hallucination) | [Report 🐛](https://app.dosu.dev/response-feedback/493a8ce2-49bb-49db-bba5-afd5245906c4?feedback_type=bug_report) | [Other](https://app.dosu.dev/response-feedback/493a8ce2-49bb-49db-bba5-afd5245906c4?feedback_type=other)</sup> [![Chat with Dosu](https://dosu.dev/dosu-chat-badge.svg)](https://app.dosu.dev/cdda13d9-dd27-4d31-b09a-5d8bec92de21/ask?utm_source=github)&nbsp;[![Open in Cursor](https://dosu.dev/dosu-in-cursor.svg)](https://cursor.com/link/prompt?text=This%20is%20a%20common%20issue%20when%20moving%20to%20a%20subdomain%20with%20Expo/Android%20and%20Better%20Auth.%20The%20most%20likely%20cause%20is%20that%20the%20session%20token%20is%20not%20being%20handed%20off%20or%20stored%20correctly%20after%20OAuth%2C%20due%20to%20subdomain-specific%20cookie%20and%20redirect%20handling%20on%20Android.%0A%0AHere%E2%80%99s%20what%20to%20check%20and%20try%3A%0A%0A1.%20%2A%2ADeep%20Link%20Cookie%20Parameter%2A%2A%3A%20After%20OAuth%2C%20the%20backend%20must%20append%20the%20session%20token%20as%20a%20%60cookie%60%20query%20parameter%20to%20the%20deep%20link%20URL.%20The%20Expo%20client%20extracts%20this%20and%20saves%20it%20in%20SecureStore.%20If%20the%20deep%20link%20is%20missing%20the%20%60cookie%60%20parameter%2C%20the%20session%20will%20not%20persist.%20This%20usually%20means%20a%20mismatch%20in%20%60trustedOrigins%60%20or%20callback%20URL%20config%20on%20the%20backend.%20Log%20the%20deep%20link%20URL%20after%20sign-in%20to%20confirm%20the%20%60cookie%60%20parameter%20is%20present.%20If%20it%E2%80%99s%20missing%2C%20review%20your%20backend%20config%20and%20ensure%20your%20app%E2%80%99s%20scheme%20is%20listed%20in%20%60trustedOrigins%60%C2%A0%28%5Bdetails%5D%28https%3A//github.com/better-auth/better-auth/issues/6936%29%2C%20%5Bdetails%5D%28https%3A//github.com/better-auth/better-auth/issues/3711%29%29.%0A%0A2.%20%2A%2ABackend%20Cookie%20Domain%20and%20Attributes%2A%2A%3A%20For%20cross-subdomain%20session%20sharing%2C%20set%20%60crossSubDomainCookies%60%20in%20your%20Better%20Auth%20config%3A%0A%20%20%20%60%60%60ts%0A%20%20%20advanced%3A%20%7B%0A%20%20%20%20%20crossSubDomainCookies%3A%20%7B%0A%20%20%20%20%20%20%20enabled%3A%20true%2C%0A%20%20%20%20%20%20%20domain%3A%20%27.seen-t.com%27%2C%20//%20leading%20dot%20required%0A%20%20%20%20%20%7D%2C%0A%20%20%20%20%20defaultCookieAttributes%3A%20%7B%0A%20%20%20%20%20%20%20sameSite%3A%20%27none%27%2C%0A%20%20%20%20%20%20%20secure%3A%20true%2C%0A%20%20%20%20%20%20%20httpOnly%3A%20true%2C%0A%20%20%20%20%20%7D%2C%0A%20%20%20%7D%0A%20%20%20%60%60%60%0A%20%20%20This%20ensures%20cookies%20are%20valid%20across%20subdomains%20and%20survive%20OAuth%20redirects%C2%A0%28%5Breference%5D%28https%3A//github.com/better-auth/better-auth/issues/5611%29%2C%20%5Breference%5D%28https%3A//github.com/better-auth/better-auth/discussions/5670%29%29.%0A%0A3.%20%2A%2ATrusted%20Origins%2A%2A%3A%20Make%20sure%20all%20possible%20frontend%20origins%20%28including%20your%20app%E2%80%99s%20scheme%2C%20e.g.%2C%20%60yourapp%3A//%60%2C%20and%20%60exp%3A//%60%20for%20Expo%20Go%29%20are%20listed%20in%20%60trustedOrigins%60%20in%20your%20Better%20Auth%20config%C2%A0%28%5Breference%5D%28https%3A//github.com/better-auth/better-auth/issues/3711%29%29.%0A%0A4.%20%2A%2AForce%20Session%20Refresh%2A%2A%3A%20In%20Better%20Auth%20v1.3.7%20and%20later%2C%20after%20social%20sign-in%2C%20session%20data%20is%20not%20always%20immediately%20available%20via%20%60useSession%28%29%60%20on%20mobile.%20Call%20%60await%20authClient.getSession%28%29%60%20right%20after%20sign-in%20to%20force%20a%20session%20refresh%20and%20store%20the%20session%20data%C2%A0%28%5Breference%5D%28https%3A//github.com/better-auth/better-auth/issues/1443%29%2C%20%5Breference%5D%28https%3A//github.com/better-auth/better-auth/issues/6582%29%29.%0A%0A5.%20%2A%2AExpo%20Plugin%20Initialization%2A%2A%3A%20Ensure%20the%20Expo%20plugin%20is%20initialized%20before%20any%20sign-in%20attempt%2C%20and%20that%20your%20app%E2%80%99s%20scheme%20matches%20what%E2%80%99s%20in%20%60trustedOrigins%60%C2%A0%28%5Breference%5D%28https%3A//github.com/better-auth/better-auth/issues/6936%29%29.%0A%0A6.%20%2A%2AInspect%20SecureStore%2A%2A%3A%20Log%20the%20contents%20of%20SecureStore%20after%20sign-in%20to%20confirm%20the%20session%20token%20is%20being%20saved.%20If%20it%E2%80%99s%20not%2C%20the%20issue%20is%20likely%20with%20the%20deep%20link%20or%20plugin%20setup%C2%A0%28%5Breference%5D%28https%3A//github.com/better-auth/better-auth/issues/6936%29%29.%0A%0A7.%20%2A%2ARecent%20Fixes%2A%2A%3A%20There%20have%20been%20recent%20fixes%20for%20cookie%20parsing%20and%20handling%20in%20both%20the%20backend%20and%20the%20Expo%20client.%20If%20possible%2C%20consider%20upgrading%20to%20the%20latest%20Better%20Auth%20and%20%40better-auth/expo%20versions%20for%20improved%20reliability%C2%A0%28%5Breference%5D%28https%3A//github.com/better-auth/better-auth/issues/6483%29%2C%20%5Breference%5D%28https%3A//github.com/better-auth/better-auth/pull/6990%29%29.%0A%0AIf%20you%20follow%20these%20steps%20and%20still%20see%20the%20issue%2C%20share%20the%20deep%20link%20URL%20after%20OAuth%20and%20the%20SecureStore%20contents%20after%20sign-in%20to%20help%20pinpoint%20where%20the%20flow%20is%20breaking.)&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/7240)
GiteaMirror commented 2026-04-13 07:06:40 -05:00
Author
Owner
Copy Link

@skempisty commented on GitHub (Jan 10, 2026):

@dosu

For this suggestion:

Backend Cookie Domain and Attributes: For cross-subdomain session sharing, set crossSubDomainCookies in your Better Auth config

Note that my FE/BE are running on app.seen-t.com, just like they used to be running on seen-t.com earlier. This is only an issue on android with regards to google login (credentials login works fine). Is this advice about cross-subdomain session sharing relavant?

<!-- gh-comment-id:3732118786 --> @skempisty commented on GitHub (Jan 10, 2026): @dosu For this suggestion: > Backend Cookie Domain and Attributes: For cross-subdomain session sharing, set crossSubDomainCookies in your Better Auth config Note that my FE/BE are running on app.seen-t.com, just like they used to be running on seen-t.com earlier. This is only an issue on android with regards to google login (credentials login works fine). Is this advice about cross-subdomain session sharing relavant?
GiteaMirror commented 2026-04-13 07:06:40 -05:00
Author
Owner
Copy Link

@dosubot[bot] commented on GitHub (Jan 10, 2026):

No, crossSubDomainCookies is not relevant when both your frontend and backend are on the same subdomain (like app.seen-t.com); it's only needed if you want to share cookies across different subdomains (e.g., app.seen-t.com and api.seen-t.com) reference. In your setup, cookies are already scoped correctly.

The reason credentials login works but Google OAuth does not on Android is because credentials login sets the session cookie directly in the response, while OAuth relies on the backend appending the session token as a cookie query parameter to the deep link URL. The Expo plugin then extracts and stores this in SecureStore. If the deep link is missing the cookie parameter, or if trustedOrigins/callbackURL are misconfigured, the session won't persist reference.

For your case, focus on checking that the deep link after OAuth contains the cookie parameter, that trustedOrigins and callbackURL are correct, and try calling await authClient.getSession() right after signIn.social() to force a session refresh reference. If you still see issues, logging the deep link and SecureStore contents after sign-in will help pinpoint where the flow is breaking.

To reply, just mention @dosu.

How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other

Chat with Dosu Open in Cursor Join Discord Share on X

<!-- gh-comment-id:3732121574 --> @dosubot[bot] commented on GitHub (Jan 10, 2026): <!-- Answer --> No, crossSubDomainCookies is not relevant when both your frontend and backend are on the same subdomain (like app.seen-t.com); it's only needed if you want to share cookies across different subdomains (e.g., app.seen-t.com and api.seen-t.com) [reference](https://github.com/better-auth/better-auth/discussions/5670). In your setup, cookies are already scoped correctly. The reason credentials login works but Google OAuth does not on Android is because credentials login sets the session cookie directly in the response, while OAuth relies on the backend appending the session token as a cookie query parameter to the deep link URL. The Expo plugin then extracts and stores this in SecureStore. If the deep link is missing the cookie parameter, or if trustedOrigins/callbackURL are misconfigured, the session won't persist [reference](https://github.com/better-auth/better-auth/issues/3711). For your case, focus on checking that the deep link after OAuth contains the cookie parameter, that trustedOrigins and callbackURL are correct, and try calling await authClient.getSession() right after signIn.social() to force a session refresh [reference](https://github.com/better-auth/better-auth/issues/3711). If you still see issues, logging the deep link and SecureStore contents after sign-in will help pinpoint where the flow is breaking. <!-- 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/15c818e7-2682-46e9-b043-0dfa1bd4484e?feedback_type=great_response) | [Irrelevant](https://app.dosu.dev/response-feedback/15c818e7-2682-46e9-b043-0dfa1bd4484e?feedback_type=irrelevant_answer) | [Incorrect](https://app.dosu.dev/response-feedback/15c818e7-2682-46e9-b043-0dfa1bd4484e?feedback_type=incorrect_sources) | [Verbose](https://app.dosu.dev/response-feedback/15c818e7-2682-46e9-b043-0dfa1bd4484e?feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/15c818e7-2682-46e9-b043-0dfa1bd4484e?feedback_type=hallucination) | [Report 🐛](https://app.dosu.dev/response-feedback/15c818e7-2682-46e9-b043-0dfa1bd4484e?feedback_type=bug_report) | [Other](https://app.dosu.dev/response-feedback/15c818e7-2682-46e9-b043-0dfa1bd4484e?feedback_type=other)</sup> [![Chat with Dosu](https://dosu.dev/dosu-chat-badge.svg)](https://app.dosu.dev/cdda13d9-dd27-4d31-b09a-5d8bec92de21/ask?utm_source=github)&nbsp;[![Open in Cursor](https://dosu.dev/dosu-in-cursor.svg)](https://cursor.com/link/prompt?text=No%2C%20crossSubDomainCookies%20is%20not%20relevant%20when%20both%20your%20frontend%20and%20backend%20are%20on%20the%20same%20subdomain%20%28like%20app.seen-t.com%29%3B%20it%27s%20only%20needed%20if%20you%20want%20to%20share%20cookies%20across%20different%20subdomains%20%28e.g.%2C%20app.seen-t.com%20and%20api.seen-t.com%29%C2%A0%5Breference%5D%28https%3A//github.com/better-auth/better-auth/discussions/5670%29.%20In%20your%20setup%2C%20cookies%20are%20already%20scoped%20correctly.%0A%0AThe%20reason%20credentials%20login%20works%20but%20Google%20OAuth%20does%20not%20on%20Android%20is%20because%20credentials%20login%20sets%20the%20session%20cookie%20directly%20in%20the%20response%2C%20while%20OAuth%20relies%20on%20the%20backend%20appending%20the%20session%20token%20as%20a%20cookie%20query%20parameter%20to%20the%20deep%20link%20URL.%20The%20Expo%20plugin%20then%20extracts%20and%20stores%20this%20in%20SecureStore.%20If%20the%20deep%20link%20is%20missing%20the%20cookie%20parameter%2C%20or%20if%20trustedOrigins/callbackURL%20are%20misconfigured%2C%20the%20session%20won%27t%20persist%C2%A0%5Breference%5D%28https%3A//github.com/better-auth/better-auth/issues/3711%29.%0A%0AFor%20your%20case%2C%20focus%20on%20checking%20that%20the%20deep%20link%20after%20OAuth%20contains%20the%20cookie%20parameter%2C%20that%20trustedOrigins%20and%20callbackURL%20are%20correct%2C%20and%20try%20calling%20await%20authClient.getSession%28%29%20right%20after%20signIn.social%28%29%20to%20force%20a%20session%20refresh%C2%A0%5Breference%5D%28https%3A//github.com/better-auth/better-auth/issues/3711%29.%20If%20you%20still%20see%20issues%2C%20logging%20the%20deep%20link%20and%20SecureStore%20contents%20after%20sign-in%20will%20help%20pinpoint%20where%20the%20flow%20is%20breaking.)&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/7240)
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 locked
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#10767
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?