Flexible Authentication: Server-Driven Flows at Airbnb
Airbnb re-architected its authentication system using a "Flexible Authentication" paradigm to improve user experience and engineering velocity. This involved splitting the login flow into "Identify first then Challenge," offering "Try another way" options, and fundamentally shifting to a fully server-driven UI for authentication screens. This approach decoupled client releases from authentication logic, enabling rapid experimentation and significant improvements in login success rates and cost efficiency.
Read original on Airbnb EngineeringAirbnb faced a challenge with its decade-old authentication system, which struggled with diverse user patterns like infrequent logins and varied regional preferences for authentication methods. The goal was to create a more seamless and adaptable login experience while improving engineering agility. This led to the development of Flexible Authentication, a system design centered on moving logic from client to server.
Identify First, Then Challenge Architecture
The core product insight was to treat authentication as a two-stage process: Identify first, then Challenge. Instead of a monolithic login process, users first identify their account (via email, phone, social login) and then a server-side policy engine dynamically determines the most suitable challenge (e.g., WhatsApp OTP for Brazil, Naver login for South Korea). This separation allows for highly contextual and optimized challenge delivery. The critical architectural decision here is that the client never decides which challenge to present; the server makes that call, enabling per-region or per-user tuning without client updates.
Server-Driven UI for Critical Flows
Moving complex, frequently changing logic (like authentication) to the server via a server-driven UI approach significantly increases iteration speed and reduces client-side complexity. This pattern is particularly powerful for flows where user context, A/B testing, and rapid adaptation are crucial, as it decouples business logic changes from client release cycles.
Eliminating Dead Ends with a Server-Driven Challenge Picker
A key design principle was to eliminate login "dead ends." If a user couldn't complete the primary challenge, the old system often left them stuck. The new architecture introduces a Challenge Picker, a server-driven component that accompanies every challenge screen. The server not only returns the primary challenge but also a ranked list of alternative authentication methods, allowing users to select "Try another way." This ensures adaptability and resilience, even if a particular challenge method (e.g., SMS) is temporarily unavailable or inconvenient for the user.
Fully Server-Driven Screens and Workflow
To achieve rapid iteration, the entire authentication experience was made fully server-driven. Each step (identifier input, challenge, error recovery) is defined as a screen by a server response. The client acts as a thin renderer, displaying screen types and sending actions back, without containing flow logic, copy, or sequencing. This approach significantly reduced client-side code by 60% and enabled over 20 experiments in three months, transforming feedback cycles from weeks to days. This architecture facilitates A/B testing and continuous optimization of the user journey.
- Improved User Experience: Reduced time to login, 2.6% increase in successful authentications.
- Cost Reduction: 11% cut in OTP costs due to smarter challenge selection.
- Reduced Duplicate Accounts: 27% decrease as more users successfully re-authenticate to existing accounts.
- Increased Velocity: Rapid experimentation and deployment without client updates.