Enabling Post-Signup Email Verification without Blocking User Sign-In on Supabase (Resend)

[SergejSi]

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

I am trying to improve the user experience in my application by allowing users to sign in immediately after registration, even before verifying their email. The default behavior in Supabase requires users to verify their email before they can sign in, which I believe creates a poor user experience. I want to give users the ability to verify their email after they have signed in by sending them a verification link or preferably a code to verify their email. However, I'm facing an issue where I cannot send a verification link to users using the Supabase Auth resend method for this purpose.

To Reproduce

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

1. Initialize Supabase auth with a user's email and password.
2. Try to send the user a verification email after sign-up (not blocking sign-in) using the resend method as follows:

   await supabase.auth.resend({
       email: user?.email as string,
       type: "signup"
   });

3. Notice that no verification email is received.

Expected behavior

I expect to be able to send users a verification email (or ideally a verification code) after they have signed up and signed in, without blocking their initial sign-in due to unverified email. This approach aims to enhance the user experience by not forcing email verification before the user can explore the application.

Additional context

This issue is critical for user onboarding and directly impacts the user experience in our application. If there's an alternative approach to achieve this behavior or if someone has solved a similar issue, insights would be greatly appreciated. Ideally, I would like to send a verification code that users can enter to verify their email, but currently, the primary issue is the inability to resend the verification link after the user signs in.

[utkarsh1097]

I believe you have set Confirm email: Users will need to confirm their email address before signing in for the first time. to false. If that is the case, the user email is considered "verified" (you can confirm this by looking at the user.email_confirmed_at field. It is null when the email has not been verified and has some value when it is. Any user that registered when the Confirm email setting was set to off, will have their email_confirmed_at value close to the created_at timestamp.

If you want to implement "mail verification post sign-up" I would recommend using a custom metadata attribute (maybe a key like email_verified) which can be true/false depending on whether the mail is verified or not. But then you would have to implement your email verification API (whose responsibility would be to keep track of the verification tokens and set email_verified to true).

Edit: For reference, this is how Supabase's resend API works: https://github.com/supabase/auth/blob/master/internal/api/resend.go#L64-L172

[devjume]

+1 For this feature.

According to docs this have been possible but is deprecated? But I couldn't find more when, why and in what PR.
And I cannot find any information what "Allow unverified email sign in" setting is/was.

There is old issue for this without update supabase/auth#453

[devjume]

I had idea for hacky workaround which should be possible. But I didn't properly test this! See bottom

1. Set "Confirm email" to false
2. Sign up user with supabase.auth.signUp()
3. Create database triggers that call supabase edge function Supabase youtube - Database Webhooks and Edge Functions
   
4. On the edge function do:

const { data, error } = await supabase.auth.admin.generateLink({
  type: 'magiclink', <---- NOTE: 'signup' wont work here.
  email: '[email protected]'
})

[PREVIOUS RETURNS OTP TOKEN]

Next use your own transaction email provider (AWS SES, Resend etc.) to send that token to the users email...

5. Create input to confirm OTP token. Then verify the token and confirm user email on backend.

const { data, error } = await supabase.auth.verifyOtp({ email, token, type: 'email'})

const { data: user, error } = await supabase.auth.admin.updateUserById(
  '6aa5d0d4-2a9f-4483-b6c8-0cf4c6c98ac4',
  { email_confirm: true }
)

I didn't test this properly because it would require me to set webhooks and triggers manully on production. Because on production and local development webhook url is different.

Production: https://XXXX.supabase.co/functions/v1/hello-world
Local env: http://host.docker.internal:54321/functions/v1/hello-world

That causes issues with migration files. As it is not possible to reference right url in the migration files.

Here are two more issues related to this that I found:
https://github.com/orgs/supabase/discussions/680
https://github.com/orgs/supabase/discussions/8197

[utkarsh1097]

I am also interested in a way to enable post-signup verification. While a custom backend (using supabase.auth.admin on the server side + custom metadata) should help develop an alternative solution, I was wondering whether there can be built-in support for this problem without major changes.

A few observations:

• config.Mailer keeps track of 2 booleans of interest: Autoconfirm and AllowUnverifiedEmailSignIns (Note that the default value of AllowUnverifiedEmailSignIns is False).

  The "Confirm email" switch corresponds to Autoconfirm (as seen in the screenshot below). But I don't see any way to control AllowUnverifiedEmailSignIns from the GUI.

• While /signup (For email-based signups) makes use of Autoconfirm for deciding whether to mark the user's email as verified or not, /token?grant_type=password (For email & password-based sign-ins) is not making use of AllowUnverifiedEmailSignIns for deciding whether to let user sign in with the given credentials.

  At the moment, AllowUnverifiedEmailSignIns is only being used in the case of external identity providers (Apple/GitHub/Facebook, etc).

With this, I think it would be great to allow devs to configure AllowUnverifiedEmailSignIns from the dashboard, and use its value for email & password-based sign-ins. I believe doing this (along with potentially making slight tweaks in the sign-up API as well) should address the issue.

[allenchuang]

Where is this option?

[nadimify]

+1 to this feature request, would help a lot in onboarding experience

[kowalgregy]

It's crazy that this isn't supported — a fundamental feature for good UX. You want the user to access parts of your app before verifying the email (as an example).

[travisvn]

It's crazy that this isn't supported — a fundamental feature for good UX. You want the user to access parts of your app before verifying the email (as an example).

Absolutely agreed.

I did not think to check that this was an option before completely designing my project around Supabase Auth, as it is a feature that the majority of modern, consumer-facing services implement.

A bit frustrating to have to find a workaround to this, particularly having paid for Supabase Pro...

Anyone have suggestions on how to maybe approach this without risking potential spam from bots on account signups?

And then, of course, how to handle what essentially amounts to having to recreate a portion of the auth architecture (handling email templates, email sending, token generation and verification, middleware adjustments, etc)...?

Maybe forcing (or strongly encouraging) OAuth signups is the best way forward to get around the reduced onboarding user experience...

[biering]

I have the same issue. Verifying the email after signup is a pretty common thing which is currently not really possible. Any updates on that topic?

[williamwjs]

May I ask if there's any updates to this? This flow is also very crucial to us, as we do not want verification to block the user onboarding process.

So what we want to achieve is that - upon signup, no verification is needed, and the user could go through onboarding as needed. After 1hr of sign up, we check for whether the email is verified, and if still not verified, we then block the site access to prompt the user to verify first.