Supabase Authentication Token Cross-Instance Validation Issue

[jimmy3574]

Bug report

• [x ] I confirm this is a bug with Supabase, not with my own application.
• [x ] I confirm I have searched the Docs, GitHub Discussions, and Discord.

When a user has a valid Supabase authentication token from Instance A (e.g., Web App X), this token is being incorrectly accepted as valid by Instance B (a separate Web App with SUpabase Auth) without proper validation.

Steps to reproduce:

1. Log into Instance A
2. Access a separate Supabase application Instance B
3. The application accepts the authentication token from Instance A as valid, despite it being from a completely different Supabase instance

Expected behavior:

• Each Supabase instance should only accept tokens that were issued by that specific instance
• Tokens from other Supabase instances should be rejected as invalid
• The auth.getUser() and auth.getSession() methods should validate the token against the current instance

Actual behavior:

• Tokens from any Supabase instance are being accepted as valid
• auth.getUser() and auth.getSession() return successful responses with tokens from different instances
• This allows users to potentially authenticate into applications using tokens from completely unrelated Supabase instances

Security Implications:

• Cross-instance token acceptance could lead to unauthorized access
• Applications cannot reliably verify that a token was issued by their specific Supabase instance
• Potential for session hijacking if users have active sessions on multiple Supabase instances

Library:
-Supabase JS (Client SDK, not SSR)

[j4w8n]

I find it strange that getUser would do this since it makes a network request to the supabase instance backend to verify the jwt - which I have assumed gets validated against the jwt secret from that specific project.

[j4w8n]

Question: are you storing the auth token with a custom name that happens to be the same for each instance? Because by default it stores the project id in the name, so I can't imagine that being picked up by another instance.

[j4w8n]

I can confirm that solely depending on getSession to determine if there is a session - and using the same custom storage key for both instances - does trick my app into believing someone is logged in. However, none of my calls to the db yield any results since the jwt and user_id are wrong for the instance.

Furthermore, calling getUser returns the below error; which makes sense to me since it should be validating the jwt against the wrong supabase instance.

{
  data: { user: null },
  error: AuthSessionMissingError: Auth session missing!
}

[jimmy3574]

Yeah it's strange. Essentially, I'm building an admin CMS for staging/prod instance. So Supabase setup is org then instance for prod, staging, admin cms.

Running locally, was logged in as a prod test user, terminated server, ran server for admin cms, (running on different ports fyi). Closed browser tab for prod instance, opened admin and I was logged in as the prod user.

No custom storage key. Different env variables.

`const { data: { user }, error: userError } = await supabase.auth.getUser();

    console.log('User data:', user);
    console.log('User error:', userError);`

