#EXAMPLE Email code verification, SMS verification, and 2FA (OTP) support

11 messages · Page 1 of 1 (latest)

solar notch
#

Wondering if anybody has any examples of instrumenting the Payload local auth strategy more deeply or replacing it entirely.

  • My use case absolutely requires that accounts are verified both by email and SMS before being considered "verified".
  • Email verification by code rather than link would also be great, but is not absolutely mandatory.
  • 2FA support with OTP and potentially other methods is also mandatory.
  • Is it worth trying to use the Payload local auth strategy in these cases or should it just be replaced?
  • Examples of any of these would be fantastic, as well as any existing code for doing 2FA of any kind, or generally having multiple steps for an account to be considered verified.

Thanks!

snow ember
#

I don't think I've seen an example here yet but I am very interested in this for sure. I would say it'd be great to build in a way to extend our local auth strategy with other auth factors, wherein we could have a way to just "pass in" verification steps or similar

#

we probably have about 80% of "extension points" needed for this, and would only need a few more

solar notch
#

I'm going to go check out the current implementation and see what I can discover.

solar notch
#

This takes care of the OTP login, which is a step in the right direction, but doesn't deal with having custom/multiple verification steps.

#

@snow ember Do any of the extension points you mentioned allow hooking the verify API on an auth collection? That would certainly be a start, allowing you to provide a method which can be called with different params for the different steps (e.g. email, SMS as above). I believe that the email verification with code rather than link could then be done by using the existing method to override verify.generateEmailHTML. Same can then be done for forgotPassword.generateEmailHTML, if the reset-password API can be hooked. SMS verification might need a custom API route if requiring the ability to resend. Similarly, some fiddling would be required to allow the user to change their phone number after create but before verify, but it's doable.

#

Realistically, the other thing that would be nice is being able to specify the field(s) to be used to identify a user, which would allow having things like username or username + email for login.

solar notch
#

Beyond that, we go into the territory of using disableLocalStrategy and setting up the verification, email, login, logout, etc. stuff as a combination of hooks, custom API routes, and either a custom passport auth strategy or a more suitable existing one such as above.

fossil oak
#

Hey, did you find a good solution in the end you could share with us? 🙂