Auth not working across completely different domains (app)

I'm trying to set up authentication where users log in on one domain and use the app on another completely different domain (think

auth-service.com

auth-service.com

auth-service.com

auth-service.com and

my-app.io

my-app.io

my-app.io

my-app.io

totally unrelated domains).

My setup:*

Auth server on
```
a.xyz
```
a.xyz
```
a.xyz
```
a.xyz
Main app on
```
foo.abc
```
foo.abc
```
foo.abc
```
foo.abc
Both use the same Turso database and identical Better-Auth configs
Same session table, same cookie names, everything

What happens:

User logs in on auth server → works fine, session created in database
Auth server sends session token back to main app
Main app sets the token as a cookie on its domain
When I call
```
getSession()
```
getSession()
```
getSession()
```
getSession()
on the main app → returns null every time

I can see the session in the database and the cookie is set correctly, but Better-Auth just won't recognize it.

My question: Does Better-Auth tie sessions to the domain where they were created? Even with a shared database, will a session created on

a.xyz

a.xyz

a.xyz

a.xyz never work on

foo.abc

foo.abc

foo.abc

foo.abc?

I'm using SvelteKit + Better-Auth + Drizzle + Turso. Has anyone got this working with completely different domains?

All other config are normal or same as installation docs.

I may be missing something very obvious here, help would be really appreciated

Thanks!

momoneko•6/23/25, 7:44 PM

The issue is that you can't set a cookie for a different domain. The browser refuses cookies that don't match the domain where they're comming from or from a higher level domain.
In theory, you could set the advanced.cookies.domainadvanced.cookies.domain to

foo.abc

foo.abc

, but even then, the browser will refuse to set the cookies.

E.g. the screenshot shows what I get when I try to sed the domain to httpbin.org

What you can do is to get your auth server on a subdomain (e.g. auth.foo.abcauth.foo.abc) and set the domaindomain to

foo.abc

foo.abc

SSheldonFromBBT I'm trying to set up authentication where users log in on one domain and use the...

sebciotp•6/23/25, 8:12 PM

The cookies are not send between different domains because its not secure and generally avoided. However, you can bypass that by using cookie attribiutes that comes with security risks.

https://www.better-auth.com/docs/reference/options#advanced

Here you can use options like use secure cookies and disable csrf check that will allow you to send between domains, i think that you also need to customise to cookie to have SameSiteSameSite set to none property which you can also customise

Mmomoneko The issue is that you can't set a cookie for a different domain. The browser ref...

SheldonFromBBTOP•6/24/25, 5:46 AM

But while setting the cookie which is a better auth session token, returned by the auth server app, we don't get to set this option, in sveltekit you set normally as you would, do you mean that the token generated by better auth on auth server (app), when returned to different domain app, gets invalidated or useless? Is this a better auth specific behaviour or cookies in general?

SheldonFromBBTOP•6/24/25, 6:57 AM

Is the session token tied to a origin or domain it was created? such that when better auth client on other domain validates it, it fails and return null?

SheldonFromBBTOP•6/24/25, 7:11 AM

I am doing this because of a very specific issue of cpu time limits on cloudflare workers, due to that I thought of a workaround of hosting the auth server on vercel and main app on cloudflare, while I may upgrade to paid plans or higher limits in future, I want to have a solution or workaround for now, I am doing this first time i.e the different or separate server for auth and main app.

Ssebciotp The cookies are not send between different domains because its not secure and ge...

SheldonFromBBTOP•6/24/25, 7:12 AM

This doesn't seem to work, it only specifies for subdomain apps and not totally different TLD or domains

momoneko•6/24/25, 7:15 AM

This is a cookie behavior in general; you can't set cookies for google.comgoogle.com from facebook.comfacebook.com and viceversa (or

a.xyz

a.xyz

from

foo.abc

foo.abc

) ; but you can set cookies for app.foo.abcapp.foo.abc from auth.foo.abcauth.foo.abc

momoneko•6/24/25, 7:19 AM

I don't remember if Cloudflare offers this for the free plan or not (not using Cloudflare at the moment), but you can set a DNS CNAME record for auth.foo.abcauth.foo.abc to point to

