nextjs 13 / PKCE flow is not supported on signups with autoconfirm enabled

[bmichotte]

Bug report

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

Describe the bug

Following the documentation for auth with nextjs13,
I receive an error AuthApiError: PKCE flow is not supported on signups with autoconfirm enabled when I try to signup a user.

I tried both client and server action versions without success.

System information

• OS: macOS
• Version of supabase-js: 1.64.8
• Version of supabase/auth-helpers-nextjs: 0.7.0
• Version of Next.js: 13.4.4

Additional context

I'm currently working on a self-hosted version of supabase for the development.

[regalstreak]

Locally, I just had to set email_confirmations as true to get rid of this

Looks like PKCE is going to be the only flow they'll be supporting

[liawifelix]

Locally, I just had to set email_confirmations as true to get rid of this

Looks like PKCE is going to be the only flow they'll be supporting

It works, thanks a lot

[estebangarcia21]

For those who still want the user to sign in with a session without the user confirming their email, my temporary workaround was to manually set the email_confirmed_at and confirmation_sent_at to the current date in the database and sign the user manually.

const { data } = await supabase.auth.signUp({ email, password });

const verificationTime = new Date().toISOString();

// Update the email_confirmed_at and confirmation_sent_at columns from the auth.users table.
await prisma.users.update({
  data: {
    email_confirmed_at: verificationTime,
    confirmation_sent_at: verificationTime
  },
  where: { id: data.user.id }
});

const { data: _data } = await supabase.auth.signInWithPassword({ email, password });

const session = _data.session;

[byamasu-patrick]

@bmichotte has this already been fixed?
I can also confirm that my code is working perfectly fine but when I try to signup with email I am getting this error.

PKCE flow is not supported on signups with autoconfirm enabled

I disabled Confirm email inside Auth Providers in supabase because I don't want to see an email being sent automatically when the user create an account. Just after disabling this feature in supabase i am getting that error message from supabase. Is there any solution for this issue from the supabase team? I am using nextJS 13 and "@supabase/auth-helpers-nextjs": "^0.7.2",

[silentworks]

@byamasu-patrick As the error stated you can't use the pkce flow with confirm email turned off. The latest versions of auth-helpers which support the app router (which now mean everything can be done server side) requires pkce for this to work.

[tholder]

PKCE flow with email confirmation though seems to be suffering another bug #587

[jramiroz98]

You have to roll back to version 0.9.4
At least that's how it worked for me using SvelteKit

[byamasu-patrick]

@jramiroz98 I will try your approach and see if it is going to work with. Because my goal is to totally disable the default behavior when someone create an account the deafault confirmation email should not be sent to the user.

[eialanjones]

Another workaround:

// Create a "admin client"
import { createClient } from '@supabase/supabase-js';

export const SupabaseAdmin = (req?) => {
  return createClient<Database>(
    process.env.NEXT_PUBLIC_SUPABASE_URL,
    process.env.SUPABASE_SERVICE_ROLE,
  );
};

// then use it to create the new user
const {
      data: { user },
    } = await SupabaseAdmin().auth.signUp({
      email: email,
      password,
    });

// then log in using the serverside supabase normally 
await supabase.auth.signInWithPassword({ email, password });

[i-bsd]

Locally, I just had to set email_confirmations as true to get rid of this

Looks like PKCE is going to be the only flow they'll be supporting

This is not a fix. Nor is using supabase admin client-side.

This is a really frustrating update as it adds a lot of friction to new customer signups making them check their email.

[StockBet]

yes exactly. why is the default method the one with highest friction?? smh bruh

[piccinnigius]

for me doesn't work, in local environment created user by hand for now :/

[skoshx]

I hope someone from the Supabase teams notices this, it is totally unacceptable, that in this day and age we should start requiring our users to confirm their emails like this was back in 2015.

Customers want to log in with no friction, that's why there is magic link log in.

I just upgraded to the PKCE flow, and now I realize that I will need to go back to using the old flow, because PKCE doesn't work if you want to manually send the login link email (because you want it to be branded)...

[i-bsd]

I hope someone from the Supabase teams notices this, it is totally unacceptable, that in this day and age we should start requiring our users to confirm their emails like this was back in 2015.

Customers want to log in with no friction, that's why there is magic link log in.

I just upgraded to the PKCE flow, and now I realize that I will need to go back to using the old flow, because PKCE doesn't work if you want to manually send the login link email (because you want it to be branded)...

