Goto
Goto (flow concept)

Goto describes the process of jumping from one step to another independently of the configured step order.

The Goto concept

A Goto jump has a source step and a target step.

  • Source step
  • A source step can have several potential Goto targets. They are configured in the source step.
  • Pre- and skip conditions of source steps are evaluated: If the evaluation of a precondition fails, the flow is aborted. If the evaluation of a skip condition succeeds, the step is skipped.
  • Source steps that are left by a Goto are aborted in the sense that they will not provide a successful step result and therefore will never add tags to the flow.
  • Target step
  • The target step has a step ID, which must be unique within the flow. 
  • Pre- and skip conditions of target steps are evaluated. 
  • If the evaluation of a precondition fails, the flow is aborted. If the evaluation of a skip condition succeeds, the step is skipped and flow processing continues normally.

Goto jumps to steps other than the configured targets or to targets outside of the flow are prohibited.

Interactive Goto

For interactive steps, the Goto target's endpoint can be used to instruct the flow processor to continue with a different step. The target step may be interactive or non-interactive.

  • Example:
  • An authentication flow has been started and the user is on the Password Authentication Step.
  • The user provides the correct credentials and the flow automatically continues to the mTAN Authentication Step.
  • The user decides to use a different second factor.
  • Using the Goto-Targets endpoint the list of possible target steps is retrieved. The user selects email OTP from the list.
  • Using the Goto-Target endpoint the flow is instructed to continue flow processing with the chosen target step.
  • The user receives an email, provides the correct code, and is then authenticated.

Goto REST endpoints

For every flow type, a REST endpoint supporting two methods is exposed. They are used to retrieve possible Goto targets and follow a goto, i.e., tell the flow state machine what step to process next.

  • .../goto-targets/retrieve/ – retrieve all valid Goto targets steps for the current step.
  • .../goto-targets/<stepId>/goto/ – jump to the specified Goto target step.

Non-interactive Goto

Gotos can be triggered programmatically by any flow step. In this case, this step will act as a Goto source.

For non-interactive flow steps, the programmatically triggered Goto is the only way the step can act as a Goto source: The Goto target's endpoint cannot be used for this step, as flow execution is non-interactive (not REST calls).

A programmatically triggered Goto may use both interactive and non-interactive steps as Goto targets.

Custom steps
Custom step config classes need to extend AbstractInteractiveFlowStepConfig to be capable to perform an interactive Goto. Internal Gotos can always be performed by adding an InternalGotoTargetConfig to any custom step config and implementing the getInternalGotoTargets() method to return these targets.

Failed Goto

It is possible to configure Gotos as a failure. This has the same effect as a normal Goto but can lead to increased failure counters. In flows that support failure counters, e.g. authentication and transaction approval flows, executing a failing Goto leads to increasing the currently active failure counter on the database, possibly locking the user.

Example:
Using a failing Goto in the authentication example above prevents the user from unlimited switches between mTAN and email OTP. This prevents an unlimited number of SMS messages from being sent. 

Goto security considerations

Count failures

Configuring Gotos may lead to a user being able to execute parts of a flow an unlimited number of times. If this compromises the security, e.g. by allowing a brute-force attack, use transitions as described above to lock the user after a limited number of Gotos.

Avoid complex flows

Gotos allow for a lot of flexibility. On the other hand, if Goto transitions are used heavily, this may lead to complex flows. In particular, configurations may be difficult to understand and without careful analysis, it may be hard to anticipate security bugs introduced through minor configuration changes.

  • Therefore, we recommend:
  • For the use cases that employ Gotos, make sure these use cases are well-defined and easy to understand.
  • Perform in-depth security analysis of your flow. Analyze the flow again after changing the configuration.
  • Favor explicit flow constructs over Gotos. For example, use a selection step instead of modeling selection using Gotos. 
  • Use Fail Gotos whenever repeating a Goto has negative Security implications (see above).