Use case
Multi-channel OTP for login authentication
Add a possession check to sign-in without rebuilding the system that already creates authentication requests. Send through Flow2FA routes, your existing providers, or both.
What the flow must protect
What the OTP shows
- The person completing sign-in currently controls the phone number, WhatsApp account or mailbox on file.
- The code was issued for this specific sign-in request and was redeemed once, within its lifetime.
- The delivery attempts and the verification result can be reconciled against the otpId your application stored for this sign-in.
What it does not show
- That the person is the account holder. Possession of a destination is evidence, not identity.
- That the sign-in is not phished. OTP is not a phishing-resistant factor and can be relayed in real time.
- That a delivery receipt equals a completed sign-in. Only a verified code and a recorded outcome show that.
Where the flow breaks
Slow or filtered codes
A code that arrives after the user has given up is the same as no code. Operator filtering, throttling and long queues push latency past the point where people retry or abandon.
One-provider dependency
When every login code leaves through a single provider or bind, a degraded route becomes a login outage for the markets that route serves.
Duplicate and stale resends
Impatient users press resend. Without throttles and clear invalidation rules, several live codes exist at once and users enter the wrong one.
No link between attempt and outcome
If send attempts live in a messaging log and sign-ins live in the application, nobody can answer why completion dropped in one country last night.
Factor and assurance decision matrix
What a sign-in factor proves is not the same as what it resists. Use this to decide which factor, or combination, fits a given login risk level.
| Factor | What it proves | Phishing resistance | Main residual risk | Suited to |
|---|---|---|---|---|
| Password only | Knowledge of a shared secret | None | Credential stuffing, reuse, phishing | Not recommended alone for anything sensitive |
| Password + SMS OTP | Knowledge plus possession of the phone number on file | None — a manually entered code can be relayed in real time | Real-time phishing/relay, SIM swap | Baseline step-up for standard consumer sign-in |
| Password + email OTP | Knowledge plus possession of the mailbox on file | None — same relay risk as SMS | Mailbox compromise, relay | Where email is the primary registered channel |
| Password + configured WhatsApp OTP | Knowledge plus possession of the WhatsApp account, where that channel is configured | None — same relay risk as SMS and email | Relay; channel availability depends on configuration | Markets where WhatsApp reaches users better than SMS |
| Passkey / FIDO2 | Possession of a bound authenticator, cryptographically tied to the origin | High — resists real-time relay by design | Device loss or recovery-flow weaknesses | Privileged or high-risk sign-in where it can be deployed |
A manually entered OTP, over any channel, is not a phishing-resistant factor. It is a possession check that can be relayed if a user is deceived into reading it out.
A production flow
User submits credentials
Your application handles the password, SSO assertion or existing first factor as it does today.
Your system decides a challenge is required
Policy or your risk engine decides whether this sign-in needs a second factor, and which destination is allowed.
The request reaches Flow2FA
Submit over the documented REST API or an SMPP v3.4 bind. REST returns an otpId, which your application stores against its own sign-in record.
An approved route and channel are selected
Routing follows the policy you configure across the channels enabled on your account — SMS, email and, where configured, WhatsApp — on Flow2FA routes, your own vendors, or both.
Configured retry and fallback run
If the first attempt is not confirmed within your window, the next approved channel is tried according to your rules.
Your application verifies the code
Verify through the API or against your own store, enforcing lifetime, single use and attempt limits.
The outcome is recorded
Your application records success, failure or expiry against its own sign-in record, keyed by the stored otpId, so delivery data and sign-in data agree.
How Flow2FA fits
Second factor without rebuilding the challenge path
Keep the code that already issues sign-in requests and add a possession check across the channels enabled on your account.
Routing you control per market and risk level
Choose which route goes first and which channel is allowed as fallback for a given market or risk tier.
Controls to define, and what to measure
Controls to define
These are your decisions. Flow2FA carries and verifies the code; the policy stays yours.
- Code length, alphabet and lifetime
- Single-use enforcement and invalidation of earlier codes
- Attempt limits per code, per account and per IP
- Resend throttles and cooldown windows
- Application-level binding: only accepting an otpId your record ties to this exact sign-in session
- Protection of phone number and email changes with a separate challenge
- Risk-based fallback rules, including when fallback is not allowed
- Retention period for destinations, attempt logs and message content
What to measure
Measure completed verification, not accepted API calls. Acceptance and delivery receipts are progress indicators, not outcomes.
- Login verification completion rate, measured on verified codes rather than accepted API calls
- First-attempt success rate before any resend or fallback
- p50 and p95 latency from request to delivery attempt
- Resend rate and average resends per completed sign-in
- Completion split by country, operator and channel
- Expiry rate: codes issued that were never redeemed
Integration options
Most teams adding login OTP to a modern web or mobile stack start with REST. Teams that already run an SMS platform with SMPP binds usually keep that path and point it at Flow2FA.
Shared integration detail
REST vs SMPP, the provider model, routing and fallback, and full channel detail are covered once, in full, on the OTP API overview. For how to weigh those choices against your own requirements, see the buyer guide.
Channel availability depends on the setup configured for each account. The current public REST reference documents SMS and email channel values, while configured Flow2FA setups may also include WhatsApp.
Put a second factor on sign-in without rewriting it
Tell us how your login flow issues challenges today and which markets are giving you trouble. We will map it to REST or SMPP and show the routing and fallback options.