What is the difference between Verify MFA and Re-trigger MFA?

Verify MFA completes the challenge — use it when the user provides a code or push approval. Re-trigger MFA sends a fresh code — use it when the original code expired or the user asks for a new one. After re-triggering, call Verify MFA with the new code.

How do I tell from the login result whether MFA is required?

The login operation returns either a session (no second factor required) or an MFA challenge object (second factor required). Inspect the result type in the step immediately after Login and branch your automation to handle both paths.

What happens if the MFA challenge expires before the user responds?

The challenge becomes invalid after approximately five minutes. The user must restart the login flow from the beginning to receive a new challenge; Re-trigger MFA cannot refresh an already-expired challenge.

Login & MFA- UnifyApps

The Auth node's login and MFA operations authenticate a user against an identity provider and, when a second factor is required, complete the challenge. MFA challenges are short-lived — approximately five minutes — so design your flow to move users through verification promptly.

Overview

Login authenticates a user against the configured identity provider. If that provider requires a second factor, the login result is an MFA challenge rather than a finished session — this is not an error, it is the expected next step. The challenge carries the information needed to complete or retry verification. MFA supports one-time codes (OTP) delivered via authenticator app, SMS, or email, as well as push approval. Once the challenge is received, call Verify MFA to complete it. If the original code has expired or the user requests a new one, call Re-trigger MFA.

Operations

Authenticates the user against a specified identity provider. On success when no second factor is required, returns a session. On success when the provider requires a second factor, returns an MFA challenge instead of a session. Branch the automation on this result — both outcomes are valid and expected.

Verify MFA

Completes an MFA challenge. Provide the OTP code or push approval confirmation from the user. On success, returns a session. The challenge is short-lived — approximately five minutes — so this step must be reached while the challenge is still active.

Re-trigger MFA

Sends a fresh OTP or re-initiates the push approval request. Use when the original code has expired before the user entered it, or when the user explicitly requests a new code. After re-triggering, the new challenge replaces the previous one.

MFA Behaviour

Two operational constraints shape how MFA flows must be designed:

Challenge lifetime — an MFA challenge is valid for approximately five minutes. If the user does not complete verification within that window, the challenge expires and they must restart the login flow to receive a new one.
Lockout on repeated failures — repeated failed MFA attempts temporarily lock the user. The failure threshold and lock duration are policy-configurable. Inform users that repeated incorrect entries may lock their account temporarily.

Additionally, a provider can be configured to require different MFA factors for different purposes — for example, an authenticator app for standard login but an emailed code for a password reset initiated through the same provider.

Notes

Keep the following in mind when building login and MFA flows.

An MFA challenge result is not an error — it is the expected path when the identity provider requires a second factor. Always handle both outcomes: session returned and MFA challenge returned.
The MFA challenge is short-lived (approximately five minutes). Build the UI so users reach the verification step without unnecessary delays.
Repeated failed MFA attempts temporarily lock the user; threshold and lock duration are policy-configurable.
MFA supports OTP (authenticator app, SMS, email) and push approval; available methods depend on the identity provider's configuration.
Different providers can require different MFA factors for different actions — verify the provider's configuration before assuming a specific factor will be used.

Always test login flows end-to-end with MFA enabled in a non-production environment — including the expired-challenge path and the lockout path — before deploying to users.