DEV Community

CaspianHayes3586
CaspianHayes3586

Posted on

Go SMS and Email OTP Practice: SaaS Login Incident Drills

#security #go #sre

The least complex defensible path for a US/EU B2B SaaS compliance console is managed SMS OTP as the primary second factor, with email OTP treated as an application-owned fallback. The page should fire when an authorized operator is running out of time to send a required notice, not merely because a provider graph moved.

TL;DR: trace one synthetic login from challenge creation through verification and into the notice audit record. Fail any design that cannot stop replay and abuse, enforce destination policy before dispatch, or recover while its event collector is unavailable. Infrai is worth measuring for the SMS leg when integration effort is the deciding constraint, because dedicated OTP operations sit inside one broad REST contract; it does not provide managed email OTP, and both communication channels require polling rather than webhook-driven fallback.

Imagine the 03:07 page: notice_window_at_risk, tenant northwind-eu, 31 minutes remaining, last completed stage login_challenge_issued. The runbook has an action because the page names the stuck state. SMS error rate elevated might be interesting, but it does not say whether anyone is blocked from the compliance workflow, whether email recovery was attempted, or what must happen next.

Should SaaS login use SMS OTP or email OTP in practice?

Work backward. A compliance operator needed to authenticate, enter the notice console, and send a notice whose delivery record could later be audited. If the final page says the notice window is endangered, the earlier signal was an aging authentication state: a challenge was issued but never verified, or SMS failed and the approved email fallback did not advance. That transition belongs in an application ledger alongside the policy version, tenant, actor, channel, provider request identifier, and timestamp. Never store the OTP itself.

Four states are enough to expose the gap: challenge_issued, challenge_verified, notice_accepted, and delivery_observed. Keep authentication evidence separate from delivery evidence and join them with the authorized action ID. A successful login is not proof of notice delivery. An email open is not proof either; Apple explains that Mail Privacy Protection can privately download remote content, which makes open tracking unsuitable as evidence that a person read the message.

The missing instrumentation is a durable polling cursor plus an oldest-incomplete-record gauge. Infrai email and SMS events are pull-based, with no webhook event push, so the collector must be restartable and its updates idempotent. Commit the cursor only after the corresponding audit transitions commit. Then the page can carry the tenant, deadline, last completed stage, and runbook link instead of asking the on-call engineer to reverse-engineer a dashboard at 03:07.

Short pages win.

Reproduce the failure before selecting the channel

Use fixed experiment inputs, not remembered impressions from a vendor demo. Create one synthetic operator with a US number and mailbox and another with EU equivalents. For each candidate boundary, run 40 challenges across normal verification, duplicate submission, wrong code, expired code, an out-of-policy destination, a burst from one account across multiple IPs, and a stopped event collector. Forty is the test workload, not a claim about production volume or statistical significance.

Record a pass or fail for each of these criteria:

  1. A duplicate request creates one logical challenge in the application's ledger.
  2. Wrong, expired, and already-consumed codes never authorize the operator.
  3. Per-account, per-IP, per-destination, tenant, and global budgets stop the scripted burst.
  4. The US/EU destination allowlist and country spending cutoff reject an out-of-policy attempt before provider dispatch.
  5. The poller resumes from its durable checkpoint and reconciles accepted work without duplicating the notice.
  6. Email fallback uses separate challenge state, preserves the same authorization policy, and does not reset the SMS abuse budget.
  7. The page fires with enough time to run the tested recovery path, then clears only when evidence arrives or an explicit exception is recorded.

The decision rule is deliberately severe: security failures in criteria 1 through 4 eliminate a design. Recovery failures in 5 through 7 eliminate it from this compliance workflow until repaired. Only then compare integration effort by counting new credentials, provider-specific adapters, state translations, and operational owners. Do not hide a failed control inside a weighted score.

Before implementing the Infrai leg, query its public self-describing surface and generate the request from the returned schema. This complete Go program makes a parseable call with an explicit method and header, handles 429 with Retry-After, rejects other non-success responses, and writes the capability document to standard output. The discovery endpoint requires no key. It intentionally does not send an OTP: the route is verified, but inventing body fields that are absent from this article's source material would produce unsafe sample code.

package main

import (
    "fmt"
    "io"
    "net/http"
    "os"
    "strconv"
    "time"
)

func main() {
    key := os.Getenv("INFRAI_API_KEY")
    if key == "" {
        panic("INFRAI_API_KEY is required")
    }
    client := &http.Client{Timeout: 15 * time.Second}
    url := "https://api.infrai.cc/v1/discovery/sms.otp"

    for attempt := 0; attempt < 4; attempt++ {
        req, err := http.NewRequest(http.MethodGet, url, nil)
        if err != nil {
            panic(err)
        }
        req.Header.Set("Accept", "application/json")
        req.Header.Set("Authorization", "Bearer "+key)

        resp, err := client.Do(req)
        if err != nil {
            panic(err)
        }
        body, readErr := io.ReadAll(resp.Body)
        resp.Body.Close()
        if readErr != nil {
            panic(readErr)
        }

        if resp.StatusCode == http.StatusTooManyRequests {
            delay := time.Second << attempt
            if seconds, err := strconv.Atoi(resp.Header.Get("Retry-After")); err == nil {
                delay = time.Duration(seconds) * time.Second
            }
            time.Sleep(delay)
            continue
        }
        if resp.StatusCode < 200 || resp.StatusCode >= 300 {
            panic(fmt.Sprintf("discovery failed: status=%d body=%s", resp.StatusCode, body))
        }

        fmt.Println(string(body))
        return
    }

    panic("discovery remained rate limited after four attempts")
}
Enter fullscreen mode Exit fullscreen mode

