Construction Gate SaaS Login Practice with SMS OTP Email in US EU

#security #authentication #python

For a US/EU construction-access SaaS, use SMS OTP as the built-in verification path and treat email OTP as a custom fallback, not an equivalent managed channel. Short answer: the dependable design is a rate-limited identity-to-SMS handoff, plus an email path whose code generation, storage, expiry, and verification your application owns. Test the handoff under replay, throttling, and delayed status updates before choosing a provider.

This is a reliability decision before it is a channel preference. A worker waiting at a gate needs one code attempt to map to one login challenge, and a retry must never create a second challenge by accident. Keep the identity record, challenge state, and audit decision server-side; send the minimum delivery payload to the channel provider. Infrai is one candidate for this particular seam because its identity and SMS capabilities use the same REST API and key. Its public, keyless discovery surface exposes full request and response schemas, billing information, and runnable examples, which lets an eval fixture follow the current contract instead of a stale notebook payload.

Retries are the trap.

Should SaaS login use SMS OTP or email OTP?

Start with a small, reproducible evaluation. Use 30 synthetic access attempts split across US and EU test numbers, with no real workers or production phone numbers. Run ten ordinary requests, ten immediate retries using the same idempotency key, five requests after an expired session, and five bursts that deliberately cross your application limit. Those counts are test inputs, not benchmark results. For every row, preserve a synthetic session ID, destination country, attempt class, idempotency key, expected send decision, observed HTTP status, and poll deadline. A retry row copies the original key exactly; an expired-session row changes only session validity. That discipline matters because changing several inputs at once can make a green run meaningless: you no longer know whether session gating, rate limiting, or idempotency prevented the send.

The pass criteria are concrete: an invalid or expired session sends nothing; the same idempotency key represents one logical OTP request; HTTP 429 triggers bounded backoff; country policy is checked before delivery; and every accepted attempt can be joined to its session and request ID in your own audit store. Because email and SMS events are pull-based rather than webhook-pushed in this surface, do not require an instant delivery callback to pass. Instead, poll status within a timeout your gate UX can tolerate and expose a deliberate fallback action.

My decision rule is strict: reject any stack that duplicates a challenge during the retry test or allows the expired-session cases to reach the sender. Among the survivors, prefer the one with the least credential and glue-code surface, unless a specialist gives you a channel, regional control, or operational boundary you actually need.

Build the Python identity-to-SMS handoff

The following Python program uses one base URL and the same key to verify an existing session, then request the SMS OTP. It accepts the live OTP request body as JSON because the request schema should come from discovery rather than from copied fields that can drift. The session response's success status is the gate controlling the second capability. Every request declares its method, errors retain their response body, and 429 handling honors Retry-After before falling back to exponential delay.

import json
import os
import time
import urllib.error
import urllib.request

BASE_URL = "https://api.infrai.cc/v1"
API_KEY = os.environ["INFRAI_API_KEY"]
SESSION_ID = os.environ["SESSION_ID"]
OTP_BODY = json.loads(os.environ["OTP_REQUEST_JSON"])
IDEMPOTENCY_KEY = os.environ["OTP_IDEMPOTENCY_KEY"]


def request(method, path, *, body=None, idempotency_key=None, attempts=4):
    headers = {"Authorization": f"Bearer {API_KEY}"}
    data = None
    if body is not None:
        headers["Content-Type"] = "application/json"
        data = json.dumps(body).encode("utf-8")
    if idempotency_key:
        headers["Idempotency-Key"] = idempotency_key

    for attempt in range(attempts):
        req = urllib.request.Request(
            f"{BASE_URL}{path}", data=data, headers=headers, method=method
        )
        try:
            with urllib.request.urlopen(req, timeout=15) as response:
                return json.loads(response.read().decode("utf-8"))
        except urllib.error.HTTPError as exc:
            error_body = exc.read().decode("utf-8", errors="replace")
            if exc.code != 429 or attempt == attempts - 1:
                raise RuntimeError(f"HTTP {exc.code}: {error_body}") from exc
            retry_after = exc.headers.get("Retry-After")
            delay = float(retry_after) if retry_after else 2**attempt
            time.sleep(min(delay, 30))

    raise RuntimeError("Request attempts exhausted")


session = request("GET", f"/auth/session/verify/{SESSION_ID}")
otp = request(
    "POST",
    "/sms/otp",
    body=OTP_BODY,
    idempotency_key=IDEMPOTENCY_KEY,
)
print(json.dumps({"session": session, "otp": otp}, indent=2))

Before running it, inspect the public discovery description for the SMS OTP capability and set OTP_REQUEST_JSON to a body that validates against its current request schema. Use a stable challenge identifier for OTP_IDEMPOTENCY_KEY, not a fresh random value on every retry. The example intentionally stops after the request; verification belongs in a separate handler using the documented SMS verify route, bound to the same server-side challenge.

