Passwordless authentication with a twist

[DrakeDemon]

Most of us think of magic links when we hear "passwordless", but I'm trying out a different approach. What if we require our users to SEND an email for authenticating?

I've been experimenting with this idea recently and actually got around to building a prototype. This system will work as a SaaS (similar to Auth0) aimed at developers to implement authetication in their sites/apps.

The concept is pretty simple. Use mailto HTML links to open the default email app prefilled with a generated auth code. User then taps send, waits for the email to be processed and he's in.

There are some pretty cool benefits to this method:

• user doesn't have to type in not even their email addresses (infered from the received email)

• most email clients also send firstname/lastname with the email address, so signing up to a website that requires email, firsname, and lastname simplified

Spoof protection is done via email DKIM.

Here's a gif with how this works:

Imgur

If you want to try it out for yourselves, here's the website

https://nova-authenticator.com/

What do you guys think? Is this something that could catch on? Is it a viable alternative to existing systems?

[rproffitt]

Sounds terrible. Why? It would reveal my email address. Maybe I don't want to give up my email address to your system.

The Privacy Policy at https://nova-authenticator.com/privacy-policy is pretty much a non-privacy statement. You tell us not only
"Advertising Cookies are used to serve you with advertisements that may be relevant to you and your interests."
but that the data will move to other countries.

It appears your system is yet another data mining operation.

[DrakeDemon]

How would you log in to a website if you don't want to disclose your email address?
Also the site is pretty much in progress. The privacy policy is a generic, generated one. This is not the final product and I'm not trying to make a sale. Just trying to gather feedback about the idea.

[rproffitt]

@DrakeDemon. Just in case you don't know about them, look of 5 or 10 mail email addresses.

In the case of the product/site in this discussion, as-is it's just another company/site collecting emails with a very lax privacy policy. I'm not going anywhere near that login system.

[Dani]

I disagree with rproffitt.

Pretty much all login systems, whether it's in-house or third-party social login, require an email to log in. For one reason or another, a platform may choose to outsource their login mechanism. As the OP points out, plenty of sites outsource their login platform to Auth0 and other SaaS-based authentication platforms.

I use a site in which, instead of prompting the user for an email address and password to log in each time, they only prompt for your email address. You then receive an email with a one-time-use link to log you into the site. It is, indeed, passwordless.

DaniWeb's lost password feature works much the same way. You click the Forget Password link on the signup page. You're prompted for your email address. You then receive an email with a one-time-use link that logs you into your control panel.

I'm not quite sure what you mean, DrakeDemon, when you say that it would use mailto HTML links to open the default email app. Who would you be emailing? The end user would be emailing your platform? How does the end user then gain access once the email has been received and "processed"?

Typically login systems work by sending a cookie to your web browser. How would a cookie end up on the end-user's computer after a server processes an email it receives?

The other thing to consider is that the email protocol is not guaranteed (delivery failures do happen quite regularly) or instant. Sometimes, ISPs delay emails anywhere from a few hours to a few days.

[Dani]

rproffitt,

"Advertising Cookies are used to serve you with advertisements that may be relevant to you and your interests." is a blanket statement that is required in some countries if the website is using Google Analytics or serving ads. It most likely existed already in a privacy policy template he downloaded.

[rproffitt]

Thanks Dani,

I thought about the email vagaries and glad you pointed that out.

[tinstaafl]

Most sites I access use 2-factor authentication, all without me putting in my password. Seems to me it makes this redundant.

[Dani]

How do you do two-factor authentication without a password field? Typically two-factor works because it verifies in two places, having both a password as well as email verification.

I definitely think what the OP is doing is unique in that it seems to work the other way around, being that you email them instead of them emailing you. I’m not sure yet if it will work, or if users will like it, but it’s a different take on login systems, so that’s intriguing to me.

[DrakeDemon]

Dani, you got it right. It works as a third party OAuth provider.
You mentioned that site which promtps you to enter your email address and then sends you a login link. There are commonly reffered to as "magic links". Slack uses this too. And indeed, the mechanics of "forgot password" are pretty work pretty much in the same way.

