Complexities of Magic Links

Magic links are a useful form of user authentication for a CIAM system. If you’ve ever entered your email address or phone number and received a code or clicked a link to login, you’ve used “magic links”.

I don’t actually know when the first magic link appeared, but I know Slack uses it heavily nowadays, amongst others.

There are a couple of items to consider when implementing this CIAM authentication feature.

The first is: where can your users receive messages? Also, what will they feel comfortable sharing? As mentioned above, email or text message are common options, but depending on your customer, you could use any messaging mechanism:

• whatsapp

• slack

• wechat message

• carrier pigeon

You want to calibrate this based on the profile of your customers. For instance, if I was aiming for a broad audience in the USA, email is great. Most people are okay entering that, but might be more cautious about entering a mobile number.

On the other hand, if I’m building an admin UI for a slack application that embeds in business slack channels, sending the code via a slack DM might be a good fit.

The second item to consider is deliverability. If you can’t get the user the code, they won’t be able to login. This is especially important for channels such as email or SMS. Make sure you partner with a reliable transactional messaging partner and understand the costs of delivering the message.

The third thing to think about is whether you send a one-time link or a code. A clickable or tappable link is less effort on the user’s part than a code.

But links may have a significant UX problem. If you are sending the link via email, many corporate systems prefetch links to prevent phishing. This means a one-time link may be invalid by the time the user accesses it. Such prefetching is entirely out of your control.

A code, typically 6-8 characters, entered by the user avoids this issue. Codes are a better option in general. If you are using a code, however, remember the human brain has limits on how many numbers it can remember. Additionally, when using a code, the user is forced to log in on the same device on which they began the authentication process. That is the only place the the code entry form is.

Additionally, there are other security concerns with magic links in general. When you allow magic link login, if that email inbox, whatsapp account, or SMS is accessible to an attacker, the attacker can access all those subsidiary accounts. Multi-factor authentication (MFA) can help avoid this, but it increases authentication process friction too. Also, sometimes the same email address is used for both login and MFA. Avoid that by letting the user have a separate email address for MFA purposes or use an entirely different MFA factor such as a passkey or TOTP authenticator.

You also need to make sure that you avoid enumeration attacks, where an attacker can discover if an account exists in a system by trying to login with many different login identifiers. When someone enters an email address or phone number, don’t dispaly an error message if that login identifier doesn’t exist in your system. Instead, always display the same message. For example, “if this email address corresponds to an account in our system, you’ll get an email”. If your accounts are especially high value, you add some timing jitter so that an attacker can’t enumerate based on processing time.

However, enumeration attacks are less of a concern if an application allows for self-service registration. At that point, enumeration is a given.

One final item to consider about magic link authentication is that it serves as proof of real world user existence. After all, the user has proven they have the means to receive the code or link in some kind of external system. These systems have their own levels of assurance about their users, but setting up users in any external system is going to be additional friction and will help in some way to make sure the authenticating user is real. This attribute of magic links is similar to email veriification but you receive proof at every login, rather than only after initial registration.

I hope this gives you insight into the complexities of magic link authentication.

Dan