Exactly. I'm sure we're going to lose sales forcing new customers to jump through hoops to create an account.

One thought I had (haven't tried it yet) is to use NextJS server actions to use supabase admin to add the customer, but I don't know if this feasible or secure, plus it's still an alpha feature. Might be the only way to do this if supabase don't correct the changes they've made.

[skoshx]

@thorwebdev @silentworks Sorry for the mention, but in this case it seems warranted, as the implications of this has a massive impact on Developer Experience.

Following discussions in #562 it became apparent that pkce flow is the only one supported going forward. Also it became apparent that with the pkce flow the Developers using Supabase are now forced to have their customers confirm emails upon signup, adding friction to both the Developer Experience as well as the customer experience. (Also as an aside, I'm sending magic links manually using .generateLink, which also breaks the whole login, because it doesn't send the confirmation email)

Following discussions in #567 it becomes apparent that the migration to the pkce flow complicates other types of flows, such as the one in this issue. There doesn't seem to be clear answers to many of the problems us Developers are facing with this new flow. Also, the conclusion seems to be that "In a nutshell, magic links no longer work with pkce, use the login code instead" (which once again adds friction especially to users not too familiar with login codes)...

I would like to hear a bit more about the future of Supabase as an auth provider... Is Supabase completely going to throw away magic links, and force users of their auth systems to have to confirm their emails going forward?

I guess what I'm curious to understand is, why make all these changes that seem to have been released and pushed towards so hastily, without exploring the many repercussions of them, and with seemingly little care for the decrease in Developer Experience?

Ps. I hope the answer isn't gonna be to "just use 0.9.x", because in that case we would be stuck on that version forever😂

[silentworks]

Hey @skoshx thanks for your detailed points here I will try and explain what happened and what we are doing to rectify this.

Firstly this isn't a marketing gimmick (i.e your statement in a previous post (because you want it to be branded)) this was purely an engineering oversight mainly on my part, we had this feature in pre-release for months before we decided to release it as a full release, at that point we didn't get any feedback about any of the flows not working or not being ideal, I tested out a most of these flows but only on one device/browser and also I always had email confirmation on as this is how most services I've interacted with has it setup. One of the main push for having pkce in all the flows was to fix our server-side story, before there was an hard requirement on the client-side in order to do signUp's and signIn's with Supabase auth, the pkce flow meant there was now a way to do this via the server-side only without the client being involved at all.

Rectifying this isn't as straight forward as one might think it is as we have to make some changes internally to our systems hence why my first recommendation is to revert to the previous version of the auth-helpers (no you won't be stuck on that version as we are working on fixing the current issue). We are currently working on a way to have both fully server-side auth along with autoconfirm working too.

[skoshx]

Hello @silentworks , and thanks for the thorough answer!

I understand the push towards pkce and that having these flows work server-side only is important especially when it seems that the industry is pushing towards that direction.

I'm glad to hear that this is something that you plan on fixing, and understand that possible changes to accomodate these fixes will take time, and I will be eagerly waiting for the fixes! :)

[MartinPELCAT]

Got the same problem with the SignUp and the PKCE flow not supported.

Worked around that by :

• Creating the user with the supabase admin (admin key) on a serverAction
• Then login the user on the client.

If you don't have server actions enabled, I think you could create an API route that does the same

It seems to work pretty fine.

    const { data } = await supbaseAdmin.auth.admin.createUser({
      email,
      password,
      user_metadata: { displayName } satisfies UserMetadata,
      email_confirm: true,
    });

[i-bsd]

Got the same problem with the SignUp and the PKCE flow not supported.

Worked around that by :

• Creating the user with the supabase admin (admin key) on a serverAction
• Then login the user on the client.

If you don't have server actions enabled, I think you could create an API route that does the same

It seems to work pretty fine.

    const { data } = await supbaseAdmin.auth.admin.createUser({
      email,
      password,
      user_metadata: { displayName } satisfies UserMetadata,
      email_confirm: true,
    });

Great.

I think an API route handler might be a better way, since server actions aren't production-ready yet.

[mirsahib]

I can't signup user using createClientComponentClient from @supabase/auth-help-nextjs but the default createClient function is working fine

works

const supbase = createClient(url,anon_key)
const {error} = supabase.auth.signup(email,password)

don't works

const supbase = createClientComponentClient()
const {error} = supabase.auth..signUp({
        email: data.email,
        password: data.password,
        options: {
         emailRedirectTo: `${location.origin}/auth/callback`,
         },
      });

