Problems with the current state of authentication

Authentication is required as a means to identify if the user is who they say they are.

In the days of desktop computing, the user is typically the only one who could access the device. You only needed to protect the applications and data from malicious users who were able to physically access the device. This meant that a singular mechanism of username and password was the most logical way to authenticate users. Also, this singular authentication mechanism was put right at the start, before the user could start using the application.

This paradigm however unfortunately spilt into the internet era, since this was the architecture and user experience that people were used to from the previous era. There were 2 problems that came with this.

1. Security: Unlike the desktop computing era, users who did not have physical access to a device can attempt to authenticate remotely through the internet. This meant that physical location based security became no longer inherent and that an application could be easily compromised just by guessing or brute-forcing passwords.

2. User Experience: Also, unlike the desktop computing era, remote access to servers through the internet meant the sheer amount of applications that an average user has to authenticate skyrocketed. Remembering 1 password is fine, but remembering dozens or hundreds turned out to be too much of an ask for the average user. Not to mention every site has their own password policy requirements.

Developers have lost control over how they design their web or mobile app

The social and mobile era attempted to fix some of these issues with the rise of OAuth2.0. With almost the entire connected population of the internet being Facebook and Google’s user base, this meant that they could offer social logins as a means to more easily authenticate to web and mobile apps. Password managers tried to solve to the problem of remembering passwords and coming up with secure passwords.

However, what this has done is that developers have lost control over how they design their web or mobile app.

Password manager reliance

Only 20% of people use password managers. This means that the experience a developer is able to provide to their users are dependent on the end user downloading or not downloading a password manager.

For the majority that don’t use a password manager, 60% tend to re-use passwords across websites or have a poor experience in remembering passwords.

Too many single sign on providers

There are way too many single sign on providers in 2022 that make login pages look cluttered. Providing too much choice is confusing for the user.

Putting signup and login upfront

And lastly, the concept that of putting authentication right at the start of the user journey has become the norm. This may have been a feasible solution in the desktop computing era but it does not make sense at all in the current era.

This is because we have the tools now to authenticate users to the degree necessary to access specific types of content.

Rethinking Authentication

This is why new ways have started to emerge in how to think about authentication and new principles have started to form.

1. Minimalist approach: Login and signup pages do not need to be cluttered with brand names that are not the developers’ brand. Choice needs to be minimised for the end user for better User Experience (UX).

2. Passwordless: A no-password approach to authentication means less risk of a phishing or brute force attack and less chances your user is going to forget their password and enter cumbersome reset-password flows.

3. Auth at different parts of the user journey: Authentication is not just about signup and login. Adding authentication at different parts of a user journey all the way from acquisition to payment increases flexibility, usability and security when implemented well.

Enter Magic Links.

What are Magic Links and how they can be used?

Definition of a Magic Link:

A Magic Link is a single-use URL that authenticates a user when clicked.

It is a UX pattern that has grown in popularity over the last couple of years especially after users started getting more familiar with it through logging into Slack or Medium.

Typically the user flow goes like this:

1. User types in email
2. User receives email with an embedded magic link
3. User clicks on the magic link and that’s it — the user is authenticated

The beauty of this UX flow is that your user never had to set a password when signing up or remember a password when logging in. Your user also doesn’t need to be a savvy user who uses a password manager like 1Password.

The above UX flow is that of a passwordless login.

However, magic links can be used in more ways. For example:

• MFA: You can use it as a second (or third) factor of authentication after authenticating a user with a username and password

• Instant signup: You can let the user in just with an email without verification so they are not taken away from their user onboarding journey. -> No password is required. -> Verify the user’s email only before they make a payment or input sensitive data.=

• One Click Email Authentication: Send your users a marketing email or an email newsletter with a pre-authenticated magic link that the user can click on to -> instantly signup to your service and bypass the “create an account” screen OR -> one click login to your service and bypass the traditional login screen

Without One Click Email Authentication

With One Click Email Authentication

Why use Magic Links?

The point of using Magic Links is to ultimately increase the bottom line.

