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!
I'm going to go check out the current implementation and see what I can discover.
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.
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.
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.
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
How did you get on with this
Hey, did you find a good solution in the end you could share with us? 🙂
I made it, it's my first YouTube video so forgive me if it's not the best quality but I wanted to share it already and not edit it endlessly
https://www.youtube.com/watch?v=Tpqt_q7KWPQStar
Discord
online
Get dedicated engineering support directly from the Payload team.