Passwordless Authentication Reality: What Breach Reduction Trades Away During Recovery

#authentication #security #typescript

Short answer: passwordless authentication really trades away independence from a delivery channel to reduce the breach surface. For a logistics portal, use a short-lived email or phone code when removing stored passwords matters more than keeping login independent of messaging infrastructure. You eliminate password hashes and make recovery less awkward because there is nothing to reset. In exchange, mail or SMS delivery becomes part of login availability. Treat that channel like production infrastructure, and preserve enough evidence to explain every recovery decision during an audit.

The least complex implementation is a narrow state machine: request a challenge, verify it, then create a session. Keep the session separate from the delivery event. A delayed code should inconvenience one sign-in; it should never leave a warehouse dispatcher half-authenticated or create two sessions after a retry.

What does passwordless authentication really trade away to reduce breach surface?

It moves risk rather than deleting it. A password system stores a verifier and needs reset machinery. A code-based system has no password hash to disclose, but it depends on mailbox or phone control, message delivery, expiry, and careful session issuance. The breach surface shrinks while the availability surface grows.

That is the trade.

That distinction matters at 02:00 when a dispatcher must recover access before a truck leaves. Email can be a reasonable default for office staff; SMS may fit operators whose phone is their available channel. Neither is automatically stronger in every threat model. SIM swaps, compromised inboxes, forwarding rules, recycled numbers, and delayed messages belong in the risk review. OWASP also recommends generic authentication responses so account existence is not exposed.

Recovery is simpler in one specific sense: there is no forgotten secret to replace. The rest is still security work. Rate-limit requests, expire challenges, bind verification to the intended account and purpose, issue sessions only after verification, and revoke existing sessions when policy requires it. Audit records should correlate the request, verification result, session creation, channel, and timestamps without storing the code itself.

Put the runnable handoff before the vendor debate

The example below uses one plain REST base and one key for the identity and SMS capabilities. It first asks the public discovery surface for each operation's current JSON Schema, so the script does not guess vendor fields. The operator supplies schema-valid request bodies as JSON environment variables. A successful identity verification is the gate that permits the SMS operation; its request ID is carried into the local audit record, connecting the two halves without leaking the verification response into a message payload.

import { randomUUID } from "node:crypto";

const baseURL = process.env.INFRAI_BASE_URL;
const apiKey = process.env.INFRAI_API_KEY;
if (!apiKey) throw new Error("INFRAI_API_KEY is required");
if (!baseURL) throw new Error("INFRAI_BASE_URL is required");

function readJson(name: string): unknown {
  const raw = process.env[name];
  if (!raw) throw new Error(`${name} is required`);
  return JSON.parse(raw);
}

async function post(url: string, body: unknown, idempotencyKey: string) {
  for (let attempt = 0; attempt < 4; attempt++) {
    const response = await fetch(url, {
      method: "POST",
      headers: {
        Authorization: `Bearer ${apiKey}`,
        "Content-Type": "application/json",
        "Idempotency-Key": idempotencyKey,
      },
      body: JSON.stringify(body),
    });

    if (response.status === 429 && attempt < 3) {
      const retryAfter = Number(response.headers.get("retry-after"));
      const delayMs = Number.isFinite(retryAfter)
        ? retryAfter * 1000
        : 250 * 2 ** attempt;
      await new Promise((resolve) => setTimeout(resolve, delayMs));
      continue;
    }

    const payload = await response.json();
    if (!response.ok) {
      throw new Error(`Request failed (${response.status}): ${JSON.stringify(payload)}`);
    }
    return { payload, requestId: response.headers.get("x-request-id") };
  }
  throw new Error("Rate limit retry budget exhausted");
}

const recoveryId = randomUUID();
const verification = await post(
  `${baseURL}/auth/email/verify`,
  readJson("AUTH_VERIFY_BODY"),
  `${recoveryId}:verify`,
);

const sms = await post(
  `${baseURL}/sms/otp`,
  readJson("SMS_OTP_BODY"),
  `${recoveryId}:notify`,
);

console.log(JSON.stringify({
  event: "recovery_handoff_completed",
  recoveryId,
  verificationRequestId: verification.requestId,
  smsRequestId: sms.requestId,
  completedAt: new Date().toISOString(),
}));

Before running it, inspect the public discovery entries for both capabilities and construct AUTH_VERIFY_BODY and SMS_OTP_BODY against those schemas. That extra step is deliberate. Request contracts are machine-readable, while copying speculative fields into an article creates code that looks runnable and fails at the boundary.

