If the refreshed token is significantly longer than the original token, supabase fails to cleanup the initial token, breaking MFA flows

[kaihenthorniwane]

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

A clear and concise description of what the bug is.

To Reproduce

Steps to reproduce the behavior:

1. Log into a provider and check that your token in cookies is not chunked into two cookies (sb-sb-auth-token)
2. Verify supabase MFA with a TOTP factor, using this code:

 const verifyMutation = useSWRMutation(
    'mfa-verify',
    async (_, { arg }: { arg: { factorId: string; code: string } }) => {
      const { data: challengeData, error: challengeError } =
        await supabaseClient.auth.mfa.challenge({
          factorId: arg.factorId,
        })

      if (challengeError) throw challengeError

      const { error: verifyError } = await supabaseClient.auth.mfa.verify({
        factorId: arg.factorId,
        challengeId: challengeData.id,
        code: arg.code,
      })

      if (verifyError) throw verifyError

      return true
    },
  )

3. After supabase refreshes the token post-MFA verification, the token will typically be significantly longer due to the added factors, which makes it long enough to get chunked into two cookies (sb-sb-auth-token.0 and sb-sb-auth-token.1)
4. If it is chunked into two cookies, the initial cookie sb-sb-auth-token will still be there even though it should have been replaced by sb-sb-auth-token.0 and sb-sb-auth-token.1. This will lead to errors as the user is unable to access MFA protected resources.

Expected behavior

When you verify with MFA, Supabase should cleanup the stale tokens in cookies regardless of their length. This actually works if the tokens are both 2 cookies long.

1. Initial cookie that chunks into two cookies:

2. After verifying with MFA, Supabase generates a token that chunks into two cookies, and successfully cleans up the previous token.

Screenshots

This is what the cookies look like in devtools with this bug, when the initial token is shorter than the refreshed token.

1. Initial cookie which is short enough to fit in one cookie:

2. After verifying with MFA, Supabase generates a token that chunks into two cookies, but fails to cleanup the previous token.

System information

• OS: MacOS
• Browser (if applies): Chrome
• Version of supabase-js: 2.42.5
• Version of Node.js: 20.10

Additional context

If you manually delete the stale token that failed to cleanup, supabase works perfectly. So the new token generated by supabase is not malformed, it is just the stale token not being cleaned up.

[tonilopezmr]

I had same problem and we didn't include MFA for now

[fonsiheruz]

I'm experiencing the same problem here

[sergaym]

I am having the exact same problem, please fix this is urgent!!

[fonsiheruz]

@filipecabaco @avallete @grdsdev
Thoughts?

[heyshrey01]

I am facing this issue too!

[hf]

Hey folks, this indicates an issue with how you have the createServerClient set up in middleware.

Can you please share your middleware.ts and all related functions for me to check?

Make sure you follow the official Next.js guides to the dot. https://supabase.com/docs/guides/auth/server-side/creating-a-client?environment=server-component

[kaihenthorniwane]

Hey folks, this indicates an issue with how you have the createServerClient set up in middleware.

Can you please share your middleware.ts and all related functions for me to check?

Make sure you follow the official Next.js guides to the dot. https://supabase.com/docs/guides/auth/server-side/creating-a-client?environment=server-component

Thank you so much! We were in the middle of an pages -> app router migration and as a result I think it was creating side effects that was interfering with the proper function of the library. We have migrated fully to app router now and this issue seems to be gone...