Passwordless Magic Link Error "The link must be opened on the same device and browser"

Knowledge Articles
,
1

Last Updated: Sep 24, 2024

Overview

Classic Universal Login and a Passwordless email connection have been configured in a tenant.

The endpoint /passwordless/start is called from the backend to generate a link/code sent to the email.

The user receives the email message, but when the ‘magic link’ is clicked, the login attempt fails, and the following error is displayed:

The link must be opened on the same device and browser from which you submitted your email address.
Start over from this device or browser.

1.jpeg
1.jpeg452×632 10.3 KB

This article explains why this error is thrown and what can be done to prevent it.

Applies To

  • Passwordless Magic Link

Cause

Magic Links are Vulnerable

Magic Links are inherently vulnerable from a security perspective. As a result, limitations exist within the Magic Links flow. The key restriction that both the initial request and the ‘magic link’ sent via email should be opened in the same browser is enforced by a “server state” generated during the initial /authorize request in Classic Universal Login and stored in an Auth0 session cookie. The ‘magic link’ request can only succeed when this “server state” is present and valid.

To mitigate against the security risk posed by magic links, the default behavior of tenants has been changed. Embedded Login is known to have security risks. Consequently, Passwordless Email with Magic Links will no longer work by default with all three Passwordless authentication methods that are used in Embedded Login:

All three methods above do not set an Auth0 session cookie with a valid “server state”.

Tenants affected by the change

All tenants created after April 7th to 16th, 2023 (date range of staggered deployment of these changes) will have the following tenant setting disabled by default:

universal_login.passwordless.allow_magiclink_verify_without_session

Changes in behavior to note:

  • Tenants using a custom login page via Lock SDK (Passwordless), when trying to open a ‘magic link’ in the same browser window as the application, will encounter an error saying that the request must be opened in the original browser.
  • Tenants using Passwordless email with a link in a custom login page via the Auth0.js client library, when trying to open a magic link in the same browser window as the application, will encounter an error saying that the request must be opened in the original browser.
  • Tenants that generate a ‘magic link’ using the Authentication API calling the endpoint /passwordless/start, when trying to open the magic link in a browser will encounter an error saying that the request must be opened in the original browser.

Customers who rely on any of the above three flows will have the option to enable a tenant setting, which will allow verification of the ‘magic link’ and successful login in the absence of the valid server state stored in the auth0 session cookie.

Older tenants may request a change

In terms of mitigating the security threat posed by the use of magic links, all tenants created post April 7th-16th, 2023 are secure by default.

Tenants created before the change rollout window of April 7th to 16th, 2023 can opt-in to this change to be more secure. This will fail any ‘magic link’ verification requests in the absence of the valid server state stored in the auth0 session cookie.

Solution

NOTE: Passwordless connections are available to tenants configured with either ‘Classic Universal Login’ or ‘New Universal Login’. However, only ‘Classic Universal Login’ supports the use of email ‘magic links’. For further information, refer to New Universal Login v. Classic Universal Login - Passwordless authentication.

Due to the changes just described, the use of ‘magic links’ is now highly constrained.

  1. If the tenant’s setting universal_login.passwordless.allow_magiclink_verify_without_session is currently set to ‘false’, it can be manually enabled by means of a call to the Management API tenant-settings endpoint, using PATCH /api/v2/tenants/settings.
curl -H "Authorization: Bearer YOUR-MGMT-API-TOKEN" -X PATCH -H "Content-Type: application/json" -d '{"universal_login":{"passwordless":{"allow_magiclink_verify_without_session":true}}}' [https://<your-tenant-name>/api/v2/tenants/settings](https://%3Cyour-tenant-name%3E/api/v2/tenants/settings)

where is the canonical name of your tenant (e.g., demo-dev.eu.auth0.com ). Enabling this setting will allow Passwordless ‘magic links’ to be opened from any browser.

NOTE: Enabling this setting may expose the tenant applications to the risk of *Cross-Site Request Forgery (*CSRF) attacks. For further information, refer to the MDN [CSRF](https://developer.mozilla.org/en-US/docs/Glossary/CSRF) and OWASP [Cross-Site Request Forgery](https://owasp.org/www-community/attacks/csrf) documents. It is strongly advised that the tenant setting universal_login.passwordless.allow_magiclink_verify_without_session should be set to ‘false’`.

  1. The endpoint /passwordless/start can be called from the browser in an embedded native Passwordless flow. Then, the user can click on the ‘magic link’ in the same browser as it was generated to avoid the error. For further information, refer to Embedded Passwordless Login in Native Applications.
    NOTE: If a call is made to the /passwordless/start endpoint from the backend, it is essential to include the auth0-forwarded-for header with the end-user IP address to avoid hitting the rate limit on that endpoint. For further information, refer to Setting the auth0-forwarded-for header for rate-limit purposes.

  2. Passwordless login using ‘magic link’ is used with Classic Universal Login, so the call to /passwordless/start happens from the browser. The user can then click on the ‘magic link’ in the same browser as it was generated to avoid the error. For further information, refer to Passwordless Authentication with Magic Links. This is the recommended approach wherever possible.

Related References