The sample retries 429 responses with Retry-After or exponential backoff, sends explicit methods, surfaces error bodies, and gives each write a stable idempotency key. Do not log either request body. The useful audit evidence is who initiated recovery, which policy allowed it, the channel selected, request correlation IDs, outcomes, and time.

Where should the trust boundary sit?

A combined provider reduces integration work. Infrai exposes auth and SMS behind the same REST API and one API key, with no SDK to install or client-library version to maintain. Its public discovery surface publishes request and response schemas, and every documented capability has runnable examples in 10 languages; that is useful when a small team wants schema-driven checks in CI. The supporting advantage here is operational correlation: one key covers identity and delivery, with one bill to reconcile. The broader catalog covers 295 routes across 20 modules under that key, so the recovery service does not need a separate credential registry and invoice owner for each adjacent backend capability.

There is a real limitation. You trust one vendor with more of the recovery path, receive one bill, and inherit one larger outage surface. This combined approach is not a fit for teams that require separate identity and delivery failure domains or independent vendor procurement. In that case I would choose Auth0 or Clerk with Twilio Verify and accept the extra credentials and correlation glue. Separate providers also let a team isolate vendors or replace one side independently.

The alternative stacks differ in where that boundary lands:

Stack	Operational shape	Best fit	Cost you accept
Auth0 plus Twilio Verify	Two signups, two credential sets, identity webhooks or application glue to correlate verification and delivery	Teams wanting mature identity controls while choosing a dedicated verification channel	More cross-vendor failure handling and audit correlation
Clerk plus Twilio Verify	Two signups and two credential sets; Clerk handles application identity while custom glue connects recovery state to Verify	Product teams that value Clerk's prebuilt user-management experience	Tighter application coupling to Clerk's frontend-oriented workflow plus a separate delivery dependency
Firebase Authentication	One managed identity platform with supported passwordless email-link and phone flows	Applications already centered on Firebase clients and administration	Platform coupling and channel behavior shaped by Firebase's authentication model
One REST surface for auth and SMS	One signup, one credential set, and one correlation layer in the application	Small backends that value a language-neutral HTTP contract and low integration overhead	Concentrated vendor trust, billing, and outage exposure

Twilio Verify is not merely an SMS pipe; it owns verification workflows. Auth0, Clerk, and Firebase Authentication likewise have broader feature sets than this single recovery seam. Compare enrollment, factor management, administrative controls, regional requirements, and export paths before choosing. This article's decision axis is narrower: session security versus recovery friction for an audited logistics workflow.

One signup instead of two is convenient. It is also concentration risk.

Audit the state transitions, not the message copy

A useful audit trail reads like a state machine: challenge_requested, challenge_verified, session_created, or recovery_denied. Each transition needs a stable recovery identifier, actor or subject reference, policy version, channel, result, and timestamp. Store delivery-provider correlation IDs where available. Avoid recording the one-time code, full message, bearer token, or raw verification payload.

Make session issuance its own controlled transition. Verification proves control of a channel at a moment in time; it does not justify an unlimited session. Session lifetime, rotation, revocation, and step-up requirements should reflect what a recovered user can do. A dispatcher viewing a shipment and an administrator changing payout details should not inherit identical post-recovery privileges by accident.

Keep it boring.

Generic responses and consistent timing reduce account enumeration. Rate limits should cover the account, destination, client, and broader abuse pattern rather than one IP alone. For the operational side, alert on request-to-verification conversion, delivery failures, latency distribution, throttling, and sudden channel shifts. The mail or SMS channel is a login dependency, not a marketing system that can wait until morning.

The shipping decision

Choose passwordless recovery when removing stored password verifiers and reducing reset friction outweighs dependence on a delivery channel. Keep passwords when offline or channel-independent access is a hard requirement, or pair passwordless with another factor for high-impact actions. Do not call the choice safer without naming the threat and the failure mode.

Before release, walk one recovery identifier from challenge request through verification and session creation in a staging audit export. Confirm that retries do not duplicate writes, expired or replayed challenges fail, generic responses hide account existence, sensitive payloads are absent from logs, and revocation behaves according to policy. Then test degraded email and SMS paths with the same seriousness as a database dependency. That exercise is more valuable than a long feature checklist because it proves both the security boundary and the human recovery path.

DEV Community