Step-up Authentication

Prompts an already-authenticated user for a second factor mid-session: without forcing a full re-login. The application decides a challenge is required and invokes this workflow directly. Users with Push Notification already configured are challenged immediately; users without it are enrolled inline before being challenged.

Step-up

Node Topology

How the Flow Works

1. Session check: Has Session verifies that the current request carries a valid access token. If a session exists, the challenge path begins immediately; if not, the user is routed to a Child Workflow (a complete login flow). Once login succeeds the user re-enters at Has Session.
2. Identity resolution: Identity Lookup retrieves the full user profile from the session token, making the UID available to downstream nodes.
3. MFA method check: MFA Configured State checks whether Push Notification is enrolled for this user.
   • True (enrolled) → Send Push Notification directly.
   • False (not enrolled) → Configure MFA registers the method first, then continues.
4. Challenge: Send Push Notification dispatches an approval request to the user's device. Verify Push Notification waits for the response.
   • True → Success Final (step-up approved).
   • False → Failure Final (denied or timed out).

---

Flow Phases

PHASE 1: SESSION GATE

Has Session is the entry point. It checks whether the incoming request carries a valid access token from a prior login.

True: active session → proceed directly to Identity Lookup

False: no session → Child Workflow handles login, then loops back here

The Child Workflow should be a complete login flow (e.g. the Email Login template). When it succeeds it issues a session token and the user re-enters Has Session with True.

PHASE 2: MFA CHALLENGE

Identity Lookup resolves the user profile. MFA Configured State checks whether Push Notification is already enrolled.

Already enrolled

Send Push Notification → Verify Push Notification → Success

Not yet enrolled

Configure MFA → Send Push Notification → Verify Push Notification → Success

Both paths converge on Verify Push Notification. True approves the step-up; False (denied or timed out) routes to Failure Final.

---

Key Design Decisions

THE WORKFLOW IS ALWAYS A CHALLENGE: NO PASS-THROUGH PATH

The application decides a step-up is required before invoking this workflow. There is no branch inside the flow that skips the challenge: every user who enters this workflow will be prompted for Push Notification. If your app needs conditional step-up logic, that decision belongs in the application layer, not in the workflow.

CHILD WORKFLOW HANDLES THE FULL LOGIN PATH

When Has Session returns False the user has no active session and cannot be challenged. A Child Workflow node wraps a complete login flow. After login the user re-enters Has Session with a valid session and the challenge proceeds normally.

Has Session false → Failure Final  (user stuck, no recovery)

Has Session false → Child Workflow → loops back to Has Session

CONFIGURE MFA ENROLLS INLINE: NOT AT REGISTRATION

MFA Configured State False routes to Configure MFA before issuing the Push challenge. Users who haven't set up Push Notification yet are enrolled inline before the challenge. Registration stays simple: MFA is set up on first step-up, not upfront.

WIRE VERIFY PUSH FALSE TO A MEANINGFUL ERROR PATH

Verify Push Notification False covers both an explicit denial (user taps Deny) and a timeout (no response). Route these to separate paths if your policy requires different handling.

Denied→ Log the event and route to a "Step-up denied" info page

Timeout→ Offer a retry: loop back to Send Push with a max attempt count