23:41:59.698'User data:', user: { id: 'bf7...-d02a-46c6...11-6...93b57', aud: 'authenticated

[jimmy3574]

Obviously with RLS etc was not able to do much but just found it to be a strange bug since it bypassed authguard so could navigate app etc.

[encima]

Just to clarify this one:

1. Using a token from one project does not allow you to authenticate against any other project
2. The token itself may be valid but requests and calls for sessions (or session refreshes) will not be
3. Sessions persisted in browser storage will keep a user logged in but only for that project

If this is incorrect, please correct me. If not, I think this could be closed

[jimmy3574]

I can replicate it every time - This await supabase.auth.getUser(); returns authenticated for a user doesn't exist in that instances auth.

It literally returns a user object with a user id and authenticated status. If that's not an issue to a SOC2 authenticated org, close away.

[j4w8n]

I can replicate it every time - This await supabase.auth.getUser(); returns authenticated for a user doesn't exist in that instances auth.

It literally returns a user object with a user id and authenticated status. If that's not an issue to a SOC2 authenticated org, close away.

That seems off because the Supabase client calling that function is tied to a specific instance. It doesn't have permission to auth itself against another.

[jimmy3574]

The only thing I can think of is that as the initial auth state is request by localhost, then even though that has been terminated, and localhost (although different port) is making another auth request its validating it. Not sure, but I can replicate it every time. Again, can't do anything as RLS kicks in but can navigate app.

[jimmy3574]

I should add both instances are under one org in Supbase, however with a different url and anon key obvs

[j4w8n]

I'm not able to replicate this. I get AuthApiError: invalid JWT, as expected.

• Single, hosted Supabase account, but two diff projects within it
• I even made it to where there is a custom storageKey of 'token' across both projects

1. Ran app A and logged in at http://localhost:5173
2. Closed browser tab
3. Stopped app A
4. Ran app B
5. Opened browser tab http://localhost:5173

My nav bar thinks someone is logged in because it only uses getSession; this succeeds because getSession doesn't verify anything against Supabase, just grabs a session based on the name 'token' (custom storageKey).

However, calling getUser on the server-side results in the proper error above.

Furthermore, it only shows me that error because I'm using the same storageKey across projects. Since you're not, it shouldn't even be finding an auth token to send with getUser, or process with getSession, when you're logged into your 2nd app.

[jimmy3574]

Image

Not sure why then. Might be my org instance then on Supabase

[Hallidayo]

Hi @jimmy3574 - Is this an issue still for you?

I'm going to move this over as a discussion.

[asadullah009]

This is expected behavior in some cases and does not mean Supabase is accepting cross-project authentication.

The important distinction is:

• getSession() mainly reads persisted session data from local storage/cookies
• getUser() validates against the current Supabase project backend

What likely happened here is that both local apps were sharing browser storage on localhost, so the second app temporarily picked up the session from the first app. :contentReference[oaicite:0]{index=0}

However, that does not mean the JWT is actually valid for the second Supabase project.

Evidence from the discussion:

• Another user reproduced the issue only when using the same custom storageKey
• Database/RLS requests failed correctly
• Maintainers confirmed sessions and refreshes are project-specific
• Invalid JWT errors were returned when validation actually occurred :contentReference[oaicite:1]{index=1}

The key point is:

getSession() != secure authentication validation

getSession() can return cached/local persisted auth state without verifying the token against the current project.

Real validation happens when:

calling protected APIs
refreshing sessions
querying DB with RLS
verifying JWT signature against the current project's secret

That is why:

navigation/auth guards may appear authenticated
but DB queries and authenticated backend calls fail

The most likely explanation here is localhost/browser storage collision between multiple apps during development, especially if:

same localhost domain
same storage namespace
stale persisted auth state
hot reload/dev server reuse

To avoid this entirely, set an explicit unique storage key per project:

const supabase = createClient(url, key, {
  auth: {
    storageKey: 'my-project-auth'
  }
})

and avoid relying solely on getSession() for authorization decisions.

Use:

await supabase.auth.getUser()

or backend JWT verification for actual auth validation instead.

[GitNimay]

This is almost certainly not a Supabase bug, but it is a genuinely confusing behavior worth explaining clearly.

The most likely cause: shared localStorage during local development

If both applications are running on localhost (even on different ports), they share the same localStorage origin. Supabase JS stores the session under a key like sb-<project-ref>-auth-token. If your two instances happen to use the same key format or if the client is reading the wrong key, Instance B's client can pick up Instance A's stored token and return it from getSession() without ever validating it against a server.

The critical distinction between getSession() and getUser()

getSession() reads the token from local storage and decodes it locally. It does not make a network request and does not verify the token signature against your Supabase project. This is by design and is documented behavior. A token from any well-formed JWT source will "succeed" here.

getUser() makes an actual network request to your project's /auth/v1/user endpoint with the token as a Bearer header. If this is genuinely accepting a token from a different project, that would be a real bug, but it is extremely unlikely on Supabase Cloud because each project has a unique JWT secret, and a token signed by Instance A's secret will fail cryptographic verification on Instance B.

How to verify which scenario you are in

Check what getUser() actually returns on Instance B when given Instance A's token:

const { data, error } = await supabase.auth.getUser(tokenFromInstanceA)
console.log(data, error)

If this returns a valid user with no error, check whether both projects share the same JWT secret (possible if self-hosted with copied config). If it returns an error, then the token is correctly being rejected at the server level and your application logic is the part accepting the session prematurely via getSession().

The fix if this is a localhost development issue

Use different hostnames instead of different ports for local development. You can add entries to /etc/hosts like 127.0.0.1 app-a.local and 127.0.0.1 app-b.local so each app gets a fully isolated localStorage context.

The fix if this is a production concern

Always use getUser() rather than getSession() for any security-sensitive authorization check. The Supabase docs explicitly recommend this for server-side validation. Never trust getSession() alone as proof of a valid, server-verified session.