As for the mailto: links, they can be configured to prefill the fields of the compose email popup. Take a look at the gif I provided, when the mail app pops up, the "to" field is set to "[e-mail]" and the "subject" field is a 6 digit code. https://imgur.com/RhgsNzD

The system works like this. The website requests an auth code (6 digit code) from the backend and puts it into the mailto: link. Then a websocket is opened and the code is used to join a room in socket.io. After the user sends the email, the backend will process it, identify the user as (from the incoming email address), builds an authentication token and then sends it via websocket to the room with the name from the subject field of the incoming email (the 6 digit code). Thus the front end receives the authentication token. This will then be passed to the website/app which is using this integration which can use the token to perform it's own authentication (setting a cookie, or generating a JWT).
The flow is OAuth compatible and works the same way as other "log in with" third parties do. Like Facebook login does the same thing, it will return a code which can be used to read the user's email/profile.
As for the delay in receiving the email, I'm aware of it. That is why the system will also have the option to use magic links (it sends a login link to the user) as a fallback option if for some reason the reverse flow doesn't work. But I think most of the time this won't be a problem since most users are using a comercial email provider like gmail/outlook.

rproffitt, the website is under construction, all the texts on the home page, or the pricings are there just so I didn't have an empty website to showcase. This is in no way a finished product, you can't purchase anything yet, it's mostly a rough prototype that I'm using to gather feedback on the concept. If I do get some positive feedback, I'm planning on building it properly.

One last thing. I'm building a similar flow to the used with SMS messages. If you've ever used a website were you had to log in by filling in your phone number and then receiving a short code via SMS, you should know what I'm talking about.
I'm trying the same flow for those kind of apps. As in, require the user to SEND the SMS to log in. This also works via HTML <a> tags. They can use a href with a format like "sms:[phone]" which on phones will open the default SMS app. The UX is pretty much the same, the user can log in with 2 taps, no need to even write his phone no in a form.

[Dani]

I find it intriguing and a nice project to tinker with, but my hesitation will be gaining any significant traction because, even if you can convince the website owners to onboard, I think a lot of end-users will be put off by sending an email to log in. They won't understand the mechanics behind it, and will be scared of what they don't understand, and think of it as a privacy concern.

I'm also not quite sure of the actual benefit to the end-user this way. Most users have login credentials stored in digital wallets already, so the barrier isn't already there. How is this more secure than two-factor authentication? I'm not really seeing the value proposition in a website paying you to switch to your platform.

[Dani]

Oh, I guess I got it backwards, didn't I? If it's a third party OAuth provider, then I'm guessing is the idea is to educate the end-users as to the benefits. Websites can integrate it as a potential login method, and those users who already have accounts in your platform can log into the third-party websites.

I dunno, I think you're going to have a hard time educating both website owners why they should pay you and end-users why it's not scary and less secure.

[DrakeDemon]

Yes, it would be a third party option, just like login with Facebook/Google etc.

Websites can integrate it as a potential login method, and those users who already have accounts in your platform can log into the third-party websites.

Just one mention here. If users don't already have an account, sending an email will automatically create one, as well as extract first/last names from it. So signing up to a new website is dramatically improved. I'm targeting this mostly to mobile apps/websites with traffic coming from mobile devices. Just take a minute to think if you've ever found yourself browsing the internet on your phone, found a cool website (maybe an online shop, forum, etc) and decided to make a purchase there or leave a comment, but they required you to create a new account. You were lying in bed sideways, just one hand usable to use your phone. And having to fill in a form with email, password, repeat password, firstname, lastname was just too much effort and you decided not to. This method could masively improve signup conversion for these types of apss/websites (at least in theory).

I dunno, I think you're going to have a hard time educating both website owners why they should pay you and end-users why it's not scary and less secure.

