Magic links are a passwordless solution that is gaining popularity. How do we apply best practises to using them in our applications.

A magic link is also known as an Email One Time Password (OTP), but that is not a very helpful name when it is a type of passwordless authentication.

How a magic link works.

The user enters their email address A random code is generated by the server and sent, as part of a link, to the email address. The user receives the email and clicks the link. The server verifies the code in the link and grants access to the account associated with the email address.

As only the owner of the email address can receive the link only they can access the account.

What are the advantages?

Simplicity

Requesting and using a magic link is very simple for an end user. Users don’t need to remember if they have previously set up an account or not because the sign in and sign up steps are exactly the same.

The end user has very few choices to make during sign up, they don’t have to choose a password. This reduces the chances of them them abandoning sign up.

Reducing choices for your users at sign-up can dramatically improve onboarding rates.

Familiarity

Magic links are becoming more common and have been deployed by some popular sites such as Slack and Medium. This increases the chances that your users have already used a magic link.

Even if a user has not previously used a magic link, they will be somewhat familiar with the process. A magic link is the same process as resetting a forgotten password, without having to choose a password at the end.

At first glance magic links seem very simple to implement, and a working implementation can be set up relatively easily. However, as is often the case when balancing user experience and security, the devil is in the detail.

These are some considerations that need to be taken into account when implementing magic links.

Email deliverability

On today’s internet an email is normally delivered in a few seconds, but occasionally it takes much longer. There is also the possibility of the email being filtered as spam.

Where your email is sent from makes a huge difference to the chance of it being delivered. Many spam filters consider the reputation of the ip that sent the email.

Starting your own email server is going leave a lot of emails in your customers spam folders. Instead you should use an email service that is able to use their ip address and the positive reputation they have built up.

We use Postmark, which is a service focused on sending transactional emails and as quickly as possible.

Email client webviews

Some email client applications do not open links in the user’s browser of choice. Opening the link in a different browser can impact the user experience. If the user was shopping and had added items to their cart, they will not see the item in the other browser.

An application should check if the link was opened into the same browser session as requested the magic link. If not it should direct the user to copy the link into the browser so they can continue with their session.

User enters the wrong email address

There are several reasons a user might enter an incorrect email address. It could simply be a typo or maybe they have more than one email address and have forgotten which one is associated with their account.

As early as possible, considering security, a user should be notified if they are signing in or signing up. If they are signing up give them the option to try a different email address to find the account they are looking for.

Handle rate limiting

Anyone can request you send a magic link to an email address, even if they do not own it. This is a nuisance and can result in your emails being reported as spam, which will hurt the reputation for sending emails.

Failed attempts to sign in should be recorded and the number of magic links that a user can request should be limited. In the case of an email being received, retries to the same address should be limited.

Use the link only once

Many tutorials for magic links suggest sending a signed JSON Web Token (JWT) with an expiry time. However these can be used many times, before they expire, to gain access to the user’s account. This increases the chance of them being compromised.

Instead, your service should record when a link has been used successfully and at that time expire the link.

Let us help you out

We at DID are all about providing the best authentication experience. Magic links are one half of the DID authentication solution, and we are focused on making them the best possible.

Our next post is all about the other half of DID’s authentication, registering trusted devices so users can sign in with one-click.