Magic links: the TL;DR

Magic links are a handy and user-friendly way to authenticate (i.e., log in) users. They're an alternative to passwords that doesn't require the administrative overhead of single sign-on.

Speaking loosely, here's the flow:

User requests a magic link from a software application
The software generates a short-lived, hard-to-guess secret in a web link
The software emails (usually) that web link with an embedded secret to the user
The user clicks the link back into the software
The software recognizes its secret and logs in the user

Despite the name, magic links aren't really magic.

fun-is-not-a-priority

They're actually pretty simple!

Why use magic links?

Context: passwords aren't great

Conventionally, software authenticates users with passwords. The general idea is pretty simple. If you know the (presumptively secret) password, you must be the user! From a strictly technical perspective, that's pretty reasonable.

Passwords tend to cause problems, though, due to human behavior.

People typically have a hard time keeping track of passwords. There are just far too many software applications out there. It's overwhelming! There are helpful solutions like password managers (I use 1Password), but adoption is still pretty low.

Instead, people take practical shortcuts with their passwords. If you let your users log in with passwords, you should expect that some of them are doing the following:

Re-using passwords: people will use the same password across different applications. If even one application practices poor security hygiene, then the password gets exposed across all applications. It doesn't take much; a rap mixtape website called DatPiff suffered a breach in 2021 that exposed 7.5 million plain text passwords. You should expect some of those passwords got re-used for access to serious software.
Using simple passwords: people will use passwords that are easy to remember. Usually this means short or predictable passwords like "qwerty123" or "baseball." If passwords are easy to remember, they're also really easy to guess!
Writing passwords down: a lot of people will write passwords on sticky notes or keep them in plain text files. That makes them ... not that secret.
Sharing passwords: people will keep spreadsheets logging the credentials to shared accounts (e.g., the entire marketing team using "M3gacorp!" with john.doe@megacorp.net)

adminadmin

All of these are pretty egregious security blunders. They're also all undoubtedly happening.

And single sign-on (SSO) is kind of complicated

Issues with passwords are mostly resolved with single sign-on techniques (e.g., SAML / OIDC / various social login providers).

But enterprise single sign-on is kind of complicated to set up, and you can't always anticipate the social login providers that people will want to use.

Magic links are like pseudo- single sign-on

There's a sense in which magic links are like single sign-on. Instead of having the user present a secret password to you, you rely on proof of identity from an external software application.

With magic links, though, you're not communicating with an enterprise identity provider (IDP) like Okta or Microsoft Entra. You're simply receiving proof that a user has access to a given email inbox (typically), and that's considered sufficient proof of identity.

Is it ideal? Not really. However, it's often better than passwords!

Magic links: how do they work?

The underlying assumption

If you're going to use magic links, you need to be comfortable with the assumptions you're making. A magic link for a given account will grant access to anyone who has it in hand. That means that you must be sharing the link only in trusted channels.

Concretely, if you pass magic links to your users over email, you are implicitly granting access to anyone who has access to that email address.

The mechanics of magic links

The mechanics of magic links are actually pretty simple. Let's take a look at the magic links that we use at Tesseral.

https://console.tesseral.com/verify-email?code=email_verification_challenge_code_0m6r7oeiqfv1o95xbn2khr3u6

When a user clicks on this link, they'll land on https://console.tesseral.com/verify-email, passing email_verification_challenge_code_0m6r7oeiqfv1o95xbn2khr3u6 as a query parameter.

That query parameter is essentially just an opaque, highly random unique ID that our software has saved down. Our software knows which user that query parameter belongs to. So when someone lands on https://console.tesseral.com/verify-email with that valid query parameter, they get logged in.

In some ways, it's kind of simple.

Magic links: security considerations

A non-technical consideration: be careful giving them out

Magic links can be a bit hazardous. As with many things in security, the biggest risk isn't really solved with code. Instead, you just have to be careful.

Anyone who has a valid magic link can log in as a user. It is extremely important that you only ever share magic links over trusted channels (e.g., an email address).

Technical considerations: making magic links more secure

If you're going to build magic links, please try to do all of the following:

Make the secret token short-lived. Make sure links only last a few minutes.
Make the secret token one-time use. Once a link gets used, it should never be possible to re-use it.
Make the secret token hard to guess. This one doesn't make its way into many how-to guides, but it's really important. Imagine if your magic links use just a 6-digit number. Well, that's not so hard to guess. An attacker can spin up a script in a few seconds that iterates through a million possibilities. By contrast, the codes that we use, e.g., email_verification_challenge_code_0m6r7oeiqfv1o95xbn2khr3u6 are random enough that they're impossible to guess.
Throttle requests. It shouldn't be possible for someone to generate a huge number of magic links. On one level, this makes secret tokens hard to guess. (If I generate 1,000,000 valid magic links, I have 1,000,000 ways to guess correctly!) This is also a practical issue; you don't want people sending arbitrarily many emails.

There are a few other things you might consider:

Require multi-factor authentication. This is kind of a pain, but it makes it much harder for an attacker to gain access.
Require same-device or IP. You won't always want things to work this way, but you can protect your users by ensuring that magic links only work on the same device or IP address that originally requested the link. This makes it practically impossible for a random third party to use the link.
Flag unusual logins. You may want to send your user a heads-up on different devices if something weird happens (e.g., was this you?). This can give you the opportunity to revoke an attacker's session if needed.

Implementing magic links with Tesseral

You could totally implement your own magic links. It's not so complicated. However, it is a pretty big pain. It's not even just about security. You will need emails delivered rapidly without landing in the spam folder -- that's a surprisingly hard problem to solve!

If you're building magic links into a SaaS application, you may want to try Tesseral. Tesseral is open source auth infrastructure for SaaS. It comes with everything you need to handle auth, from magic links to multi-factor authentication and more. You can finish your implementation in a day or two -- and then never think about auth again.

Magic links in authentication: what are they?