What does allow_magiclink_verify_without_session do?

Question

When I export my Auth0 tenants' configurations using a0deploy, this section appears in tenant.universal_login:

passwordless:
  allow_magiclink_verify_without_session: true

What does it mean? I can't see any setting in the Branding -> Universal Login section of the dashboard at https://manage.auth0.com/dashboard that sounds related, nor in Authentication -> Passwordless, and as of today a Google search for allow_magiclink_verify_without_session returns no results; this question seems to be the first mention of the setting anywhere on the web.

Answer 1

I will try my best to answer based on my current understanding.

It seems like Auth0 rolled out a new security feature some time in April 2023 to prevent a CSRF vulnerability around opening the magic link in an email. I am not aware of there being any documentation for it, nor any announcement. The error this is causing is not currently showing up in Auth0 logs either.

This caused passwordless magic link emails to break. When clicking the link, it would show an error: "Something went wrong. The link must be opened on the same device and browser from which you submitted your email address."

The way to fix this is to do this:

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].us.auth0.com/api/v2/tenants/settings

You can retrieve a Management API token from the Auth0 Dashboard > Applications > APIs > Auth0 Management API > API Explorer.

You can also use a config.yaml to update it per the OP's note above, to set this value to be true:

  universal_login:
    [... other settings here]
    passwordless:
      allow_magiclink_verify_without_session: true

I think Auth0 really messed up here because they made a breaking change with no announcement, logging, or documentation. They seem to be stating that this change only impacted new tenants, but this was not the case, as we saw existing tenants impacted by this change.

I am not aware of any other effects of this flag other than the passwordless magic link. I think that setting this value to true is probably the safest, though, to confirm nothing else is accidentally broken, at least until Auth0 makes it clearer what is going on here.