Modify Accounts to enable custom login processes #11896
Replies: 1 comment 1 reply
-
Hi @vooteles, With the new package This repo uses this package to implement the login flow. It lacks the second step you mentioned because it implements just the OTP one. The package is just integrated with I feel that a lot of you said we already got or would be easy to get with Were you able to play around with it? I think it would be cool if you do and provide your feedback on how you feel about it and how far it's from your vision. Also, I know you said it seemed best to create a separate discussion thread, but yours feels like this one... But I guess we can keep it like this for now. |
Beta Was this translation helpful? Give feedback.
-
To start, a little bit of background. In a couple of apps I need to set up the following login flow:
So essentially the client side login page actually consist of 3 views:
In other word, I want to provide users the option to choose per account whether they want to enable MFA and if they do, I want them to have several options to choose from. This is very similar to how MongoDB Atlas is set up. They provide a multitude of MFA methods and on each login the user can choose. In many cases this provides the best user experience.
Would it be possible to add a hook to Accounts or the accounts-password package as such that developers have the option to set up their own custom login flow - a function that gets called during login. Accounts.validateLoginAttempt does allow running custom code during login, but that does not have the option to return anything to the client (aside from errors). For the above, if it is determined that an account has MFA enabled and no OTP is sent, then the login process needs to be stopped and a list of available OTP methods needs to be returned to the user. It is possible to use errors for this communication (like here), but that seems like not a very good practice. Maybe validateLoginAttempt itself could be modified as such that it could return data to the client that's attempting the login? This would allow for a lot of flexibility, as developers can then introduce custom code to the whole login process.
On the other hand, my approach to security is usually to stick to default solutions as closely as possible and avoid writing custom code. Especially when it comes to authentication. So perhaps for security a better solution would be to just modify the accounts-password package to enable the use of multiple OTP methods simultaneously?
Release 2.6.1 brings MFA support in accounts-password and accounts-passwordless, but it seems the above will not be possible with the update. Another option would be to use Accounts.registerLoginHandler and Accounts.callLoginMethod as described in this Meteor blog post. I did actually already implement such login in my app, but then decided to abandon that option. Relying on undocumented internal code for such a critical piece just seems wrong.
PS. I did say to Filipe a while back that I'd submit a PR to describe Accounts.registerLoginHandler and Accounts.callLoginMethod in the docs, but thinking about it, it probably would not be a good option. It would encourage people to write custom code on it and makes it more likely that in the future some change in Meteor core might lead to horrible security issues. A lot safer and cleaner option is to make the accounts- packages sufficiently flexible and not expose internal code.
PPS. It seemed best to create a separate dicussion thread for this in addition to this discussion.
Beta Was this translation helpful? Give feedback.
All reactions