app_metadata / user_metadata not delivered to custom ACUL MFA screens despite context_configuration

Get Help
1

Background
We use ACUL for our custom Universal Login screens. On the mfa-webauthn-platform-enrollment screen we need a per-user flag to drive UI logic, so we added it to the screen’s context_configuration

Problem
The values never reach the screen. We verified all three preconditions via the Management API:

  • Screen rendering context_configuration includes user.app_metadata.<key> (and separately user.user_metadata.<key>) — confirmed with a GET on the screen’s /rendering.
  • The value is actually set on the user — confirmed with GET /api/v2/users/{id} (both app_metadata and user_metadata contain the key).
  • The SDK maps correctly (user.appMetadata = data?.app_metadata ?? null).

Yet window.universal_login_context.user on the screen contains only id, email, picture — no app_metadata or user_metadata at all, on a fresh login well past any config-propagation window.

Question
Is per-user metadata intentionally withheld on MFA screens (e.g. because the user isn’t fully authenticated mid-MFA)? If so, is that documented, and is there a supported way to pass a per-transaction/per-user value into a custom MFA screen? We’ve confirmed there’s no Action→ACUL data channel, and enrolled_factors isn’t an available context field either.

Environment: ACUL @auth0/auth0-acul-js v1.5.0, New Universal Login, advanced rendering mode.

3

Hi @besabeteng,

Welcome to the Auth0 Community!

To directly address your questions, user-specific metadata(app_metadata and user_metadata) is intentionally withheld during MFA and password-reset screens. Because the user is in a “pre-authenticated” or “mid-authenticated” state, Auth0’s security model strictly restricts access to sensitive user metadata properties in the Advanced Customizations for Universal Login (ACUL) runtime context to prevent exposing data before identity is fully verified.

So in order to pass user specific information into ACUL’s MFA screens, I can think of an alternative of working around this by using the ext- Query Parameter Strategy.

If the UI logic you are trying to drive is determined at the beginning of the transaction (for example, when your application initiates the login request), you can pass a custom query parameter through the /authorize endpoint by following these steps:

  1. Pass the Parameter: Append your custom parameter with an ext- prefix to your authorization URL:

    https://YOUR_DOMAIN/authorize?ext-ui-flow-flag=special-variant&...

  2. Add to Context Configuration: In your Management API payload or Terraform configuration for the mfa-webauthn-platform-enrollment screen, map this parameter inside the context_configuration

    {
  "context_configuration": [
    "untrusted_data.authorization_params.ext-ui-flow-flag"
  ]
}

  3. Consume in ACUL: On your custom screen, read the parameter from the untrusted data object

    const flowFlag = window.universal_login_context.untrustedData?.authorizationParams?.['ext-ui-flow-flag'];

Otherwise, if the UI logic is tied to the client application rather than the individual user you can still take advantage of the client.metadata.YOUR_KEY for setting metadata or organization.metadata.YOUR_KEY** in the organization metadata context as presented in our ACUL Rendering Configuration Reference - Dynamic URL segments to support multi-branding in different ACUL screens, including MFA ones.

Thank you and if you have any other questions please let me know!
Kind regards,
Remus