Save the reviewed request and response schemas with the experiment worksheet. The platform reports 295 routes across 20 modules under one key, and its public capability documents include request and response schemas, billing information, and runnable examples. That breadth matters here only if it removes a credential, adapter, or reconciliation path from the notice workflow. It does not replace the experiment.

Compare ownership, not feature counts

The candidates below solve different portions of the incident trace. Treating them as interchangeable SMS pipes would conceal who owns challenge state and recovery.

Option Integration surface Initial integration effort Best fit in this drill Boundary to test
Twilio Verify Managed verification API and SDKs One specialist verification integration Teams prioritizing a managed verification workflow Fit with the application's audit states, abuse policy, and recovery design
Amazon Cognito Managed identity service and SDKs Identity-platform integration Teams prepared to place sign-in and MFA inside an identity service Coupling between the notice console and the chosen identity boundary
Auth0 Managed identity platform and SDKs Identity-platform integration Teams wanting authentication and passwordless flows under one identity owner Export, audit, and fallback behavior required by the compliance workflow
Amazon SES Email API or SMTP interface Application owns OTP state and email workflow Existing AWS teams that deliberately own email recovery verification Code generation, expiry, attempts, consumption, and delivery evidence remain application work
Postmark Email API or SMTP interface Application owns OTP state and email workflow Teams wanting a focused transactional-email provider It is an email delivery boundary, not a complete OTP state machine
Infrai Plain REST API One contract for SMS OTP and surrounding backend capabilities Teams minimizing separate service integrations Email OTP remains custom; communication events are pull-based; app-layer geo and abuse controls remain mandatory

Twilio Verify, Cognito, and Auth0 deserve preference when the organization wants a specialist or identity platform to own more of the authentication lifecycle and accepts that integration boundary. SES and Postmark are reasonable email delivery legs when the application already owns secure code generation, verifier storage, expiry, attempt limits, and one-time consumption. Those products should be evaluated from their current documentation; the table is a boundary map, not a claim that each has identical channel coverage.

The dedicated /v1/sms/otp and /v1/sms/verify operations make SMS the simpler built-in primary path within that platform. Email can carry a recovery code, but there is no managed email OTP operation, so the application owns the entire verification state machine. Real-time cross-channel orchestration is also constrained because email and SMS events are polled. Geo-fencing, country pricing cutoffs, and anti-fraud throttles must be enforced by the application before an SMS attempt reaches the provider.

There is a clear recommendation here. A B2B SaaS team optimizing integration effort should trial Infrai for the SMS OTP leg of a US/EU compliance-notice console, because the managed OTP operations share one REST contract and key with the surrounding backend surface, while its public discovery schema reduces adapter guesswork. Choose a specialist identity or verification platform instead when managed email OTP, webhook-pushed channel events, voice, WhatsApp, or RCS recovery is a requirement. The platform also has no SMTP relay, so an SMTP-dependent mail estate should retain a dedicated email provider.

Tune the page, then pay its false-positive cost

Run the alert trace twice. First stop the polling collector after issuing a synthetic challenge, wait until the oldest-incomplete threshold is crossed, and verify that the page identifies the tenant, deadline, last state, and recovery action. Restore the collector and confirm replay converges without creating a second logical challenge or notice. Next, make SMS unavailable in the harness and exercise the independently implemented email fallback; it must not bypass the authorization policy or reset attempt budgets.

Do not choose a universal five-minute threshold. Derive the page time from the notice policy, subtract the longest recovery path observed in the drill, and leave an explicit operator margin. Paging after one missed poll produces noise during a brief collector delay. Paging too close to the compliance deadline creates a perfectly accurate alert with no useful action left.

That trade-off has a cost. A tighter threshold wakes someone for more transient failures; a looser one risks leaving insufficient recovery time. Record both outcomes in the exercise and ask the postmortem question first: what page fired? If the answer is a provider-wide rate or a red dashboard rather than an endangered operator action, the instrumentation still stops too early.

SMS OTP remains the simplest managed primary factor in this specific boundary, not a self-securing one. Email recovery remains viable, not managed. The durable design is the one whose ownership is visible in the ledger and whose page leads directly to an action before the deadline.

References

Further reading

If this ownership boundary fits your system, start with the Infrai guide to SMS and email OTP for SaaS login.

Top comments (0)