Content Comparison

...

If you want to turn off that behavior, you can set the idp.authn.MFA.validateLoginTransitions property to false (V4.1+)

One thing it doesn't do is apply any activation condition you've attached to the subordinate login flow before running that flow. If you want to conditionally run a flow, that's the point of the MFA transition rule logic so you're meant to apply those conditions yourself if you want them. This provides more flexibility since you get to control when the condition applies, which allows, for example, different conditions to attach to the same login method depending on the situation. It's all the same in the end, it's just where the logic runs.

...

You will note this does not include a check for whether the result is specifically applicable to the request's requirements, because it assumes you are in control of that decision if you choose to run the flow.

Note that one feature the MFA flow does not have is individual timeouts. For various reasons, it was not practical to maintain an activity timeout on the individual results within the MFA flow, and so that check is not done. Using a shorter lifetime generally will compensate for that.

On the other hand, the overall MFA result that contains all of the individual results does have the normal lifetime/timeout policy the IdP supports. You can still time out any memory of any of the results, just not at a fine-grained level.

Also be aware that any given login flow can supply only a single result at a time to the overall merged result, and any result from a flow will overwrite a previous result.

...

Also be aware that any given login flow can supply only a single result at a time to the overall merged result, and any result from a flow will overwrite a previous result.

Reuse of the Entire authn/MFA Flow Result (When Is a MFA Next Flow Strategy Executed?)

...

For more advanced cases or to improve efficiency, a bean can be defined for a script or Java logic that defines the condition to evaluate to decide on reuse, and you can attach that bean by name.

Lifetime/Timeout Handling

Note that one feature the MFA flow does not have is individual sub-result timeouts. For various reasons, it was not practical to maintain an activity timeout on the individual results within the MFA flow, and so that check is not done. Using a shorter lifetime generally will compensate for that.

On the other hand, the overall MFA result that contains all of the individual results does have the normal lifetime/timeout policy the IdP supports. You can still time out any memory of any of the results, just not at a fine-grained level.

Also note that while V5.2 has introduced the notion of lifetime/timeout policy that can be overridden on a per-result basis, this feature (and honestly differing lifetimes in general) doesn’t compose all that well with the MFA flow unless you set the MFA flow’s reuseCondition property to evaluate to false. This is because at the top level if the IdP determines it can reuse the MFA result, it has no way to determine if the “part” of the MFA result that satisfies the SP’s request is itself still valid or not, it’s all a pile of information at that layer.

Ergo, if you wanted one factor to have a shorter lifetime than another, you can only achieve that by forcing the MFA flow to execute your logic every time, and then have those individual lifetimes applied to the component results when you run those flows via your logic. To the user this will generally be seamless anyway, but does require a bit more work by the IdP on every request, depending on how expensive your MFA rules are.

In a nutshell, if you want real control over lifetimes at the individual flow/factor level, you will need to turn off reuse at the MFA flow level as above.

Reference

...