and also setting email_confirmations to true in config.toml don't work for me

[Nicolasvegam]

Hey @skoshx thanks for your detailed points here I will try and explain what happened and what we are doing to rectify this.

Firstly this isn't a marketing gimmick (i.e your statement in a previous post (because you want it to be branded)) this was purely an engineering oversight mainly on my part, we had this feature in pre-release for months before we decided to release it as a full release, at that point we didn't get any feedback about any of the flows not working or not being ideal, I tested out a most of these flows but only on one device/browser and also I always had email confirmation on as this is how most services I've interacted with has it setup. One of the main push for having pkce in all the flows was to fix our server-side story, before there was an hard requirement on the client-side in order to do signUp's and signIn's with Supabase auth, the pkce flow meant there was now a way to do this via the server-side only without the client being involved at all.

Rectifying this isn't as straight forward as one might think it is as we have to make some changes internally to our systems hence why my first recommendation is to revert to the previous version of the auth-helpers (no you won't be stuck on that version as we are working on fixing the current issue). We are currently working on a way to have both fully server-side auth along with autoconfirm working too.

I couldn't find that version in nextjs tho, anoyone knows?

[silentworks]

We will be reverting the autoconfirm not supported with pkce flow as we are improving the auth flow for the SSR side of things. The new release is ready but we haven't pushed this to any project as yet since we are still testing out different use cases.

https://github.com/supabase/gotrue/releases/tag/v2.83.0

[jkhaui]

yes exactly. why is the default method the one with highest friction?? smh bruh

PKCE should be supabase's default method as it's more secure than other auth strategies like oauth implicit flow (and not even Firebase has PKCE flow support).

But I'm totally with you (and everyone in this discussion apparently) about the unnecessary PITA caused by further coupling the flow to email confirmation.
I'm curious if there's a technical reason they had to be implemented together? Or is it just a suggested "best practice" thing being forced on clients

[imalexlee]

Until the awesome people at supabase make a more legit fix for this, the way i currently traversed this was to roll back the @supabase/auth-helpers-nextjs version to 6.1.0. By doing this, you have to use the slightly older API. here is what to replace (at least what i replaced in my use case)

yarn remove @supabase/auth-helpers-nextjs &&
yarn add @supabase/auth-helpers-nextjs@6.1.0

server component client

import { createServerComponentClient } from "@supabase/auth-helpers-nextjs";
import { cookies } from "next/dist/client/components/headers";
const supabase = createServerComponentClient({ cookies });

the above was replaced with the code below to work with version 6.1.0

import { createServerComponentSupabaseClient } from "@supabase/auth-helpers-nextjs";
import { cookies, headers } from "next/dist/client/components/headers";
const supabase = createServerComponentSupabaseClient({ headers, cookies });

client/browser component client

import { createClientComponentClient } from "@supabase/auth-helpers-nextjs";
const supabase = createClientComponentClient();

the above was replaced with the code below to work with version 6.1.0

import { createBrowserSupabaseClient } from "@supabase/auth-helpers-nextjs";
const supabase = createBrowserSupabaseClient();

Of course, this worked in my app and might not work in yours. Hoping they issue a real fix soon!

[caleb531]

@omonk Glad it worked for you!

@silentworks I just checked my Docker images, and it looks like the gotrue image is at v2.82.4, which would explain the issue for me.

So with that gotrue-version file already created with v2.92.1 as the contents, I tried supabase stop, deleting that image, then running supabase start again. It still downloads v2.82.4 for some reason.

$ cat supabase/.temp/gotrue-version 
v2.92.1
$ supabase start
v2.82.4: Pulling from supabase/gotrue
edb6bdbacee9: Pull complete 
e66da05e113e: Pull complete 
b624d6c296c8: Pull complete 
972d4c810416: Pull complete 
e322cf576388: Pull complete 
Digest: sha256:2e4cf4e090ad0128a7e7a9fa468846c9116e000cc7bebe7a12d8acc6ad75c1be
Status: Downloaded newer image for public.ecr.aws/supabase/gotrue:v2.82.4
Started supabase local development setup.

         API URL: http://localhost:54321
     GraphQL URL: http://localhost:54321/graphql/v1
          DB URL: postgresql://postgres:postgres@localhost:54322/postgres
      Studio URL: http://localhost:54323
    Inbucket URL: http://localhost:54324
      JWT secret: <secret>
        anon key: <secret>
service_role key: <secret>

Update

