"When logging in, we want to insert additional identity verification only for users meeting specific conditions." A request starting with this single sentence can sometimes take three months.
You update the iOS app, update the Android app, and update the web app. You test each one and submit the mobile apps for review. Even after release, users do not always update right away, meaning you must support apps running the old flow for several months. During that time, the server must remain capable of responding to both the old and new flows.
The authentication architecture rebuild published by Airbnb in August 2026 is an example of shifting this exact structure. As a result, authentication-related code decreased by 60%, and the delivery size of the web client dropped by 100 KB. However, the real takeaway is not the scale of the reduction, but rather what was relocated and where.
Taking screen ordering away from clients
In the traditional architecture, the flow logic—such as prompting for a password after entering an email address or inserting a one-time password under specific conditions—was written separately into each app and the web client. The same decision logic was duplicated across three places.
After the rebuild, the server determines which screen to display next. The client is dedicated entirely to the role of rendering the screen delivered by the server and contains no conditional branching. A server-side policy engine selects which identity verification method to require based on the user and session context.
Summarizing what changed through this shift yields the following comparison:
| Change to make | Traditional | After shifting to server-driven |
|---|---|---|
| Adding an identity verification step | Update three clients and wait for app store review | Completed entirely via server-side configuration changes |
| Changing the flow based on conditions | Implement conditional branching across each client | Add conditions on the policy side |
| Users on older versions | Must continuously maintain the legacy flow | Receive the same server response |
The published benefits report a 2.6% improvement in authentication success rates, a 27% drop in duplicate account creations, and an 11% reduction in one-time password delivery costs. The improvements in success rates and duplicate accounts resulted from centralizing decisions in one place, not merely cutting code volume. Implementations split across three places will inevitably diverge in behavior somewhere.
Can this be adopted as-is in small and medium-scale systems?
Some parts only make sense at Airbnb's scale, while others are effective regardless of scale.
What is difficult to adopt directly is the policy engine itself. A mechanism that dynamically selects the optimal identity verification method based on user context becomes a major development project in its own right. In an internal system where login frequency is modest, recouping this investment is difficult.
What works regardless of scale is having the server return the screen order. Simply including the name of the next screen to display and the required input fields in the server response decouples flow changes from client updates. Even without a policy engine, consolidating conditional branching into a single server-side file eliminates duplication across three places.
As a guideline for decision-making, the criteria can be broken down as follows:
- Distributing mobile apps where waiting for app reviews bottlenecks iteration speed → High likelihood of seeing strong benefits
- Running purely on the web with no plans to change authentication flows anytime soon → Little urgency
- Concrete plans to add authentication methods (introducing multi-factor authentication, passkey support, etc.) → Worth executing in tandem with that effort
Many companies will fall into the third category. If you are currently evaluating migrating to passkeys or adding multi-factor authentication to prevent account takeovers, deciding now whether to continue updating clients each time a method is added or to shift flow ownership first will dramatically change the volume of future refactoring.
Where to draw the boundary for a rebuild
Deciding to rebuild the entire authentication architecture all at once often creates unpredictable returns relative to the risk. If you phase the rollout, the following order is realistic:
First, begin by counting where and in how many variations authentication flows are currently written. Beyond iOS, Android, and web, admin portals and external integration entry points often have separate implementations. If the count is two or fewer, the priority for a rebuild decreases.
Next, build only newly added authentication methods using a server-driven model. Leave existing flows intact so that only users using the new method take the new path. A key benefit of this design is that new and old flows can run concurrently without breaking existing paths.
Migrating existing paths can wait until the new method has stabilized. Attempting this step first makes it difficult to isolate root causes if some users become unable to log in.
What to do next
List the places in your systems that determine login screen transitions. File names are fine.
If there are three or more places and you plan to add authentication methods within the next year, centralizing the flow logic onto the server alongside that addition is worthwhile. If you have no such plans, it is sufficient to file this case study away simply as knowledge of an alternative architecture.
GleamHub provides consultations on development, AI, and automation to review authentication architectures and transition existing systems without downtime. Because the appropriate scope varies depending on your current architecture and user base, please reach out via Contact Us.
