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

Multi-tenant cross domain situation #2013

New Issue
Closed
opened 2026-03-13 09:21:03 -05:00 by GiteaMirror · 3 comments
GiteaMirror commented 2026-03-13 09:21:03 -05:00
Owner
Copy Link

Originally created by @programad on GitHub (Sep 24, 2025).

Hey, everyone. First of all, I want to congratulate the team on the awesome work on Better Auth.

Also, I am having a difficult time on finding the correct setup for my use case and I would like some help either from the team or from the community that might be an issue or not.

  • I have an app that as an API and a web application.
  • The Better Auth is on the api exposed under /auth routes. On localhost I can just use localhost:someport. On other environments the API get proper urls like api.domain.tld
  • The webapp runs on localhost:someotherport but our app is never accessed without a subdomain. Meaning we always have a tenant.localhost:someport and on other environments we can have either tenant.domain.tld or tenant.somepreviewdomain.tld or a totally custom domain setup by our customer like www.mydomain.tld

So, the app, which might be on subdomain localhost or custom domain, is calling an API to get to Better Auth on a fixed different domain.

  • Better Auth has the Oauth Proxy plugin.
  • I managed to authenticate using Google and Slack fine.
  • After authenticating, i use a "session transfer mechanism" to pass the session token that was just created on the db via query string from the API to the web application what cookie the web application should save on the browser issued by whatever the web application domain or subdomain currently is.
  • When making SSR calls, the web application send that cookie back to the auth API, to get the server side session from the DB, for example.
  • Better Auth never finds the session, potentially because the cookie was signed for a different domain, not for the API domain.

Is this the expected behavior for Better Auth + OAuth Proxy + cross-domain + multi-tenant scenario? If so, what is the recommended approach to make Better Auth always find the correct session from the db using the cookie we send from the web application?

I am thinking about making an introspection endpoint that will use a direct db query instead of Better Auth for that task but I am not convinced this is the best option right now.

Thank you for your time and awesome work!

Originally created by @programad on GitHub (Sep 24, 2025). Hey, everyone. First of all, I want to congratulate the team on the awesome work on Better Auth. Also, I am having a difficult time on finding the correct setup for my use case and I would like some help either from the team or from the community that might be an issue or not. - I have an app that as an API and a web application. - The Better Auth is on the api exposed under `/auth` routes. On localhost I can just use localhost:someport. On other environments the API get proper urls like api.domain.tld - The webapp runs on localhost:someotherport but our app is never accessed without a subdomain. Meaning we always have a tenant.localhost:someport and on other environments we can have either tenant.domain.tld or tenant.somepreviewdomain.tld or a totally custom domain setup by our customer like www.mydomain.tld So, the app, which might be on subdomain localhost or custom domain, is calling an API to get to Better Auth on a fixed different domain. - Better Auth has the `Oauth Proxy` plugin. - I managed to authenticate using Google and Slack fine. - After authenticating, i use a "session transfer mechanism" to pass the session token that was just created on the db via query string from the API to the web application what cookie the web application should save on the browser issued by whatever the web application domain or subdomain currently is. - When making SSR calls, the web application send that cookie back to the auth API, to get the server side session from the DB, for example. - Better Auth never finds the session, potentially because the cookie was signed for a different domain, not for the API domain. Is this the expected behavior for `Better Auth` + `OAuth Proxy` + `cross-domain` + `multi-tenant` scenario? If so, what is the recommended approach to make Better Auth always find the correct session from the db using the cookie we send from the web application? I am thinking about making an introspection endpoint that will use a direct db query instead of Better Auth for that task but I am not convinced this is the best option right now. Thank you for your time and awesome work!
GiteaMirror added the integration label 2026-03-13 09:21:03 -05:00
GiteaMirror commented 2026-03-13 09:21:06 -05:00
Author
Owner
Copy Link

@dosubot[bot] commented on GitHub (Sep 24, 2025):

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

Yes, this is expected behavior: browsers restrict cookies to their issuing domain, so Better Auth can't find a session if the cookie was set for a different domain or subdomain. This is a common challenge in multi-tenant, cross-domain setups, even with the OAuth Proxy plugin, which helps with initial authentication and cookie setting but doesn't bypass browser cookie boundaries for subsequent API requests reference.

The recommended approach is to avoid relying solely on cookies for session retrieval across domains. Instead, pass the session token (or a JWT, if you use the JWT plugin) from your web app to the API—typically via a header or query parameter. On the API side, use Better Auth's internal session lookup or the custom-session plugin, which exposes a /get-session endpoint that can fetch session data directly from the database, bypassing cookie restrictions reference.

Implementing a dedicated introspection endpoint (using the custom-session plugin or similar logic) is a supported and recommended pattern for your scenario. This lets you securely retrieve session data regardless of cookie domain issues reference.