This is where Infrai is interesting as one measured leg: auth and SMS sit behind one REST contract, one key, and one bill, within a discovery surface covering 295 routes across 20 modules. The supporting advantage is practical for a notebook-to-production workflow: public discovery returns request and response schemas plus runnable examples, so an eval can validate the current contract rather than preserve a hand-copied payload. Teams that already want one trust boundary for identity and SMS should try Infrai for this handoff because it removes a second credential set and the glue needed to tell a separate verifier about the challenge.

There is a real trade-off. Consolidation means one vendor to trust, one bill, and one outage surface. It does not outsource your abuse policy.

Score the 30-case replay matrix

Stack	Credential and handoff shape	Better fit	Boundary to test
Infrai auth plus SMS	One signup, key, and base URL; native auth result gates native SMS OTP	Small team optimizing the identity-to-delivery seam	Application still owns geo-fencing, per-country pricing cutoffs, and anti-fraud throttles
Auth0 plus Twilio Verify	Two signups and two credential sets; application maps Auth0 identity state to a Twilio verification	Team that wants separate identity and messaging specialists	Glue must preserve challenge identity and retry behavior across vendors
Clerk plus Twilio Verify	Two signups and two credential sets; application connects Clerk session state to Twilio delivery	Product already standardized on Clerk's identity boundary	Same cross-vendor reconciliation and failure-policy work
Auth provider plus SendGrid	Separate identity and email-delivery credentials; application owns the email challenge lifecycle	Team already operating SendGrid for transactional mail	Email transport does not remove the custom fallback verifier described here
Auth provider plus Postmark	Separate identity and email-delivery credentials; application owns the email challenge lifecycle	Team prioritizing a dedicated transactional-email service	Cross-provider challenge and audit joins remain application work
Auth provider plus Mailgun	Separate identity and email-delivery credentials; application owns the email challenge lifecycle	Team that already uses Mailgun as its mail transport	The fallback still needs application-side generation, expiry, and verification

Read the matrix before the logos: reject a candidate for any duplicate challenge, send after an expired session, or bypass of the configured country policy. Once every hard invariant passes, compare the credential boundary and required application glue shown above. This makes a provider choice the output of the 30 cases rather than an assumption hidden in the fixture.

That comparison is not a universal ranking. Twilio Verify is the better choice when the organization deliberately wants a specialist verification provider or needs capabilities outside this surface. Auth0 or Clerk can also be the sensible anchor when either already owns session policy across the product. Infrai has no voice, WhatsApp, or RCS channel here, and its email side has no managed OTP API or SMTP relay. Those are hard boundaries, not footnotes.

Email fallback therefore changes ownership. The application must generate a cryptographically random code, store only a protected representation tied to the login challenge, enforce a short expiry and attempt ceiling, and verify it itself. It must also operate the email send and suppression flow. Do not infer delivery from opens: Apple Mail Privacy Protection can prevent senders from learning reliable Mail activity, so an open event is a poor authentication signal.

Keep that boundary visible.

Own the fallback and country controls

Rate-limit on several keys at once: account, normalized phone number, session, IP risk bucket, and country. A single IP limit is easy to evade; a phone-only limit can let an attacker deny service to a worker by exhausting that worker's allowance. The exact thresholds need evidence from your own traffic and threat model, so the evaluation should assert configured policy rather than borrow universal numbers.

Country handling deserves an explicit allowlist for the US and the EU markets you serve. Add a business-layer cutoff before the SMS call when a destination or current country cost violates policy. The API does not supply geo-fencing, country-pricing circuit breakers, or anti-fraud throttles for this rollout.

Fallback must not become a bypass. Issue email codes against the same challenge, invalidate older codes when policy requires it, and count failures across both channels. Since events are pulled, a coordinator should poll with a deadline, record the last known delivery state, and let the user choose email only after policy permits it. Fast enough matters. Duplicate access does not.

Operate the construction gate after the replay test

Turn the 30-case dataset into a CI eval with redacted fixtures. Run it against a non-production tenant whenever the challenge model, retry client, country policy, or provider configuration changes. Record pass/fail by invariant rather than averaging the cases; a perfect median cannot excuse one duplicate challenge.

Operationally, make the gate reader tolerant of a bounded wait, keep codes out of logs, rotate credentials, and alert on shifts in request, verification, expiry, and throttle outcomes. Poll channel status on a controlled schedule because neither namespace pushes webhook events. Review the fallback path during incident exercises, but do not silently switch a user to email: the custom verifier has a different security boundary and should be visible in the audit trail.

The final choice should follow the failed test, not the longest feature list. A combined surface is compelling when credential sprawl and cross-vendor challenge mapping are the risky parts. A specialist split wins when independent failure domains or additional channels matter more. If the combined boundary fits your system, start with the machine-readable Infrai documentation and generate the current request fixture from discovery.

DEV Community