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

[bmichotte]

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

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 https://github.com/supabase/auth-helpers/issues/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!

[cuio]

@michelp please help

[ramazan-umutlu]

Same error .. PKCE flow is not supported on signups with autoconfirm enabled

"dependencies": { "@supabase/auth-helpers-nextjs": "^0.7.3", "@supabase/gotrue-js": "^2.46.1", "@supabase/supabase-js": "^2.31.0", "@types/node": "20.4.5", "@types/react": "18.2.17", "@types/react-dom": "18.2.7", "autoprefixer": "10.4.14", "next": "13.4.12", "npm": "^9.8.1", "postcss": "8.4.27", "react": "18.2.0", "react-dom": "18.2.0", "supabase": "^1.82.2", "tailwindcss": "3.3.3", "typescript": "5.1.6" } },

As a new js dev I shouldn't search for these errors i mean. Just trying to register user.. Should i quit?

[Surf-N-Code]

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

Can we use this new tag yet and if so, how? :)

[silentworks]

@Surf-N-Code that tag hasn't been deployed to any project as yet. It will get deployed in a week or so. Current deployed tag is 2.82.4.

[konstantinlindner]

Any update on this? How can I enable auto-confirm without getting the PKCE error? I'm not looking for a workaround, just basic functionality.

[faithyeenxin]

@imalexlee hi, I've tried your method and it works in creating my user without email verification! Thank you!

However I'm trying to set up a middleware to check routes whether session is available and redirect them if not.. however when I do this, session does not exist and is null.

What is this so?

`export async function middleware(req: NextRequest) { const res = NextResponse.next(); const requestUrl = new URL(req.url); // Create a Supabase client configured to use cookies const supabase = createMiddlewareSupabaseClient({ req, res });

// Refresh session if expired - required for Server Components // https://supabase.com/docs/guides/auth/auth-helpers/nextjs#managing-session-with-middleware const { data: { session }, } = await supabase.auth.getSession();

console.log(middleware session: ${session}); if (!session) { return NextResponse.redirect(requestUrl.origin); } return res; }

export const config = { matcher: "/home", };`

[caleb531]

@silentworks Is there any update as to when gotrue v2.83.0 will be deployed to a project? I just ran into this error myself, and am running all the latest versions of supabase packages:

• @supabase/supabase-js 2.33.1
• @supabase/auth-helpers-nextjs 0.7.4

Any timeline you could provide would be greatly appreciated! Love the work that Supabase does.

[silentworks]

@caleb531 that version should already be on your project. I just checked and we rolled out v2.92.1 some weeks ago which would include all fixes from v2.83.0. If you are on a free project try pausing/unpausing to get the latest.

[caleb531]

@silentworks Well, I did confirm that the error is absent on my live Staging site's Sign Up form (running on Supabase hosting), just not in my local dev server (http://localhost:3000).

I have already tried updating the supabase package to the latest (v1.88.0), then running supabase stop and supabase start to download the images fresh. But I'm still getting the PKCE error locally.

Is there anything else I need to do to "reset" gotrue in my project? Or any special gotrue configuration I need to add to the local repository?

[silentworks]

@caleb531 which version of the CLI are you currently using?

[caleb531]

@silentworks

@caleb531 which version of the CLI are you currently using?

Version 1.88.0:

$ pnpm exec supabase -v
1.88.0

[silentworks]

@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

[caleb531]

@silentworks So I create the gotrue-version file as you instructed, and I run supabase start:

$ pnpm exec supabase stop
⣷ Stopping containers...
Postgres database saved to volume: supabase_db_faith-dashboard
Postgres config saved to volume: supabase_config_faith-dashboard
Storage directory saved to volume: supabase_storage_faith-dashboard
Stopped supabase local development setup.

Then I run supabase start, but it doesn't seem to download any new images (even though it was doing so earlier this morning anytime I ran supabase start).

$ pnpm exec supabase start
⣻ Starting database from backup...
⣯ Starting containers...
⣯ Setting up Edge Functions runtime...
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>

With that, I start my local dev server again and receive the same PKCE error.

Is there a way to force Supabase to redownload the docker images fresh again? (preferably without wiping my Postgres database?)

[omonk]

@caleb531 good timing for me to come across this thread, i've just followed the steps above to set the gotrue-version and it has worked for me and pulling the new image and I'm no longer getting the PKCE error when creating an account

/path/to/repo/supabase/.temp/gotrue-version

Contents

v2.92.1

supabase start contents

v2.92.1: Pulling from supabase/gotrue
4060ece20d7a: Pull complete
dda6468f98aa: Pull complete
20ab543ed620: Pull complete
1c6042e25d55: Pull complete
53d6979e59b6: Pull complete```

[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