Sign in Subscribe
email

Magic Link logins are good, actually

As a user you want to get as few emails as possible. As a service provider, you want to have current email addresses of users. How do you get those?

Gabor Javorszky

• 3 min read
Close up photo of a worn brass letter box on a dark blue door with a “No junk mail” sign above it.

Normally when you sign up to a thing there are broadly three different ways of doing that:

  1. username and password, has been a thing since the dawn of the internet
  2. some social login, like with Facebook, Google, Microsoft, Apple, whatever, which uses an existing account you have elsewhere
  3. using a magic link you get emailed

Of these the social login is kinda complicated, so I’m going to ignore that one.

Problems with just username and password

Usually during signup you need to provide an email address where they send a verification code to know that you have access to that email address. As an engineer who also builds products, I would do this for the following three reasons:

  1. in case you forget your password, I can send stuff to your email to reset the password
  2. if you pay for the thing you signed up for, I can send the invoices to the email address. These are transactional emails and there’s no toggle here, you don’t get to choose whether you get these or not, and GDPR allows for this
  3. occasionally I might want to send promotional emails because I want some of your money to become some of my money by selling you things

That last part gets overused a lot, so users, rightly so, have started to use disposable email services. They spin up an ethereal email address just long enough to get through verification, and from that point the address no longer exists. They still have the username and password, they can log in, they just can’t be reached via email. Not that they aren’t checking the inbox; the inbox literally does not exist, and you’d get a 550 from the SMTP server (see RFC 5321 – 3.3 Mail Transactions). Yes, I love my RFCs, why do you ask?

One of the consequences of that is when you’d be sending out your transactional or promotional emails, all of those nonexistent email addresses are going to bounce or be marked as undelivered, which might not be great when it comes to your email sender reputation — the thing that determines if emails from you land in spam or not.

The goal is therefore to make sure you only send emails to addresses you know are alive and used. You can tell that if someone interacts with emails sent to that address, and therefore the point of this post.

If your service authentication is set up to use magic links instead of usernames and passwords, you solve two issues:

  • multi factor authentication in a single step, and
  • making sure the email actually exists and is being used

I’m going to ignore the first one, but the second one: if they can’t access the email address, they can’t click the link, and they can’t log in. Therefore if they logged in, you know that they clicked the link in the email.

Okay, but what if they want to log in on one computer but receive email only on their phone?!??!?!?!

Excellent question, you do the same thing like all the TV apps do on your smart tv:

  1. visit a link and get a code
  2. on a different device where you are already logged in, go to a different link
  3. put in the code from your TV into that page
  4. done, you’re logged into your TV!

By the way, this is the OAuth Device Authorization Grant (RFC 8628). You can use the same flow for literally anything, it doesn’t need to be a TV.

Okay, but what if you aren’t logged in any other way?

No sweat, you can make your service send out a short lived login token and use that. That flow would look like this:

  1. you want to log into service on the library computer (as an example), you ask it to send you a magic link (or token) email, and it displays a code entry field
  2. you receive that email on your phone, and in it you have a token: PLS LET MEI N84
  3. you enter the code on the form on the library computer, and now you are logged in

The code is short lived, you can only use it for 5 minutes after being generated and sent to you, and once you logged in with it, you can’t use the same code to log you in again.

That code would have been generated for your account, and it would only be valid on the computer that asked the email to be sent out, which you can verify by checking with the “do I have the cookie with this value on this browser?” method.

Use these responsibly!

Photo by Miguel A Amutio on Unsplash