a.xyz

a.xyz

and disable proxy, so that the traffic doesn't pass through Cloudflare and cost you money.
This way, requests to auth.foo.abcauth.foo.abc will hit the vercel server directly and you'll be able to set the token.

SheldonFromBBTOP•6/24/25, 7:22 AM

Okay I'll try doing this and will update here

momoneko•6/24/25, 7:26 AM

Here's some docs to help you out https://developers.cloudflare.com/dns/proxy-status/#dns-only-records

Cloudflare Docs

Proxy status

While your DNS records make your website or application available to visitors and other web services, the Proxy status of a DNS record defines how Cloudflare treats incoming DNS queries for that record.

momoneko•6/24/25, 7:27 AM

also, don't forget to set advanced.cookies.domainadvanced.cookies.domain to

foo.abc

foo.abc

, otherwise the cookie will work only for auth.foo.abcauth.foo.abc

Ssebciotp The cookies are not send between different domains because its not secure and ge...

SheldonFromBBTOP•6/24/25, 7:28 AM

I had one doubt that, does better auth while validating the session (with getSession()) also inherently validates the domain it was set or created on?

SheldonFromBBTOP•6/24/25, 7:30 AM

with the session token

momoneko•6/24/25, 7:32 AM

it doesn't; the browser doesn't send contain domain data with the cookie - and from what I'm seeing, BA doesn't add any info in the cookie itself.

It does add a signature (the part after the dot), so it will check that the cookie was created by the same server that validates it

Mmomoneko it doesn't; the browser doesn't send contain domain data with the cookie - and f...

SheldonFromBBTOP•6/24/25, 7:35 AM

Okay, thanks for this info

SheldonFromBBTOP•6/24/25, 7:36 AM

So setting up separate servers on same domain (subdomain) , is the only actual solution here?

momoneko•6/24/25, 7:53 AM

That'd be the easiest, yea

You can look into using Bearer tokens, but that opens up a totally separate can of worms; at the very least you'll need to figure out a way of storing the token, then you need to set up CORS for your particular setup, then all API requests may or may not need to be changed (I'm actually not familiar with BA on the frontend

).

If I had the option, I'd go the subdomain route. But I think it's worth knowing that there's another option.

Mmomoneko That'd be the easiest, yea You can look into using Bearer tokens, but that open...

SheldonFromBBTOP•6/24/25, 8:02 AM

Yes, there must be another way, anyways thanks for the help, I'll update here If I come across any workaround or solution.

SSheldonFromBBT This doesn't seem to work, it only specifies for subdomain apps and not totally ...

sebciotp•6/24/25, 1:27 PM

haev you tried making the cookie have samesite set to none attribiute? the docs are bit unclear but i believe it's tottally possible withouit using subdomains

sebciotp•6/24/25, 1:27 PM

i mean the cookie attribiutes in you auth config

sebciotp•6/24/25, 1:32 PM

defaultCookieAttributes: {
    sameSite: "none",
    httpOnly : true,
    secure: false, // you can try changing this to see if true works in prod
}

defaultCookieAttributes: {
    sameSite: "none",
    httpOnly : true,
    secure: false, // you can try changing this to see if true works in prod
}

I mean this under advanced, if you're using backend then update cors to handle your domain also.
Also, i would recommend trying anything in incognito, as browser likes to cache everything

sebciotp•6/24/25, 1:33 PM

also, options like disableCSRFCheckdisableCSRFCheck in your auth config also may make a difference

stormej•6/24/25, 2:52 PM

I too have a similar issue

