I am currently planning to create an application. So far I have always been using the traditional username/password approach. But I would like to get rid of passwords for user authentication. This would avoid to worry about weak, stolen and forgotten passwords.

I want to create a passwordless signup and signin with magic links, but I wonder if my approach is appropriate or too risky compared to the traditional approach:

  • SIGNUP: User needs to post email for registration. Short lived magic link is created in DB/cache and sent to the provided email. If user clicks on the link before link get's expired he/she is validated.

  • SIGNIN: Same process as signup. Short lived magic link is created and if clicked on time, user is provided an JWT token to be used as a bearer token. When JWT expires, all you need to do is request a new magic link which will sign you in.

Will this work?

  • 1
    If you change the title to "Options for passwordless signup and signin" the question will be a better match for this site. Currently the vote for closing this question is because it is currently opinion based. It can be a good question if we remove the opinion aspect to it. There are options that fit within security recommendations that are not related to passwords. Jan 11, 2022 at 15:34
  • 2
    Your proposal seems predicated on fast email delivery, and on users that have access to their email in the same place they are using their web browser. Neither of these are true in the general case, even if they might be for you personally. You'd be better with a Web-only solution, such as client certificate (which has worked very well for me in the past). Jan 11, 2022 at 15:36
  • 1
    I’m voting to close this question because it belongs to security.stackexchange.com Jan 11, 2022 at 18:19
  • Such password-less log-in as practiced by Slack isn't necessarily insecure, though it does have different trade-offs compared to traditional username+password authentication. It is probably more convenient and more secure for typical users (the type that uses the same weak password for all services). But I personally loathe this. Fine as an alternative or even as a default, but for a user who is already security-conscious it's going to be a major hassle. For example, I avoid clicking links on emails. Auto-filling a password from my password manager is easier than waiting for an email.
    – amon
    Jan 11, 2022 at 18:43
  • @ThomasJunk: certain question are on-topic on more than one site.
    – Doc Brown
    Jan 13, 2022 at 11:57

2 Answers 2


The question I'm answering is slightly different than the title. I.e. what options are available for authentication that don't involve passwords. When you look at multi-factor authentication, you have an immediate clue as to what options might be available:

  • Something you know: this would include passwords, security questions, pins, or things of that nature
  • Something you are: this would include biometric data like fingerprints
  • Something you have: this would be things like sending a text, using a security token or authentication app (i.e. the id changes every 30 seconds)
  • Somewhere you are: this would be like geo-fencing or user fiingerprinting

You can have a good secure multi-factor authentication using a combination of a PIN and a security token. I.e. the first 4-8 characters would be the user's pin (something the user knows), and the last 6 numbers would be from the security token or authentication app (something the user has).

Of course, one of the ways to sidestep all of that is to use 3rd party authentication using the OAuth 2 API. That would let you use Facebook, Google, Twitter, or some other authority to handle all the hard stuff, and you only need to exchange the 3rd party token for your JWT bearer token.

I'm a firm believer in using a bearer token for authorization, but you have to positively confirm the user is who they say they are.


This approach is indeed an interesting way to conceive authentication:

  • There are already some popular applications that use it, such as Medium
  • It is not much less secure than a password based login with a reset procedure by email (For some sites I do not use recently, I always end up resetting may password via such an email link).

You have mentioned obvious benefits. But it has also some drawbacks. You need assess them with a view to your users' psychology and the level of security required for your app:

  • Some users will find the additional emails annoying. The shorter the JWT lifetime, the more frequent the perceived annoyance. Not to speak of SPAM filters.
  • Users cannot use it on devices that have no access to their email. Same issue in some mobile context, when users are on untrusted networks (emails are more at risk than https if used from an email client that is not configured securely).
  • For applications requiring a higher level of security, setting a too long JWT lifetime might put the user at risk, since the application could be re-entered if the token is still available.
  • In the same spirit, an unprotected desktop computer would also put a user at risk, since someone accessing the desktop could easily login without the legitimate user noticing.

Moreover, you'll face some new risks:

  • You must be sure that the links cannot be predicted.
  • The validity duration of the link must be short enough to avoid brute-force.
  • You should make the links unusable once the JWT is emitted, if you need to prevent link hijacking.
  • You should foresee a SIGNOUT option, so that users can login/logout on computers shared with other users.
  • You could inform users about previous connections made with their email e.g. on welcome screen after the login is complete (depending on sensitivity of information).
  • You might have to consider data protection implications, considering that each login involves a third party email provider.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.