Use Magic Links at different parts of the user journey → Convert more users to become customers → more customers become paying customers → more revenue

Benefits:

1. Reduce drop-off rates at the signup and login screens. It has been shown 45% of users drop-off at the sight of a ‘create an account’ screen. So replacing a traditional username password screen with magic links can significantly boost user conversion and retention.

2. Unleash developer creativity. You can be quite creative in how and where in the user journey Magic Links could be used. For example, you may choose to let your users into the app to explore and fire off a Magic Link just before the user attempts to pay. The sky is the limit in how Magic Links can leveraged for your app.

3. Increase security. Eliminate the risk of password phishing attempts by removing passwords from the journey altogether.

There are however some considerations to be taken into account.

Considerations:

1. Only as secure as the user’s email. If the user’s email provider has poor authentication policies and if the user accidentally divulged their email account details, this would leave all apps using Magic Links vulnerable.

2. Email can take time to be delivered. Email deliverability could be slow and could also end up in spam if not implemented right.

How do Magic Links technically work?

Conceptually, Magic Links work quite simply in 3 steps.

1. Generate a pre-authenticated Magic Link strongly tied to a user

2. Allow the user to access Magic Link through a communication channel such as Email

3. Verify the Magic Link and authenticate the user

Since Magic Links themselves do not have a standard to go by, there are many implementations of this. This also means they become prone to errors when attempting to implement on the fly.

Here, for the sake of an example, we will explain how using Magic Links with EZiD APIs work. EZiD APIs are loosely based on OAuth2.0 standards to help developers who are already used to those standards.

The traditional passwordless login flow looks like this.

Step 1: Send Magic Link email to user

Here, we use the /send API to send an embedded magic link to a user through the email channel through a single API.

The Magic Link URL has a format of https:///auth?code=. The auth code can be embedded in a JSON Web Token (JWT) so that the recipient can verify that the code hasn’t been tampered with.

Note: The Auth API can send the Magic Link email directly to the user or your server can choose to send this depending on which email service you want to use.

Step 2: Verify Magic Link when clicked on and authenticate user

Here the Magic Link has an ‘auth code’, that your server can exchange for an Access Token.

There are a few reasons as to why the access token is not directly provided in the Magic Link:

• The Magic Link needs to be single-use for security reasons and the Access Token is not.

• You also do not want the Access Token in the URL which can be prone to sniffing.

• Lastly, the client secret that you will need to access the Auth API should be protected server-side and so by passing the ‘auth code’ to the server, your server can then use the Client Secret to exchange that for the Access Token.

Step 3: Use Access Token from authenticated user to access app resources

Now that you have an Access Token for the user, they can now use this to access resources as specified in the claims (assertions about the user that allow them to access or not access particular resources) that the Access Token has.

But how about getting more flexibility to embed Magic Links at different parts of your customers’ journey.

This is where it helps to think about Magic Links in the form of:

i) Generate

ii) Send

iii) Verify

By de-coupling Generation of Magic Links and the Sending of Magic Links, it provides greater flexibility to deploy and embed it in creative ways that give a better User Experience.

For example, if you wanted to embed this in an outbound marketing email CTA for faster onboarding for your users, you can do so by:

Step 1: Generate Magic Link

Generate a Magic Link for each user in marketing email campaign through a script.

Step 2: Send Magic Link to users

The communication channel to send the embedded Magic Links would depend on your marketing tool used. This could be Hubspot, Mailchimp or Sendgrid for example, where you embed the returned Magic Link as a dynamic field.

Step 3: Verify Magic Link

Verify the Magic Link and get an Access Token when a user clicks on the CTA that has the Magic Link embedded.

While the flexibility of Magic Links are great to provide a better UX, it begs the question of security.

Are Magic Links secure?

Magic Links it fact are more secure than traditional username / password pages but with the right implementation.

No passwords ⇒ better security

Magic Links avoid password security headaches. No passwords to store means no bee-hive of sensitive data to attack. It also means reduced risk of phishing websites that attempt to get your user’s passwords as the most they can do is send you a Magic Link. 80% of people do not use a password manager and so are not protected from such attacks.

