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.
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
I'm going to go check out the current implementation and see what I can discover.
How did you get on with this
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.
@jmikrut Do any of the extension points you mentioned allow hooking the
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
. Same can then be done for
, if the
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
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.
Hey, did you find a good solution in the end you could share with us? 🙂