A guide to magic links: how they work and why you should use them

The average American’s email address is associated with upwards of 130 online accounts (according to this Digital Guardian survey). Assuming the average American practices good account security hygiene, each of those accounts should have a unique, hard-to-guess password. Unfortunately, that isn’t the case. Over 60% of survey respondents admitted to reusing passwords in some capacity.

Humans just can’t remember hundreds of strong passwords. There has to be another way.

Two of the most popular are password managers, like 1Password and Dashlane, and passwordless authentication. With a password manager, you have to remember only a single password to access a vault of your other passwords. With passwordless authentication you can avoid password fatigue by authenticating without—you guessed it—a password.

Magic links provide a way for users to authenticate without a password. The whole process of authentication with a magic link involves the user providing their email, then clicking said “magical link” to log in. We’ll take a deep dive into how magic links work, on a technical level; review the security implications of using them; and look into how they improve the customer’s experience.

How magic links work

Magic links are similar to the set up of a one-time password (OTP) for authentication, and they go through the same flow as a “Forgot Password” workflow. On a high level, it goes like this: A user gives an application an email address and then clicks the magic link that is sent to their email—and, voilà, they’re logged in.

One of the most well-known magic link flows is Slack’s. Slack leans into the “magic” aspect, adorning the action with a magic wand, as seen below.

From an end-user’s standpoint, a magic link sure does seem like magic. But really, it’s just using tokens and hash functions. Let’s take a look from a technical standpoint. (Note that all code below is pseudocode.)

1. A user visits an application or website.
2. The website requests the user’s email address.
3. The user enters their email address.
4. The application generates a token for the magic link and forms the magic link.

1. The application sends the magic link URL to the user’s email.
2. The user opens the email and clicks on the magic link.
3. The application receives the query at the magic link end point.

If a user is not found, we wouldn't authenticate, and nothing further would happen. This is a step to help stop hackers in their tracks. How? There are arguments that error messages are a way to give hackers clues into who has and doesn’t have an account in your system.

Pretty easy, though, right? Fewer than 10 steps, and odds are, it’s very similar to your current workflow for when user’s forget and need to reset their passwords, except without the added step of setting a password. So, at this point, you’re probably really excited to add magic links to your application. Before you get started, let’s take a second to review the security of magic links.
‍

The security implications of magic links

From a developer’s perspective, magic links are a very appealing form of user authentication. There’s no extra hardware to purchase and, really, barely any new code to write if you already have a “Forgot Password” workflow. Sadly, they aren’t quite as secure as other forms of authentication. That being said, much of the onus for security is on the user and the user’s email provider.

Since the magic link to log the user in to your application is sent to the user’s email, that means that anyone with access to the user’s device could gain access to their account in your app. If a user loses their device, or their device is stolen, a bad actor could obtain the link. Or, if the user’s email password is hacked, the hacker would have access to the magic link as well. Magic links are also vulnerable to man-in-the-middle (MITM) attacks if the users is on an unencrypted network, which would let the hacker steal the token.

That puts a lot of  the responsibility for security on the user. The best you can advocate for is for your users to do the following:

• Enable multi-factor authentication (MFA) for their email account.
• Use a secure email provider.
• Avoid using networks without encryption.

Unfortunately, these are all suggestions, and not anything enforceable.

Another security vulnerability of magic links comes with sharing them. In the same way that an application using passwords cannot make rules about their users sharing passwords, you can go only so far in enforcing that magic links not be shared.

Here are some of the best way to be sure that magic links aren’t shared beyond the account holder:

• Mitigate risk by making each magic link work only one time.
• Set an expiration time for each magic link (e.g. 15 minutes).
• Make it so that links must be opened by the same browser or device.

Don’t worry, the security around magic links isn’t all bad. Weak passwords and reused passwords are huge pitfalls in security that lead to account breaches. With passwordless authentication, there are no weak or reused passwords. There’s nothing for hackers to brute-force or phish away from a customer.

This leads us to the next point: why magic links are so good (for the customer).

Magic links can provide a great customer experience

Magic links are intuitive, familiar, and simple for end users. If you care about providing a great customer experience, magic links are the go-to for user authentication. After all, what’s easier than typing in your email address (which, hopefully, you know by heart and don’t have to look up, unlike a password) and then clicking a link?

Magic links can, however, get complex. An easy user experience is often in tension with the security concerns we mentioned above.

One of the first security concerns you’ll likely encounter isn’t from you or your user—it’s from the email provider. Sometimes, email providers mark magic link emails from new senders as spam, funneling an important email into the rarely-visited spam folder. Your user might request link after link, not realizing they’re being sent to spam. The key is to use a reputable email provider, one with an IP address that common spam filters recognize as being trustworthy (as in, one without many complaints).

Other security concerns will be on your shoulders. If your app sends a magic link, for instance, and the user requests another—should it expire the first one? Users can easily end up frustrated if they’re clicking through multiple emails and links looking for the most up-to-date one. (Of course, users could likely stand to be more patient, but in the heat of login frustration, we can’t count on that). Expiring magic links leaves the login experience with fewer vulnerabilities but the user fewer ways to log in. That’s a balance you have to strike.

Similarly, some sites restrict users from using magic links outside of the same browser session where users requested the magic link. A magic link appears a whole lot less magic when you exit your browser and find it doesn’t work when you do eventually try to log in. But of course, there’s the balance: This restriction helps ensure magic links aren’t live for too long. Magic links that persist, by default, are also default security vulnerabilities.

That balance is important because the improved user experience is worth it.

Easy user experiences tend to be good for business. If account creation is easy to do, more users will be willing to sign up (especially if creating an account provides extra benefits). Sometimes, users already have accounts but don’t bother to log in. That means the applications are losing out on valuable user-behavior data by not being able to associate that user’s visit with their account. Getting them to log in is paramount. If you can tempt them to log in by making it easy, you’ll get access to that sweet and savory data. Plus, magic links work across devices, which means users can easily log in on their tablet, laptop, desktop, and mobile device.

Know any PMs? They’re likely to tell you that one of their biggest headaches is directing customers to new features and upping engagement. It’s basically what they live for. Magic links can actually drive user engagement with new features by immediately directing them to new features after login with the magic link. Highlighting new features that everyone has worked really hard to build will help customers enjoy the experience of using your application even more than they already did.

Using magic links for your application

Magic links are a great way to provide a simple user experience for your customers without compromising their account security. Is using magic links the right move for user authentication in your application? It probably depends on what your application does. If you handle sensitive financial or health care data, magic links may not be the best move. If you work with consumer apps in entertainment and online shopping, you’re probably good to go!

Want to give magic links a try? With WorkOS, magic links are free and set you up to handle Single Sign-On via the WorkOS SSO API.  Fetching Profiles is identical between SSO and Magic Link - you can make authentication easy today, and when you're ready to move upmarket, SSO will be easy for you tomorrow. Check out our docs or these example apps to get started.