If approved that this is a interesting feature, I can do it

Are you thinking that the magic link is emailed to the user or would the user need to immediately save or bookmark that magic link to be able to login again?

I've implemented this before with email. Seems like a great solution for a Hackathon oriented site as it provides a low friction authentication if you have email attached.

Instead of a magic link we could also add the user as a guest one which will be maintained till the session is closed.

Instead of a magic link we could also add the user as a guest one which will be maintained till the session is closed.

How is the use case for a guest different than the use case for an unauthenticated user?

Are you thinking that the magic link is emailed to the user or would the user need to immediately save or bookmark that magic link to be able to login again?

A magic link that is savable would be similar to a password saved in the email or other unencrypted or untrusted datastores. That wouldn't be in line with OWASP's guidelines.

I am still thinking about this, but I suspect a secure solution would be more along the line of we emailed you a one-time code (or a link with the code embedded in it) that you need to enter in the next 3 min before it expires along with this one time pin number that we are showing you on the screen. It would probably be more or less an implementation of 2FA.

I am still thinking about this, but I suspect a secure solution would be more along the line of we emailed you a one-time code (or a link with the code embedded in it) that you need to enter in the next 3 min before it expires along with this one time pin number that we are showing you on the screen. It would probably be more or less an implementation of 2FA.

So this passwordless login would be a one-time login right? They would then need to setup (or already have setup) a username or other unique identifier for themselves for their account I'm guessing? And then each time they wanted to login they'd have to request a new passwordless link to get in?

They way that I've implemented it is that once they get the passwordless login link they are told that this gives the holder of this full access to their account and to treat it like a password. The reason that this is "good enough" is that if you have access to a user's email then you have full access to all password resets on all systems that I know of. The only way to protect is MFA. In this case providing MFA doesn't help because it's still available to anybody who has taken over their email.

For this project I wouldn't make it that complicated. As long as the user is told up front what they are getting then that should be sufficient. Basic password authentication is full of holes and it is as secure (or not secure) as this passwordless login I described.

The only way to increase security is MFA - but that has nothing to do with local/OAuth/Passwordless in their own right - that's on top of all those strategies.

Hackathon-starter uses emails as usernames. Unless if there is a proposal that is not compromising security while staying simple, I would be rejecting this request.

Simple proposal: We generate a 6 digit password, saved in a db, that lasts for minutes when it is requested. Use bitly or preferred url shortener to link to a url that does a login with the args in the url.

I'd love this feature! Glitch, Medium, FCC etc. is already doing passwordless and it seems like the most secure way to do auth (https://www.freecodecamp.org/news/360-million-reasons-to-destroy-all-passwords-9a100b2b5001/).

Just posting an update on this:

1. Yes, I think we need it and would like to add it.
2. It is blocked on some code clean-up. More specifically, I suspect the code is going to look similar to how email verification may need to work. I added some code for email verification a while ago, but that code most likely needs to be cleaned up/refactored using the new javascript features since it has a bunch of nestings and may be hard to read: https://github.com/sahat/hackathon-starter/blob/master/controllers/user.js#L305 .

If we can get item 2 done, then ideally we can either reuse the same code or call a common helper functions, etc. and implement the feature while keeping things easier to maintain. If someone would like to help me with it, I would be happy to even get on a conference call to minimize any potential PR rework.

The workflow pattern that I have seen more recently and we would probably want to implement as the initial version:

1. The user is presented with a choice to login by email
2. The user enters their email and presses the login button
3. The user sees a response message that an email was sent to them with a link to log in (magic link: has a token embedded in it)
4. The user checks their email, opens the email, and clicks on the magic link. The link opens the application again but in a logged-in state. The email address is also marked as a verified email address.

Note 1: The login process needs to set the session and cookie so the application continues in a logged-in state if the user opens another browser tab and navigates to the application. This is the current behavior for all of the other login methods and there is existing code that makes that happen.
Note 2: The logout function would need to perform the same function as the other methods.
Note 3: The magic link needs to expire (5 minutes?)

@sahat I think this issue was closed before my PR was merged