Help with MFA deprecation notice

[joao.roberto]

Hi,

I’ve noticed a deprecation notice in my tenant’s logs and I don’t know exactly what’s originating or how to fix it (see below). I couldn’t find any guidelines describing how to adapt my application code to the new requirements of Auth0 MFA. Does anyone have any idea how to fix it?

Thanks!

{
  ...
  "type": "depnote",
  "description": "Allow unchallenged MFA api access: This feature is being deprecated. Please see details.feature of this log for more information.",
  "connection_id": "",
  "details": {
    "feature": {
      "requesting_unchallenged_mfa_access": true,
      "id": "unchallenged_mfa_access",
      "name": "Allow unchallenged MFA api access",
      "description": "When this feature is deprecated, users will be prompted for MFA when requesting access to the mfa-api"
    }
  }
  ...
}

[marcelina.barycka]

Hi there @joao.roberto ,

Can you please check your Auth0 tenant dashboard -> Settings -> Advanced -> Migrations to see if a toggle button exists to disable the Allow unchallenged MFA API access?

Can you please share how you currently interfere with the mfa-api so I can suggest workarounds? Also, if possible (on a dev/stage/test tenant), can you please switch the mentioned button and go through the flow with a test user to see what would break (and at what stage)?

One known case affected by the change was when the user attepmts to manage their MFA factors with the token received by calling the /authorize endpoint with the:
audience: https://subdomain.auth0.com/mfa/
and scope: openid profile read:authenticators enroll remove:authenticators.

[joao.roberto]

Hi @marcelina.barycka,

Thanks for you reply! Yes, the toggle button actually appears in the tenant’s settings and it is enabled.

Once users log into my application, we allow them to add/remove authenticators – this is done through the MFA API, using the audience and scope you mentioned above.

So, to test what you suggested, I switched off the Allow unchallenged MFA API access option and watched the logs after adding and removing authenticators through my application. The deprecation noticed didn’t appear so far.

I will wait new users to log in and interact with the application to be 100% sure if that fixed the issue.

Thanks again!

[marcelina.barycka]

Hi @joao.roberto ,

Happy to hear!

Thank you for going through the MFA flow after disabling the Allow unchallenged MFA API access feature on your tenant!

In case of any issues your new users encounter with MFA registration, we’ll investigate further

[joao.roberto]

Hm… Unfortunately, this didn’t work. My application requires MFA from admin users, but not from regular users. I use a Flow for that contextual login.

Turning Allow unchallenged MFA API access off is now requiring MFA from them all. Is it possible to by pass it in my Flow implementation having that option off?

Thanks!

UPDATE: I’ve added api.multifactor.enable('none'); to my Flow so that regular users shouldn’t be asked about MFA, but this didn’t succeed.

[marcelina.barycka]

Hey @joao.roberto ,

Currently with this deprecation, calling the /authorize with the audience: https://subdomain.auth0.com/mfa/ challenges unenrolled users for MFA because of no prior check of the user’s MFA enrolments state (enrolled / not enrolled).

It is possible that the performance impact of querying the user’s enrollments affected the decision.

→ The recommendation associated was to manage MFA factors in a different way (via M2M application calling our Management API).

BUT , we decided to provide our customers with a remedy on our side (by first checking the enrolment status for a user before checking the audience) so that not enrolled users will not be prompted for MFA even though the audience: https://subdomain.auth0.com/mfa/ was provided with the /authorize call.

The deprecation date was scheduled for April 18 but will be extended to August.

Feel free to share thoughts / follow-up questions.