Silent Authentication (prompt=none) Compatibility with Flexible Factors Actions API (challengeWith / challengeWithAny / enrollWith / enrollWithAny)

Product Feedback
1

Description: The newer Flexible Factors Actions API methods (api.authentication.challengeWith(), api.authentication.challengeWithAny(), api.authentication.enrollWith(), api.authentication.enrollWithAny()) are fundamentally incompatible with Silent Authentication (prompt=none) flows. When these commands are invoked inside a post-login Action, Auth0 consistently returns a “Multifactor authentication required” / mfa_required error during silent authentication, even when the user has a valid session and previously satisfied MFA (including completing MFA via the legacy api.multifactor.enable() method with “Remember for 30 days” enabled) [17].

The documented workaround for legacy MFA — inspecting event.authentication.methods for a prior mfa entry and skipping the challenge within the same session [1][13] — does not fully resolve the problem when migrating to the new Flexible Factors API. Specifically:

  1. A “remember device” state established under the legacy api.multifactor.enable('any', { allowRememberBrowser: true }) command is not honored by challengeWithAny() after migration, causing previously trusted sessions to break.
  2. challengeWith / challengeWithAny do not currently expose an allowRememberBrowser option, which has already been raised as a separate gap [18].
  3. The Flexible Factors commands force user interaction unconditionally, which by definition conflicts with prompt=none semantics and returns an error rather than silently succeeding on an already-authenticated session.
  4. Additionally, a failed silent authentication due to MFA does not terminate the session; a subsequent interactive /authorize call will prompt for MFA without requiring first-factor credentials, which introduces an unexpected behavioral inconsistency.

Customers migrating from the legacy MFA API to the recommended Flexible Factors API [17] are therefore left without a supported path that preserves their existing silent authentication flows.

Use-case: Many applications rely on silent authentication (prompt=none) to renew short-lived access tokens in SPAs without UX disruption [1], and as a defensive mechanism to detect session state (e.g., allowing users who cannot complete an MFA challenge to gracefully switch accounts rather than becoming stuck on the MFA page with no logout path). At the same time, customers require the granular control offered by the Flexible Factors API — for example, setting email as the default MFA factor — which is not achievable through the tenant-level “Always Require” MFA policy.

The current state forces customers into a mutually exclusive choice between:

  • Using challengeWith / challengeWithAny to control factor selection (breaks silent authentication), or
  • Using “Always Require” at the tenant level (no control over default factor), or
  • Remaining on the deprecated api.multifactor.enable() API (blocks adoption of the recommended Flexible Factors model).

A supported mechanism is needed so that challengeWith / challengeWithAny / enrollWith / enrollWithAny can interoperate with silent authentication — for example, by honoring event.authentication.methods containing a prior mfa entry (mirroring the legacy “require MFA once per session” pattern [1][13]), by respecting an existing “remember device” state across the legacy-to-new API migration, and/or by exposing an allowRememberBrowser option on the new commands [18]. This would allow customers to adopt the modern Flexible Factors API, retain custom default-factor logic (e.g., email-first MFA), and preserve silent authentication as a critical token renewal and session recovery pattern.