So I think I found the root cause of the issue. In my lockfile (pnpm-lock.yaml, in my case), I

  /@supabase/supabase-js@2.33.1(encoding@0.1.13):
    resolution: {integrity: sha512-jA00rquPTppPOHpBB6KABW98lfg0gYXcuGqP3TB1iiduznRVsi3GGk2qBKXPDLMYSe0kRlQp5xCwWWthaJr8eA==}
    dependencies:
      '@supabase/functions-js': 2.1.1(encoding@0.1.13)
      '@supabase/gotrue-js': 2.46.1(encoding@0.1.13)
      '@supabase/postgrest-js': 1.8.0(encoding@0.1.13)
      '@supabase/realtime-js': 2.7.4
      '@supabase/storage-js': 2.5.1(encoding@0.1.13)

But the latest version of supabase/gotrue-js (per https://github.com/supabase/gotrue-js/releases) is v2.48.1. And because I typically use npm-check-updates / ncu (which only reads from package.json) to update my dependencies, I wasn't seeing an update for gotrue-js.

I think https://github.com/supabase/supabase-js/blob/master/package.json needs to be updated to have the minimum semantic versions of all supabase/supabase-js dependencies to be the latest versions of those dependencies. Right now, it shows some older versions:

"dependencies": {
  "@supabase/functions-js": "^2.1.0",
  "@supabase/gotrue-js": "^2.46.1",
  "@supabase/postgrest-js": "^1.8.0",
  "@supabase/realtime-js": "^2.7.4",
  "@supabase/storage-js": "^2.5.1",
  "cross-fetch": "^3.1.5"
},

Granted, even after I explicitly run pnpm update @supabase/gotrue-js, delete the docker image, then stop/start the docker containers, it's still fetching v2.82.4. Not sure why it's stuck on fetching the older image.

[jdgamble555]

@silentworks - When does this get rolled out locally for testing?

J

[caleb531]

@silentworks I think I found why Supabase CLI keeps downloading the supabase/gotrue:v2.82.4 image, even after clearing pnpm store, reinstalling node modules, etc. It's because supabase/supabase (master) is still pointing to the 2.82.4 image in docker-compose.yml:

auth:
  container_name: supabase-auth
  image: supabase/gotrue:v2.82.4

Source: Line 89 of the docker-compose.yml file.

I also found another reference to v2.82.4 in supabase-cli:
https://github.com/supabase/cli/blob/main/internal/utils/misc.go#L41

Can someone please update these places to use the latest supabase/gotrue image? Or is there a way I can manually update the image versions myself?

[silentworks]

@caleb531 the supabase/supabase repo docker-compose.yml file has no relation to the CLI. You might need to change your project_id in your supabase/config.toml file in order for the new image to download as docker would just run your setup with the existing image it already has from previous container build. The process I have stated works as @omonk did the steps and it worked for him.

[silentworks]

@silentworks - When does this get rolled out locally for testing?

J

I stated how to get the latest using the steps above. When will this be officially set in the CLI, I'm not sure as we do take a bit longer to add stuff to the CLI than we do to the hosted platform.

[silentworks]

@silentworks I think I found why Supabase CLI keeps downloading the supabase/gotrue:v2.82.4 image, even after clearing pnpm store, reinstalling node modules, etc. It's because supabase/supabase (master) is still pointing to the 2.82.4 image in docker-compose.yml:

auth:
  container_name: supabase-auth
  image: supabase/gotrue:v2.82.4

Source: Line 89 of the docker-compose.yml file.

I also found another reference to v2.82.4 in supabase-cli: https://github.com/supabase/cli/blob/main/internal/utils/misc.go#L41

Can someone please update these places to use the latest supabase/gotrue image? Or is there a way I can manually update the image versions myself?

@caleb531 to update it yourself would be the steps I provided you with earlier.

[tolluset]

@caleb531 you can create a file called gotrue-version inside of the supabase/.temp directory and add the version number you want to use in that file and it will pull the image down for you to use.

Steps to take:

• supabase stop
• create gotrue-version file inside of supabase/.temp directory
• Type the version number you want inside of the gotrue-version file v2.92.1
• supabase start and this should pull the new image

After downloading new images, signup worked. Thanks!

[jdgamble555]

I stated how to get the latest using the steps above. When will this be officially set in the CLI, I'm not sure as we do take a bit longer to add stuff to the CLI than we do to the hosted platform.

@silentworks - I think you should move this up the ladder as a problem (the fact that it takes longer to add stuff to CLI). People develop before they update their production versions, if anything this is backwards. I keep reading everywhere that Supabase tries to have the local version match the hosted platform, yet huge issues like this continue to create problems for people. Hence, why we see many complaints about developing on local.

That being said, I appreciate you and the work around.

J

[silentworks]

@jdgamble555 we started as a hosted first solution, there was no CLI until like around a year ago. Most of our users use the hosted first approach too but this is something we have started putting effort into fixing (we still have users whose machines cannot handle Docker as its resource heavy). From the outside everything might look like a quick and easy PR but thats not how all the moving parts of Supabase work. I come from a background of local development first approach as this is how it was with PHP, but you need to remember that Supabase isn't a language or a framework, its an amalgamation of different open source technologies being provided to an user, this is something thats not easy to deliver for local development.

[DOZBORNE]

@caleb531 you can create a file called gotrue-version inside of the supabase/.temp directory and add the version number you want to use in that file and it will pull the image down for you to use.

Steps to take:

• supabase stop
• create gotrue-version file inside of supabase/.temp directory
• Type the version number you want inside of the gotrue-version file v2.92.1
• supabase start and this should pull the new image

Just found this! Works!

Yeah, if it didn't pull images, just a docker issue. Similar to when using docker compose, you may have to "force" pull images using docker compose pull, which will force fetch latest images. Same thing in this case, just ensure that the image pulls.

Thanks for your time @silentworks !

[silentworks]

I'm closing this out as it has been resolved on hosted Supabase and can be resolved in local Supabase following the instructions I've left on this issue.

[piccinnigius]

Hi @silentworks when creating the file i got this:

invalid reference formatema...
                        Retrying after 4s: public.ecr.aws/supabase/gotrue:v2.95.0

invalid reference formatema...
                        Retrying after 8s: public.ecr.aws/supabase/gotrue:v2.95.0

invalid reference format

any hint?

EDIT: it was caused from an additional line ending added by IntelliJ

[silentworks]

@piccinnigius it is adviced to not use a version locally that hasn't been deployed to the platform as yet. The current version that has been deployed to the platform is v2.92.1.

[piccinnigius]

@silentworks ok thanks so much for the advice 🙏

[jdgamble555]

@silentworks - A suggestion about closing threads. There are developer and user reasons to not close an issue until it is actually fixed, not with a work-around, which is what this is. Anyone who is using the latest local version of Supabase and trying to test an auth flow could come across this error and need to read this Github issue. Not only is your fix in the middle of this thread and hard to find, it will be under closed issues. It might be advantageous to keep this open for those people until the CLI update is pushed.

That being said, on a different note, I was getting this error when using the fix with supabase db reset:

When I use the "v2.92.1," I am getting the:

"Failed to load configuration: required key API_EXTERNAL_URL missing value"

Which is said to be fixed in the latest cli version: supabase/supabase#16702

However, I can't use the latest CLI version, or I will not have this issue fixed. Perhaps I a missing something here.

Thanks,

J

[silentworks]

@jdgamble555 any reason why you can't use the latest CLI version? btw the issue you are having now isn't related to this thread, probably best to move it over to the CLI repo and tag me there.

You might be confusing what issue this thread is about when you say it hasn't been fixed. The original author of this issue said this wasn't working in self-hosted (not CLI) but this has been fixed in both hosted and self-hosted (since this is up to a user to manage and they can simply pull the docker container for the gotrue version with the fix mentioned).

The fix for anyone using the CLI is stated above in this comment #569 (comment)

[jdgamble555]

@silentworks - Well you need the CLI to install the docker, but this is a moot point now. Got it working by deleting all docker files and reinstalling (with the gotrue-version file intact).

Thanks for you help :)

My other point was just to not close this until the gotrue version is pushed as the default version on docker for the reasons I mentioned above.

J

[jeremypeters]

I've just hit the same issue as @jdgamble555. I've had to add v2.92.1 to the gotrue-version as the recommended workaround to prevent the PKCE error, but now I am also experiencing the same "Failed to load configuration: required key API_EXTERNAL_URL missing value" error using this version.

[raulghm]

Upgrading supabase package to last version resolve the issue in my case.

[jdgamble555]

The latest cli version seems to have updated gotrue, so you don't need the workaround anymore.

J

[rdewolff]

I can confirm that updating my local supabase instance has fixed the issue 🕺🎉

Simply stop and start the supabase instance, it has downloaded the last version and works.

supabase stop
supabase start

Thanks for everyone that took the time to investigate the issue and help solve it :)