[Done] Passwordless sign-in

[StorytellerCZ]

A new method of signing-in. Requires only e-mail from user and when signing-in it would send a one time link to the user's primary e-mail through which they would sign-in.

I think this could operate alongside SSO logins, but if active should replace accounts-password. There could be an argument that this could be a community package and I'm all for it, but I think with SAAS like Clerk we should include this in the core or at least dedicate a section in the guide for it.

Additional functionality could be build on top of this which would allow for things like admins in one click to log-in into an app like the user.

Relevant forums discussion: https://forums.meteor.com/t/can-we-build-password-less-authentication-into-accounts/55885?u=storyteller

[filipenevola]

I like this idea but I'm not sure if it needs to be in the core.

I believe the first question is: does it need to be in the core?

If yes, the second question is: why?

As explained here

Try to re-work your feature request as a minimal set of hooks to core that enable the feature to be implemented as a package.

I believe in this case maybe we don't need any new hook at all but if we do, that is the way to go.

So my suggestion is to study more the possible new hooks, propose then here and when we decide the new hooks that are necessary we could go forward with a PR and also a package using these hooks to implement the desired feature.

And to wrap up we would write a section in the guide explaining how to use it 😉

[StorytellerCZ]

I think this is still an unresolved conflict that goes back to the apple-oauth or enhanced methods discussion.
Regarding the Apple Oath your argument is that since there is a package in the community it doesn't need to be in core. My argument is that given how mandatory it has become for anything that ships on Apple products it should enjoy the same privilege as Google Oauth.
Here I was inspired most recently by Clerk and I think we might want to consider extending the default functionality a bit or at least doing the investigation and if nothing else just chuck this to writing a guide article and maybe even creating an example. My main motivations is to potentially extend support to more use cases that have become popular in recent years.

[mgrivera]

Is this for cases when a user doesn't have an account?
Or maybe the user does have an account but is in a device that is not his/her and just want to connect without having to use password?

[StorytellerCZ]

@mgrivera the second use case would be something that would be implementable with this feature, but the downside with that use case is that user still has to login into e-mail or send the link to themselves somehow.

[jankapunkt]

I like this idea but I'm not sure if it needs to be in the core.

We could draft it as independent package, augmenting Accounts with a few necessary server-/client-hooks that are required to implemented Meteor.loginWith<magic> and see if it is relevant enough to become part of the accounts-* family.

My opinion on this is: the closer generic Accounts functionality is to the core of Meteor the better for zero- or minimal-config developer experience.

[minhna]

could it be a package "account-passwordless"?

[cstrat]

@mgrivera - my use case is for users who rather than using email/password, simply want to be emailed a token and that token (either by URL or by entering a code) can login. Similar to what happens when you verify your email in the current meteor workflow.

I believe it should be a separate feature built into the accounts core package. It would be possible to hack something together, but the thing about Meteor which attracts a lot of beginners is that user authentication is handled by core and can be trusted. If we're hacking something together not sure it can be relied on for long term. Accounts-Password is part of core, this would be an update to that. 95% of the workflow already exists with the process to validate a users new email. Just need to modify that and have it as something developers can toggle.

I find password less access appealing because it's one less password to worry about. I have strong security on my email, I trust that.

Bonus moves:

1. Support SMS as well as email (twilio perhaps?)
2. Support 2FA via Email (or as above by SMS)

[filipenevola]

In general I agree with your points but supporting passwordless authentication inside the accounts-password package would be weird I think.

Our idea for the email package is to provide an easy way to hook any service there, we are already working in this direction, it will probably be available on Meteor 2.4.

About SMS and other ways it would require the same steps, probably providing an easy way to hook another methods of sending the authentication login / token.

[renanccastro]

Hello, everyone.
What do you think of a package that has the following features?

You can log in passing a 6 length code, that is generated randomly and has an expiration of X hours(1 by default), to the method called:

Meteor.loginWithToken(token, (err) => {
  if (err) {
    // handle error
  } else {
    // successful login!
  }
});

You can request a token for a user, which can be an existing, or non-existing user by using:

Accounts.requestLoginTokenForUser(selector, user);

The selector is a mongo selector. A default user is an object that will be used to it if it not exists, so it's an object. Ex: { phone: 55555 }, { username: 33333}, {email: test@test.com}. If no user is found, a new one is created using the "user" object.

By default, account-passwordless will send an email if an email is set for the user, pre-configured with the following:

Hello!

Type the following token in our login webpage to be logged in:
${token}
If you want, you can click the following link to be automatically logged in:
${url}

which in turn can be customized with the following:

Accounts.emailTemplates.sendLoginToken = {
  subject(user) {
    return "Your login token on YourWebsite";
  },
  text(user, token, url) {
    return `Hello!
Type the following token in our login webpage to be logged in:
${token}
If you want, you can click the following link to be automatically logged in:
${url}
Thanks,
YourWebsite team
`
  },
  html(user, url) {
    // This is where HTML email content would go.
    // See the section about html emails below.
  }
};

You can opt-out from email sending and also configuring the package with the following:

Accounts.config({
  sendLoginTokenByEmail: false,
  loginTokenExpirationHours: 1 (default)
});

If you want to send the user to a different page than home("/"), you can use:

Accounts.urls.loginWithTokenUrl = (token) => {
  return Meteor.absoluteUrl(`${token}`);
};

Now, for the callbacks:

Callbacks

Accounts.onLoginWithTokenLink((token, done) => {
  // called in the client side when a token is detected in the URL
  // no need to call Meteor.loginWithToken(token) at the end
})

Accounts.onCreateLoginToken((token, user) => {
  const { phone } = user.phone;
 
 customSendSMSLogic(phone, token);
});

Am I missing any use-case for this package? Would an API like this be good enough?

[renanccastro]

We could work with the user parameter being null. If it's null, don't create it, that's was actually my plan :) How do you think one could exploit it @jankapunkt? I'm thinking more in the use case of an e-commerce, or something that needs to login/signup a user with just a phone or person ID. I think typos are tolerable in this case, as it's something the user can opt-out if he wants to

[jankapunkt]

@renanccastro such an exploit is solely hypothetical from the point, that creating a user can be induced by a "failure" (in such case user not found, maybe due to misspelled username etc.).

I would always assume, that creating a user is an intentional step within a registration procedure and should not be a side-effect of some other step.

I would therefore propose a third optional options parameter, which contains a flag, like createUserIfNotFound. With a certain default value.

[StorytellerCZ]

Also spamming in random email into the form could create a DDOS attack (even with request limits) as the creating a new user and sending an email isn't exactly a cheap operation.
Also while at it with such an easy new user creation, we might want to also implement an option to remove the user by clicking a link in the validation email. It has been noted in the code as a todo, but never implemented.

[filipenevola]

We always need to choose but we need to remember that easy sign-up is important for the apps.

And yes, we could have a way for the user to say "I didn't sign-up" in the email.

Another important option in fact is to have a boolean for people to choose if they want to createUserIfNotFound or not as it would provide a more flexible control in the UI.

Some apps maybe don't want to have the same form to sign-up and sign-in for example 😉

[StorytellerCZ]

Sounds good, one thing we also need to account for is the enrollment flow and creating of user from the administrators of the app.

[renanccastro]

I've started implementing this here: #11602

[filipenevola]

Meteor 2.5 also includes a package called accounts-passwordless so this discussion is closed now.

More details in the blog post coming soon about 2.5.