1

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.

Mark Amery
  • 143,130
  • 81
  • 406
  • 459

1 Answers1

2

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.

Joel M.
  • 579
  • 5
  • 8
  • Thanks for the info. How do you know it's related to a CSRF vulnerability if there's no docs and you presumably don't know the details of the vulnerability? I am guessing that you contacted Auth0 support about this and they stated explicitly the security feature fixed a CSRF vulnerability, but would be interested to confirm the guess! – Mark Amery Jun 14 '23 at 07:04
  • Googling it today, it seems like there IS some documentation around the restriction from the error message you quote. https://auth0.com/docs/authenticate/passwordless/authentication-methods/email-magic-link#limitations says *"When using Magic Links with Classic Universal Login, both the initial request and its response must take place in the same browser or the transaction will fail."* It looks like that's been in the docs since at least Jan 2022, though (earliest Wayback Machine snapshot), which is confusing and suggests to me this answer is missing *some* part of the full story... – Mark Amery Jun 14 '23 at 07:09
  • Did they document this restriction way back before 2022 but forget to ever actually *implement* the behaviour they'd documented until April 2023, then finally notice and fix it silently in a way that broke login flows existing clients' users were relying on? Seems possible, but I don't know how we could possibly find out without an Auth0 staff member chiming in. – Mark Amery Jun 14 '23 at 07:11
  • @MarkAmery yes that's what their support said, was that allowing the magic link to be opened from any browser is a CSRF vulnerability. – Joel M. Jun 14 '23 at 20:14
  • Good to know about that doc! I hadn't seen it. – Joel M. Jun 14 '23 at 20:14
  • this solution saved me today! i've spent 3 hours yesterday debugging and now it works. Posting here post from the auth0 forum https://community.auth0.com/t/passwordless-magic-link-error-the-link-must-be-opened-on-the-same-device/109529 – woss Jun 20 '23 at 16:04
  • It is as @JoelM. mentioned, via a support ticket and was told that: *The new default behavior is: when using a passwordless email connection with magic links, the user can now only open the link from the same browser that started the flow with an active session. The flag allows you to opt out of this behavior and allows users to verify their magic link without having an active session.* -- I believe this is poorly handled, so I have filed a [feedback](https://community.auth0.com/t/better-documentation-comunication-for-feature-flags/114413) for better communication on this kind of opt-outs – pessolato Aug 24 '23 at 13:59