Airbnb rebuilt its authentication system around a paradigm called Flexible Authentication, splitting login into an 'Identify first then Challenge' model where a server-side policy engine picks the most likely-to-succeed verification method based on user context (e.g., WhatsApp OTP in Brazil, Naver login in South Korea). Every challenge screen now offers a 'Try another way' fallback via a Challenge Picker component, and the entire flow became server-driven with the client acting as a thin renderer. Results after three months: 60% code reduction, 100KB smaller web bundle, 20+ experiments run without client releases, 2.6% higher authentication success rate, 27% fewer duplicate accounts, and roughly 11% lower OTP costs.
Table of contents
Rebuilding login and signup surfaced product insights, not just technical challenges. Here’s how we designed Flexible Authentication at the intersection of product intuition and technical architecture.Identify first then ChallengeTry another wayGet Jose Santos’s stories in your inboxMoving faster than our client release cyclesResultsConclusionAcknowledgmentsQuestions this post answers
What is the identify-first-then-challenge authentication model?
It is an authentication design that splits login into two stages: first the user identifies themselves with any method (email, phone, social login), then a server-side policy engine selects the challenge most likely to succeed for that person's context, such as a WhatsApp OTP for a Brazilian user or a Naver login for a South Korean host, with other options offered as fallbacks. Explore more architecture writeups like this on daily.dev when weighing authentication design tradeoffs.
What results came from making an authentication system fully server-driven instead of client-driven?
Moving authentication logic to the server produced a 60% reduction in code, a 100KB smaller web client bundle, and enabled 20+ experiments in three months without app store releases. Authentication success rate rose 2.6%, duplicate accounts fell 27%, and OTP costs dropped roughly 11%, because flows could adapt per-region and per-experiment without shipping new client binaries. Developers evaluating server-driven UI patterns can find similar engineering case studies on daily.dev.
Why did Airbnb add a 'try another way' fallback to every authentication screen?
Their previous system had dead ends: users who couldn't complete SMS or password challenges got stuck with no alternative path. The fix was a Challenge Picker component that ranks alternative login methods by predicted success for that user's context, so tapping 'try another way' adapts the flow instead of restarting it from scratch. See how teams handle login UX edge cases and fallback design on daily.dev.