If you want true cross-domain session retrieval, use tokens (JWT or session token) and an API endpoint for session introspection. This is secure and aligns with Better Auth's architecture for multi-tenant, cross-domain apps.

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 (Sep 24, 2025): <!-- Greeting --> Hi @programad! I'm [Dosu](https://go.dosu.dev/dosubot) and I’m helping the better-auth team. <!-- Answer --> Yes, this is expected behavior: browsers restrict cookies to their issuing domain, so Better Auth can't find a session if the cookie was set for a different domain or subdomain. This is a common challenge in multi-tenant, cross-domain setups, even with the OAuth Proxy plugin, which helps with initial authentication and cookie setting but doesn't bypass browser cookie boundaries for subsequent API requests [reference](https://github.com/better-auth/better-auth/issues/3874). The recommended approach is to avoid relying solely on cookies for session retrieval across domains. Instead, pass the session token (or a JWT, if you use the JWT plugin) from your web app to the API—typically via a header or query parameter. On the API side, use Better Auth's internal session lookup or the `custom-session` plugin, which exposes a `/get-session` endpoint that can fetch session data directly from the database, bypassing cookie restrictions [reference](https://github.com/better-auth/better-auth/blob/f6cbdcc84ee5d2971fdcc8b23ff7c174f88cf45b/packages/better-auth/src/plugins/custom-session/index.ts). Implementing a dedicated introspection endpoint (using the custom-session plugin or similar logic) is a supported and recommended pattern for your scenario. This lets you securely retrieve session data regardless of cookie domain issues [reference](https://github.com/better-auth/better-auth/blob/f6cbdcc84ee5d2971fdcc8b23ff7c174f88cf45b/packages/better-auth/src/api/routes/session.ts). If you want true cross-domain session retrieval, use tokens (JWT or session token) and an API endpoint for session introspection. This is secure and aligns with Better Auth's architecture for multi-tenant, cross-domain apps. <!-- 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/c06a84e9-725b-4dfd-b15f-d4d27e002da7?feedback_type=great_response) | [Irrelevant](https://app.dosu.dev/response-feedback/c06a84e9-725b-4dfd-b15f-d4d27e002da7?feedback_type=irrelevant_answer) | [Incorrect](https://app.dosu.dev/response-feedback/c06a84e9-725b-4dfd-b15f-d4d27e002da7?feedback_type=incorrect_sources) | [Verbose](https://app.dosu.dev/response-feedback/c06a84e9-725b-4dfd-b15f-d4d27e002da7?feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/c06a84e9-725b-4dfd-b15f-d4d27e002da7?feedback_type=hallucination) | [Report 🐛](https://app.dosu.dev/response-feedback/c06a84e9-725b-4dfd-b15f-d4d27e002da7?feedback_type=bug_report) | [Other](https://app.dosu.dev/response-feedback/c06a84e9-725b-4dfd-b15f-d4d27e002da7?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/4878)
GiteaMirror commented 2026-03-13 09:21:06 -05:00
Author
Owner
Copy Link

@captbunzo commented on GitHub (Oct 29, 2025):

Hey @dosu,

Thanks so much for the detailed explanation. An application I'm building will require this as well, so I'm going to start working on this today.

Do you have a recommendation between using JWT versus the session token?

@captbunzo commented on GitHub (Oct 29, 2025): Hey @dosu, Thanks so much for the detailed explanation. An application I'm building will require this as well, so I'm going to start working on this today. Do you have a recommendation between using JWT versus the session token?
GiteaMirror commented 2026-03-13 09:21:06 -05:00
Author
Owner
Copy Link

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

Hi, @programad. I'm Dosu, and I'm helping the better-auth team manage their backlog and am marking this issue as stale.

Issue Summary:

  • You reported issues with Better Auth's OAuth Proxy in a multi-tenant, cross-domain setup where session cookies aren't recognized due to domain restrictions.
  • I explained that this is expected browser behavior and recommended passing session tokens or JWTs from the web app to the API.
  • I suggested using Better Auth's custom-session plugin or a dedicated introspection endpoint to securely retrieve session data.
  • Another user showed interest in this approach and asked for advice on choosing between JWT and session tokens.
  • The issue was resolved with the understanding that cross-domain cookie restrictions require token passing strategies.

Next Steps:

  • Please let me know if this issue is still relevant with the latest version of better-auth by commenting here.
  • Otherwise, this issue will be automatically closed in 7 days.

Thanks for your understanding and contribution!

@dosubot[bot] commented on GitHub (Jan 28, 2026): Hi, @programad. I'm [Dosu](https://dosu.dev), and I'm helping the better-auth team manage their backlog and am marking this issue as stale. **Issue Summary:** - You reported issues with Better Auth's OAuth Proxy in a multi-tenant, cross-domain setup where session cookies aren't recognized due to domain restrictions. - I explained that this is expected browser behavior and recommended passing session tokens or JWTs from the web app to the API. - I suggested using Better Auth's custom-session plugin or a dedicated introspection endpoint to securely retrieve session data. - Another user showed interest in this approach and asked for advice on choosing between JWT and session tokens. - The issue was resolved with the understanding that cross-domain cookie restrictions require token passing strategies. **Next Steps:** - Please let me know if this issue is still relevant with the latest version of better-auth by commenting here. - Otherwise, this issue will be automatically closed in 7 days. Thanks for your understanding and contribution!
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 integration
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#2013
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?