Airbnb's Server-Driven Authentication Architecture
Airbnb redesigned its authentication architecture by shifting decision-making from client applications to a server-side policy engine. This server-driven approach enables dynamic adjustment of authentication flows, experimentation without client updates, and a significant reduction in client-side code, improving flexibility and user experience. The system centrally manages challenges based on user context, optimizing for success and offering fallback options.
Read original on InfoQ ArchitectureShifting Authentication Logic to the Server
Airbnb's new authentication architecture fundamentally alters how login and signup flows are managed by moving the decision-making logic from client applications (Web, iOS, Android) to a centralized server-side policy engine. This allows for dynamic adjustments to authentication challenges based on user and session context, without requiring client-side code deployments. The primary benefit is increased agility in responding to evolving security needs and user preferences, reducing the burden on client development teams.
Identify-then-Challenge Architecture
The architecture operates in two main stages: Identify and Challenge. Users first identify their account (e.g., via email, phone, social login). The server then evaluates this information along with session details and applies a configurable policy engine to select the most suitable authentication challenge. This engine can prioritize methods based on factors like geographical location (e.g., WhatsApp OTP for Brazil) or user history, while also providing fallback options.
Key Architectural Shift
Clients no longer dictate which authentication challenge to present; they simply render the screens returned by the server. This decouples the authentication business logic from client UI, enabling rapid experimentation and localized adaptations.
Benefits and Outcomes
- Code Reduction: Achieved a 60% reduction in authentication-related client code and a 100 KB reduction in the web client bundle.
- Increased Success Rate: Improved successful authentication by 2.6%.
- Reduced Duplicates: Decreased duplicate account creation by 27%.
- Faster Experimentation: Experiments not requiring client changes moved from idea to measured result in days rather than weeks, with over 20 experiments run in the first three months.
- Enhanced User Recovery: Introduction of a server-driven "Challenge Picker" helps users recover from authentication failures by providing ranked alternative methods based on past success and registered options.
This server-driven model extends beyond login to cover signup, account selection, and error handling. Server-side schemas are also used to generate client-side type definitions, aiding in development and consistency across platforms.