Indeed this is my main concern. It's such a radically different way that I'm afraid it won't catch on. But I have high hopes :). The SMS system I mentioned in my last comment it already built, I'm using it internally for a prodution app. So far the feedback has been great from the users (~3000 of them have used it so far). Before this the website was using Facebook Account Kit (now DEAD). It worked by requiring users to fill in their phone number and would send an SMS short code to them. Then the user would have to type in the received code in the form and login. The new system practically elimites having to write your phone number and the short code. So it's a bit faster/easier to use. Of course there have been a few complaints from some users that they didn't want to SEND an SMS, but not a lot of them. Eventually I think the whole user base (~50k) will get used to it. Btw, only 3k used it so far because the rest of them are active users which have previously logged into the app and their session has not expired yet.

[DrakeDemon]

By the way, I'm having a hard time convincing developers that this is a good idea. The regular users so far love the UX. Not having to type anything in to log in is awesome (just think Sign in with Apple). This is because developers usually don't think about (or just refuse to) the user experience they are giving out to their users. Most of us are so hung up on best practices/ideologies almost religiously that we can't take a step back and think outside of the box. I've been trying to pitch this idea with some subtle articles on medium and have received massive hate for it :)).

[Dani]

I’ll be honest. I don’t think that you have given me a strong enough value proposition as to why I should incorporate it into DaniWeb, and pay you for it nonetheless.

I mean ... users on mobile can already log in with Facebook in a single click. We’re all already logged into either Google or FB already. And, from mobile, I actually think context switching between browser/email client is more of a jarring experience.

I get that there is less barrier to entry to join a new site than filling out a whole form. But I’m not so sure I see the benefit to the website owner.

Since you plan on charging for this product ultimately, you have to have a strong enlightened value proposition as to why there would be an ROI. The business owner needs to see a return on their investment. Eg if they spend $500, they’ll make $1500. How will giving you money make them more money, when they’re already using log in with Facebook for free?

[DrakeDemon]

Thank you for the honest feedback!
Not sure if DaniWeb would be a target customer. Most of the users here are programmers that know how to use password managers for autofilling, and are also pretty much against anything else, as we've established :).

As for mobile users, indeed we do have log in with facebook, but there are users who don't use that because either they don't have a facebook account or are afraid the website will post on their Facebook profile (this is a legitimate concern users have, especially since most of them don't bother to read which scopes the app is requesting). In our own webapp (the one with 50k users) only 40% log in using Facebook, the others use the SMS option.
And there is no context switch between the website and the email app (this one is triggered as a pop up that automatically closes after the user clicks send). Take a look at the gif I made with the UX https://imgur.com/RhgsNzD

The benefit for the website owner is that it could decrease bounce rates and increase conversions. So eventually it will end up as ROI. Would you not spend 5$ to be able to convert a lost lead to make a sale?
I'm thinking to market this more towards e-commerce websites, actually looking into building a Shopify addon.
I can't convince you yet because I haven't started working on my maarketing pitch, as I don't have a product to sell yet. I'm just trying to validate the concept (security, UX, etc) and if I can build a working prototype I'll start from there.

Again, thank you for your replies, you have given me a lot to think about.

[Dani]

I guess I don’t see why bounce rates would be lower than other OAuth options that also reduce the friction to create a new account.

You’re saying that the target demographic is eCommerce, but you also said your target demographic are people in bed laying sideways with only one free hand. Who is going to be typing in shipping addresses and credit card numbers?

[DrakeDemon]

It would increase bounce rates for people who prefer not to use log in with Facebook/Google.

You’re saying that the target demographic is eCommerce, but you also said your target demographic are people in bed laying sideways with only one free hand. Who is going to be typing in shipping addresses and credit card numbers?

Because once you have the item in your cart, you are ready to buy, and having to fill in shipping details and credit card info is expected.
Here are some stats about shopping cart abandonement:
https://truelist.co/blog/shopping-cart-abandonment-stats/

One of the metrics there is

35% of online transactions are dropped because of a required registration prompt.

So if you could get that down to 30% by using this system, wouldn't you?