Ssebciotp ``` defaultCookieAttributes: { sameSite: "none", httpOnly : true, se...

SheldonFromBBTOP•6/24/25, 4:36 PM

I'll try doing this

SheldonFromBBTOP•6/24/25, 4:40 PM

Would it be appropriate to tag and ask for clarity or help from bekacru?

SheldonFromBBTOP•6/24/25, 4:41 PM

This issue seems to have unclear solutions and documentation, should be not this hard to resolve or atleast debug

SSheldonFromBBT Would it be appropriate to tag and ask for clarity or help from bekacru?

sebciotp•6/24/25, 7:22 PM

SSheldonFromBBT This issue seems to have unclear solutions and documentation, should be not this...

sebciotp•6/24/25, 7:23 PM

It's documented that it's way better to use a subdomain instead

SSheldonFromBBT This issue seems to have unclear solutions and documentation, should be not this...

momoneko•6/25/25, 9:18 AM

This is hard by design, specifically browser design
if it weren't, any website would be able to set any cookie for any other website, opening new avenues for DoS and data injection

There actually are options to do it, but it becomes messy real quick, and may have unintended consequences down the road

Some of things i know for sure work

you can do a double redirect, passing the cookie via a query param as described in https://stackoverflow.com/a/12370586; not really safe, cause the cookie value will be left in the browser history
you can make use of postMessagepostMessage, as suggested by another answer to the same question - https://stackoverflow.com/a/22935156
you could make a fetch request to
```
foo.abc
```
```
foo.abc
```
, passing the cookie in the body or headers, and the
```
foo.abc
```
```
foo.abc
```
could do a
```
Set-Cookie
```
```
Set-Cookie
```
; but then you need to figure out all the CORS needed for this

In either case, you can't make your cookie HttpOnlyHttpOnly, as JS needs to be able to access it in order to populate the params. But this makes you vulnerable to XSS

The OP of the question above actually wrote another, pretty comprehensive answer detailing the approaches above - https://stackoverflow.com/a/73599289; just reading through that should tell you how messy the approaches are.

If you decide to go through with any of them, good luck, and have fun

momoneko•6/25/25, 9:29 AM

@SheldonFromBBT, I just took a look at your qustion once again, and steps 2 and 3 kinda bug me

Auth server sends session token back to main app
Main app sets the token as a cookie on its domain

Seems like you actually figured out a way of sharing the cookie between the apps. How does this happen?

And if that's the case, does your token look like example 1 or 2?

rxuUpeKEyQPbVPMimw9Ib1vBxLcobHkwrxuUpeKEyQPbVPMimw9Ib1vBxLcobHkw
rxuUpeKEyQPbVPMimw9Ib1vBxLcobHkw.bkVHMxIs9jukr7U9tyaMZtmEp4oSTShi%2FqyTPT2VNp8%3DrxuUpeKEyQPbVPMimw9Ib1vBxLcobHkw.bkVHMxIs9jukr7U9tyaMZtmEp4oSTShi%2FqyTPT2VNp8%3D

If it's like in the first example, it won't work - the actual cookie also includes a signature. You can see it after the .. in the second example.

I assume you're parsing the signInEmailsignInEmail response and grabbing the token from there. You'll need to parse the headers of the response, and grab the cookie from the

Set-Cookie

Set-Cookie

response header. You'll need to add returnHeadersreturnHeaders to the call to signInEmailsignInEmail

If the above didn't make sense, then all my assumptions were wrong and we'll need more details about your setup

Mmomoneko @SheldonFromBBT, I just took a look at your qustion once again, and steps 2 and ...

SheldonFromBBTOP•6/25/25, 9:37 AM

Yes, it's almost same

SheldonFromBBTOP•6/25/25, 9:38 AM

I do get the session token in this format: <>.<>, as you said

SheldonFromBBTOP•6/25/25, 9:39 AM

The thing is this flow or logic does work for same domain or app, just not for different domain apps

SheldonFromBBTOP•6/25/25, 9:40 AM

I do get the session token and upon setting it as the cookie, I do get signed in as expected

SheldonFromBBTOP•6/25/25, 9:40 AM

Everything went over my head when I applied this for different apps

SheldonFromBBTOP•6/25/25, 9:40 AM

And yes its url decoded as expected

Mayur•7/8/25, 5:04 PM

Im facing the same issue, now i have placed my auth and my app as 2 subdomians under a same domain and it worked . But what if i want a mobile app to use my same Auth Backend . How can i solve this . Im using Honojs , Better Auth , google oauth with mongodb deployed on cloudflare workers

Auth not working across completely different domains (app)

Similar Threads

Similar Threads

Similar Threads