GoTrueClient intercepts non-Supabase initiated OAuth preventing manual login flows

[uncvrd]

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.

Describe the bug

Hi there, I've run in to an issue where Supabase Auth is intercepting url params/fragments that contain the keyword access_token in them even when auth requests aren't coming from a Supabase Auth initiated request.

For example, I use Supabase Auth for OAuth Login for social providers so I need to have detectSessionInUrl enabled. However, in my application I have a page for users to authenticate through Facebook Login to connect their Facebook Pages and Instagram Accounts.

I initiate this flow manually (outside of Supabase) using: https://developers.facebook.com/docs/instagram-platform/instagram-api-with-facebook-login/business-login-for-instagram

However the callback URL returns a string that looks like this:

https://my-clever-redirect-url.com/success/?#access_token=EAAHm...&data_access_expiration_time=1658889585&expires_in=4815&long_lived_token=ABAEs...

As you can see there is an access_token fragment. And if the user is logged in via Supabase already, this automatically logs the user out since it detects an access_token being returned in the URL, which is invalid and Supabase Auth uses this as a trigger to log the user out...

This issue occurs due to the check for implicitGrant here: https://github.com/supabase/auth-js/blob/8a1ec0602792191bd235d51fd45c0ec2cabdf216/src/GoTrueClient.ts#L311C31-L311C49

Where it checks if there are params for either (params.access_token || params.error_description)

Is there a way to prevent running this check on certain pages (like my redirect page) so there isn't this kind of conflict?

To prevent this, I thought I could just proxy my response through a server and rewrite the url to not interfere with Supabase but since this value is passed as a URL fragment, this data is not sent to a server and is only accessible in the browser...

Expected behavior

I expect to be able to use OAuth flow that isn't triggered by Supabase Auth without there being a conflict and Supabase intercepting non Supabase initiated Auth flows.

Screenshots

System information

• OS: MacOS
• Browser chrome
• Version of supabase-js: 2.43.5
• Version of Node.js: v20.12.0

[j4w8n]

Related: #911

[uncvrd]

yea exactly, for now I've had to pnpm patch the GoTrue client to do this

[jgennari]

That was helpful, @uncvrd. I'm having the same issue so I created a patch. Will keep an eye here for any updates.