Make email auth a default auth method

[Martinsos]

Username&Pass (U&P) as an auth method is great due to minimal requirements it has, but it is not a production-level solution. Since we use it as a default method in our tutorials/examples/starters, this means that people often have to later switch to Email&Pass (E&P), and that switch is cumbersome.

Recently, we made E&P much easier to start with -> you can now start using it during development without any setup! Once going to production, you need to set up email sender, but that is ok.

With all this in mind, and based on how we saw people using Auth in Wasp, the idea is that we do the following:

1. Make E&P a default/recommended method in our tutorials and/or starters (including OpenSaas), maybe even some examples.
2. Don't remove U&P, we are keeping it, but don't mention it as a default method anymore, and make it clear in it's docs that it's missing production-level features (and therefore requires additional custom logic / management in production). Still, it can be useful for some projects, which is why we are leaving it.

[infomiho]

We'll need to update:

• the tutorial
  • docs
  • apps
• the docs
• Open SaaS template
• other starter templates that use username & password
• the docs in general to recommend the email method
• the username docs to mention caveats of using it

[Martinsos]

We will want to update starter templates in such way that they already come with login and signup pages configured and existing.

[NomaanAhmed]

If moving forward with this, can we also allow disabling email verification in production? Effectively makes it username/password (but with email field validation)

[Martinsos]

If moving forward with this, can we also allow disabling email verification in production? Effectively makes it username/password (but with email field validation)

We will take this into discussion! It is not really a recommended way of doing things so we are reluctant to support it. I am curious, could you better explain your use case, why are ok with going without email validation, but still don't want to use username and pass instead of email?

[NomaanAhmed]

If moving forward with this, can we also allow disabling email verification in production? Effectively makes it username/password (but with email field validation)

We will take this into discussion! It is not really a recommended way of doing things so we are reluctant to support it. I am curious, could you better explain your use case, why are ok with going without email validation, but still don't want to use username and pass instead of email?

Of course! A couple of examples:

1. Using e.g. Stripe to process payments, you prefill the checkout page with an email to send an email receipt. You could argue that you can add an extra email field to the username/pw auth, but I think that's just additional effort for no reason (in general, usernames are not super popular in SaaS products, which is a great use-case for quickly spinning up full-stack apps using Wasp).

   • Worth noting that this is a use-case in the opensaas.sh Wasp starter - not that one starter should be the basis of a decision 🙂

2. You're spinning up a smoke test to test a product and want users to sign up with less friction - it is very common to allow email sign up and automatically login, but limit features until email is verified - giving access to an emailVerified bool would be great for conditional logic.

3. Low-friction-preferred use-cases like ecommerce (sign up and start shopping immediately, convert guest checkout to authenticated checkout without verification), etc.

4. In general, email verification is a conversion-killer 😅 - while there are valid reasons (like fraud) to have it, often its nice to have it be delayed/removed entirely from sign up.

Also, adding email verification later on is much easier when you're already using email auth, vs having to do a data migration if going from username --> email auth.

Let me know if I can help and thanks for taking it into consideration!

[Martinsos]

If moving forward with this, can we also allow disabling email verification in production? Effectively makes it username/password (but with email field validation)

We will take this into discussion! It is not really a recommended way of doing things so we are reluctant to support it. I am curious, could you better explain your use case, why are ok with going without email validation, but still don't want to use username and pass instead of email?

Of course! A couple of examples:

1. Using e.g. Stripe to process payments, you prefill the checkout page with an email to send an email receipt. You could argue that you can add an extra email field to the username/pw auth, but I think that's just additional effort for no reason (in general, usernames are not super popular in SaaS products, which is a great use-case for quickly spinning up full-stack apps using Wasp).

   • Worth noting that this is a use-case in the opensaas.sh Wasp starter - not that one starter should be the basis of a decision 🙂
2. You're spinning up a smoke test to test a product and want users to sign up with less friction - it is very common to allow email sign up and automatically login, but limit features until email is verified - giving access to an emailVerified bool would be great for conditional logic.
3. Low-friction-preferred use-cases like ecommerce (sign up and start shopping immediately, convert guest checkout to authenticated checkout without verification), etc.
4. In general, email verification is a conversion-killer 😅 - while there are valid reasons (like fraud) to have it, often its nice to have it be delayed/removed entirely from sign up.

Also, adding email verification later on is much easier when you're already using email auth, vs having to do a data migration if going from username --> email auth.

Let me know if I can help and thanks for taking it into consideration!

Those are some very good arguments, thanks for sharing!

I remember now that we were exploring allowing for postponed verification, but decided to go with forced verification because it makes security easier to get right -> even postponed verification opens up quite some opportunities for unwanted behaviour. But I get what you mean with smoothness and conversion -> based on this, we probably should let you postpone or drop verification if you wish so, while we can leave verification at signup as default.

I opened a separate issue for this here: https://github.com/wasp-lang/wasp/issues/2073 ! Can't promise when this will happen, but we will get to it!