Best Practice Implementation performed

i) Identify your use case and the level of security your app requires and where in the auth journey the user is actually required to be authenticated.

For example, if you are protecting financial trading in your app, you would need to supplement Magic Links with another factor of authentication. You can for example allow the user to enter your app with traditional username and password if you like, and then send them a Magic Link (or device biometrics auth) just before they attempt a trade.

ii) Magic Links need to be single-use only.

iii) Magic Link duration needs to be short (typically expires < 15 minutes). In this example, it means that after 15 minutes, the Magic Link would not authenticate the user. The expiration time depends on the sensitivity of data your app protects and whether the use case is for signup or login. The graph below illustrates how the duration of the Magic Links should be designed.

Definitions:

Sensitivity of data: This is the degree to which the data needs to be protected. Higher sensitive data include Personally Identifiable Information (PII) and payment details.

Duration of Magic Link Validity: This is how long the Magic Link that is residing in a user’s email is valid for, after which the Link would no longer authenticate.

Signup: The first time the user enters a website and becomes authenticated

Login: A subsequent time the user enters a website by verifying their authentication credentials.

The graph outlines that the higher the sensitivity of data, the shorter the Magic Link duration should be. Also, the Magic Link duration should be shorter for Login as compared to Signup, because there is existing data updated by the user to be protected in the case of Logins.

For a scenario such as embedding a Magic Link in an outbound marketing campaign, it only makes sense to do so for the case of Signups in a low sensitive data environment.

iv) The generation of Magic Links need to be secured. For example, if using a third party service like EZiD, the client secret must be protected server-side and appropriate systems and process put in place to control access to the secret.

v) The UX (both in the app and in the email) needs to ensure that the end user is fully aware that a Magic Link is pre-authenticated so to prevent them forwarding emails that have embedded Magic Links.

For more details, you can check out our dedicated post on this at ezid.io/resource/are-magic-links-secure.

Do Magic Links make sense for my business?

Magic Links may the perfect solution for certain types of businesses but it may not be the right solution for other types. The assessment comes really from 2 angles.

UX:

How important is UX? Is yours the type of app people onboard anyway regardless of how cumbersome the onboarding experience is? Eg if it’s a critical piece of software for work, your users are going to signup and login regardless. If you are an ecommerce business however, the UX to signup or login through to purchase will be critical in reducing drop-off rates.

Is your app primarily a mobile app or a mobile browser experience or a laptop web app? For a mobile app, you may want to consider using SMS instead of emails as the mode of communication as that could be easier for your user to access (depending on the location).

Security:

You are already eliminating passwords, but do you need more factors of authentication other than email Magic Links? If you are a fintech provider or handle critical health data, you may wish to consider more factors of auth to supplement Magic Links. If you are an app that does not wish to collect emails at all due to privacy, email Magic Links might not be for you.

This solution is perfect for a B2C marketplace, SaaS or subscription e-commerce, as UX for onboarding starts to matter a lot and a good level of security matters.

Users sharing invites (with embedded magic links) with their friends or the other side of the marketplace is crucial in creating virality and accelerating customer acquisition.

How can I get started?

There are few options to get started.

1. Build it yourself. This can be fine for some developers who are experienced and confident in the implementation and want to pour more time into authentication.

2. Leverage a third party library. Identity and Access Management services such as Auth0 provide libraries for the implementation of Magic Links for the signup and login page. This way, you can avoid building everything yourself and accelerate development.

3. Use flexible third party APIs built on top of open standards. API Services such as EZiD allow you to maintain control and flexibility of the User Experince that you can provide to your customers while outsourcing the hard bits that involve authentication and verification via an API. You can weave in Magic Links at different parts of your users’ journey by calling the APIs only when you want to. Being built on top of OAuth2.0 means you can leverage concepts such as the Access Token to perform fine grained access control as well.

You can check out our EZiD Magic Link APIs here or speak to us here.