SYSTEM Cited by 1 source

Airbnb Flexible Authentication¶

Overview¶

Flexible Authentication is Airbnb's rebuilt login and signup platform, replacing an authentication stack that had grown organically over a decade (accreting Social Login, Email OTP, and Phone as separate methods). Its design goal is to let users "pick up exactly where they left off, regardless of how much time had passed or which device they were using" — a structural requirement for a two-sided marketplace where guests log in at irregular intervals and a failed login is lost revenue for both guest and host. (Source: sources/2026-08-12-airbnb-flexible-authentication)

Architecture¶

Three architectural pillars, each a direct expression of a product insight:

1. Identify first, then challenge¶

The flow is split into two stages (see concepts/identify-first-then-challenge):

Identify — the user states who they are using whatever method they want (email, phone, social login).
Challenge — once the target account is known, a configurable policy engine picks the verification challenge most likely to succeed for that account and context, leads with it, and offers the rest as fallbacks.

The policy engine can use all available session/account signals, including history (what the person has succeeded with before, what methods are registered, what's available on their platform). Airbnb states it has "only started to scratch the surface" of optimizing it. Regional examples: WhatsApp OTP over SMS in Brazil; Naver over Google ID in South Korea.

2. Challenge Picker ("try another way")¶

A hard product requirement — every authentication screen must offer an escape — implemented as the Challenge Picker (patterns/server-ranked-challenge-fallback), a server-driven component accompanying every challenge screen. The server returns the primary challenge plus a ranked list of alternatives ordered by predicted success for the person's context. Tapping "Try another way" adapts the flow in place rather than restarting it — contrast the legacy system, where a failed SMS meant navigating back to re-enter an email to attempt password login. This also decouples login-flow availability from any single challenge's backend: if one method is down, users complete another.

3. Fully server-driven, screen as unit of abstraction¶

The experience is fully server-driven, with the screen as the fundamental unit of abstraction (patterns/server-decides-client-renders). Each step — identifier input, challenge, account picker, error recovery — is a screen defined entirely by the server response. The client is "only required to serve as a thin renderer that knows how to display a set of screen types and send actions back, with no opinion about sequence, copy, or flow logic." The client never decides which challenge to present.

Because screens are defined by a server-side schema, the Web, iOS, and Android clients consume automatically generated type definitions, so client/server mismatches are caught during development.

Results¶

60% reduction in (client-side) auth code and a 100 KB smaller web client bundle after moving screen sequencing and flow logic to the server.
20+ experiments in the three months since launch; most needed no client change, collapsing idea→result from weeks to days.
+2.6% authentication-success rate (from an already-high base, affecting millions of sessions).
−27% duplicate accounts (returning users reach their existing account, preserving trip history / reservations).
~−11% OTP cost (fewer one-time SMS codes sent) as more journeys resolve through completable challenges.

Relationship to the SDUI lineage¶

The concepts/server-driven-ui page long cited the "Airbnb Ghost Platform" as the widely-referenced SDUI precedent that was not on the wiki. Flexible Authentication is the first concrete Airbnb SDUI instance documented here, and it applies SDUI to a flow-logic-heavy, correctness- and-availability-critical surface (authentication) rather than to content screens — a notable extension of the pattern's usual application (cf. Yelp CHAOS, Zalando Appcraft).

Caveats¶

Policy-engine internals (heuristics vs. ML, exact signals, success-rate computation), the screen-schema wire format, and the codegen toolchain are not disclosed.
No auth-service throughput/latency/availability SLOs are published; results are percentages without absolute baselines or confidence intervals.
Security details (account-enumeration hardening, rate limiting, trade-offs of always exposing all fallbacks) are out of scope in the source.