Enable the use of AllowUnverifiedEmailSignIns for Email provider

[utkarsh1097]

Background: supabase/supabase-js#991 (comment) (The comment, as well as the original issue)

For the Email auth provider, Supabase lets users configure whether the user "will need to confirm their email address before signing in for the first time". This field configures the Autoconfirm field in the mailer configuration used by the auth backend, and depending on this field:

• If set to true, the new user's email address is considered auto-verified.
• If set to false, new user registrations are required to confirm their email before they can sign in.
  • this limits the ability to offer a user experience where users can still sign into their accounts without verified emails, but with limited functional capabilities.

I believe the MailerConfiguration.AllowUnverifiedEmailSignIns field, which defaults to "false" for the Email auth provider, is well-suited to address this limitation. Currently, I see this field used only for external auth providers. However, I think its use case can be extended to email-and-password-based accounts as well.

[GaryAustin1]

There is a very new feature that might be a solution for what you are looking for: https://supabase.com/docs/guides/auth/auth-anonymous

[utkarsh1097]

Allowing and maintaining anonymous user sessions is different from letting users register and use a session without verifying their email addresses.

[GaryAustin1]

Understand, but there is not the feature you are looking for that I know of, and I've not looked at that anon feature closely yet so figured it was worth pointing out.

[utkarsh1097]

Thanks for your help!

Yes, it is not yet implemented. Which is why I am proposing a new feature request along with some research on how I think it can be implemented (based on my understanding)

[vtsatskin]

I too have run into this limitation. I will share my use case to help justify why this feature is important to more users. Hopefully the Supabase team can consider prioritizing this feature request.

I would like to be able to have a user have a valid session without verifying either an email or an SMS number. I would like to validate emails at a later point in time.

Our use case is to validate a user's email and/or phone number at a later point after account creation. So our flow is as follows:

1. User signs up with email without a password
2. User interacts with our system as a logged in user, information is stored in Supabase database via the API. The information is associated to the account.
3. User confirms their email
4. User is given more access to data and/or UI based on email being verified

At step 2, we would like to have the user logged in so we can grant or restrict access to data or functionality via RLS policies. We want to associate the data to the specific user and their email, so having anonymous sign ups is not feasible (from my understanding). Nor is allowing public access to read or write data feasible since we want to limit access via RLS policies.

At step 4, we want to use on Supabase Auth's built in verification status stored in the auth.users table for emails and/or phone numbers so that we can build RLS policies for our data. We want to use the existing verification flows Supabase Auth supports without having to re-implement the existing verification flows in our application logic.

Based on this use case and our requirements, the following two modes of using Supabase Auth are not appropriate:

1. auth.email.enable_confirmations = true: This enables the email verification flow but prevents users from logging in and getting a valid JWT. Therefore we can verify emails but we cannot have users use the API before verification.
2. auth.email.enable_confirmations = false: This automatically marks a user's email as verified in the database on sign up. This prevents us from knowing a user's email verification status. We cannot verify their emails at a later point since they are already verified. We cannot restrict access to data based on email verification via RLS policies since the email is already marked as verified.

[vtsatskin]

It looks like this issue is on the team's radar and that it might be addressed by this currently open PR: supabase/auth#1661