Our team was reviewing push enrollment docs and noticed this
When users enroll with push, they also get enrolled in OTP, as Guardian supports challenging with OTP for scenarios where the user does not have connectivity.
Is it possible in the UL process exclude the addition of the OTP factor?
Hi @daenzer.gabriel,
Thank you for posting your question!
The Push-Notification is considered to be the OTP authenticator enrolled as a fallback, so unfortunately at the moment when using Universal Login, the OTP will be automatically added as an option to users. Because Push notifications rely on a data connection that can be spotty, the OTP serves as the mandatory “fail-safe” or offline backup.
If you wish to, you have the option of submitting a Feature Request since others might be interested in such an option as well and our Product Team is actively monitoring this thread for potential implementations.
Kind regards,
Remus
I think it is actually fine that we don’t request that, it looks like I can call for enrollments via the /api/v2/users/{id}/enrollments endpoint which includes push factor without the totp. This should be functional enough for what we need, thanks!
Hi @daenzer.gabriel,
While the Management API lists Push and TOTP as separate entries, they are tethered within the Guardian framework. When a user enrolls in Push, the system automatically creates a TOTP enrollment as a mandatory “fail-safe.” These factors share a single enrollment “seed,” meaning they are effectively a single logical unit; deleting one will typically result in the deletion of the other.
In the Universal Login experience, the “Enter Code” (OTP) option will always be visible as a fallback if the Push notification fails or if the user is offline. To strictly hide the OTP factor from the user interface, a developer would need to build a Custom MFA UI using the Authentication API, which allows full control over which challenge methods are displayed to the user.
While you can use GET /api/v2/users/{id}/enrollments to see the factors, we generally recommend using GET /api/v2/users/{id}/authentication-methods instead.
The newer endpoint is the modern standard for Auth0. It provides much deeper metadata—especially for newer technologies like WebAuthn—and includes the link_id field. This field is crucial because it explicitly shows that a Push factor and its OTP fallback are tethered together, whereas the older endpoint can make them look like entirely independent enrollments.
Thank you!
Best regards,
Remus
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.