@supabase/ssr fails with OAuth

[sroussey]

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

A clear and concise description of what the bug is.

To Reproduce

Steps to reproduce the behavior, please provide code snippets or a repository:

git clone https://github.com/sroussey/test-supabase
# add your key stuff to .env
npm run dev
# navigate to /login
# Choose one, in this case Google
# See error: Access blocked: Authorization Error (Invalid parameter value for code_challenge_method: 's256' is not a valid CodeChallengeMethod)

Expected behavior

Ability to login via OAuth

Screenshots

Additional context

The test repo was created using npx create-next-app -e with-supabase and just adding links to use OAuth. Maybe such a thing should be added to the base template.

[silentworks]

I can't see any issue here, the repo you provided and steps doesn't involve any Google OAuth setup. Also note when you get this type of error its generally because of a misconfiguration inside of the Google console. Please follow the steps here to configure your app correctly in the Google console https://supabase.com/docs/guides/auth/social-login/auth-google#configuration-web

[sroussey]

So... I have had google working for a long time. Using:

"@supabase/auth-helpers-nextjs": "^0.6.1",
"@supabase/auth-helpers-react": "^0.3.1",

It works fine. I tried upgrading, but then I got the same failure. I tried switching to ssr and got this same failure. That is why I created this simple example.

I believe the failure started when the libs changed to start using PKCE.

[iboss-ptk]

I'm having the same issue with "@supabase/ssr": "^0.0.10". doing this will not have the error but I don't think it's the way to go..

const supabase = createBrowserClient(PUBLIC_SUPABASE_URL, PUBLIC_SUPABASE_ANON_KEY, {
		global: {
			fetch
		},
		cookies: {
			get(key) {
				if (!isBrowser()) {
					return JSON.stringify(data.session);
				}

				const cookie = combineChunks(key, (name) => {
					const cookies = parse(document.cookie);
					return cookies[name];
				});
				return cookie;
			}
		},
		auth: {
			// change flow type to implicit
			flowType: 'implicit'
		}
	});

[iboss-ptk]

ok so with local supabase http://localhost:54321/auth/v1/authorize?provider=google&code_challenge=<base64encodedstring>&code_challenge_method=s256 fail but code_challenge_method=S256 works.

We might need to fix this line from supabase/gotrue-js for google provider, haven't tested with other provider though.

[iboss-ptk]

related issue: supabase/auth-js#770

[J0]

Hey team,

Thanks for reporting the issue and for supplying a test repository - I'm having a slight issue with replicating this though - this is what it looks like on my end.

The code_challenge_method param is intended for Supabase Auth and not for Google. There was a known issue in April where the code_challenge_method param was not sanitized which lead to the error. It was patched in late April/early May and we haven't observed repeat instances since then

Could I trouble you to try clearing both package-lock.json and node_modules and reinstalling after?

Alternatively, if there's a staging environment or another test repository where we can replicate this we can take a look further.

Let us know

Thanks!

[sroussey]

When setting up a staging server, I don't see the issue.

So maybe my local version of supabase is out of date? Is there a way to check?

[sroussey]

So maybe my local version of supabase is out of date? Is there a way to check?

I never use npx supabase start/stop so it never updates (I start and stop docker instead). I imagine many people do this.

You might put in some check that the client and server versions are compatible or something.

[J0]

Hey @sroussey,

Sorry for the delayed reply - was away for the holidays. Happy New Year and thanks for looking into the issue. For Auth one can check against the releases page against what's on the Docker container to see that it's up to date.

We're looking into alternative solutions and will relay to CLI team. Thanks for the feedback!