devgo.cn一句话看懂
这篇讲 Airbnb 如何重新设计登录注册流程，把原本混杂的验证步骤拆成"先认出你是谁，再选最方便的方式验证"两步。值得关注是因为它展示了一种服务器驱动的灵活认证架构，不仅让用户登录更快更顺，还让团队能快速实验新想法，不用等应用商店审核。
核心观点
1. **两阶段模型取代单步验证**：旧系统把登录当成"你能不能证明身份"一个问题，新系统拆成"你是谁"和"怎么验证你"两步。这意味着可以根据用户所在地区、设备、历史行为，动态选择最可能成功的验证方式，而不是固定一种。
2. **服务器控制流程，客户端只负责显示**：所有登录步骤的顺序和内容都由服务器决定，客户端只渲染收到的屏幕。这带来的好处是：修改流程不需要发新版App，实验周期从几周缩短到几天。
3. **每个验证页面都有"换一种方式"出口**：用户如果完成不了当前验证（比如收不到短信），可以一键切换到其他方式，流程不会中断。这大幅减少了用户因卡住而流失的情况。
4. **架构重构带来可量化的收益**：客户端代码减少60%，Web包体积减少100KB，认证成功率提升2.6%，重复账户下降27%。这些数字说明，好的架构设计能同时改善用户体验和业务指标。
正文精讲
Airbnb 的登录场景很特殊：用户可能一月份订了房，到夏天才再次打开App；房东可能只在有预订时登录。如果登录失败，客人订不了房，房东收不到钱，双方都受损。但 Airbnb 的认证系统是十年间慢慢拼凑起来的，支持了社交登录、邮箱OTP（一次性验证码）、短信验证码等多种方式，却没有针对这种"低频但关键"的使用模式做优化。
团队发现，问题的核心不是"用户能不能证明身份"，而是"哪种方式对他们最简单"。一个用手机号注册的巴西旅行者，收短信可能很慢，但 WhatsApp 在巴西普及率极高，发个 WhatsApp OTP（通过WhatsApp发送的一次性验证码）就快多了。一个韩国房东用 Naver（韩国主流身份提供商）登录比用 Google 顺手得多。所以，正确的做法是先问"你是谁"，再根据你的情况选最合适的验证方式。
基于这个洞察，他们设计了"Identify first then Challenge"（先识别身份，再选择验证）模型。
流程分成两步：第一步，用户用邮箱、手机号或社交账号告诉系统自己是谁；第二步，一个可配置的策略引擎根据用户会话和账户信息，选出最可能成功的验证方式作为首选，其他方式作为备选。关键架构决策是：客户端从不决定显示哪个验证方式，服务器说了算。客户端只负责渲染收到的屏幕，不管流程逻辑。
另一个重要改进是"Try another way"（换一种方式）机制。
旧系统里，如果你收不到短信验证码，就只能返回重新选其他方式，流程中断。新系统要求每个验证屏幕都必须提供"换一种方式"按钮，点击后显示一个由服务器排序的备选列表，按预测成功率排列。用户不会卡死，流程自适应。
服务器驱动的架构还带来了额外的速度优势。
以前，想改登录流程得等App审核和灰度发布，几周才能开始实验。现在，所有屏幕顺序和内容都由服务器定义，客户端只是一个"瘦渲染器"，知道怎么显示几种屏幕类型并发送用户操作。修改流程只需改服务器配置，实验周期从周缩短到天。上线三个月，他们已经跑了20多个实验。
这些改变带来的效果很直接。客户端代码减少了60%，Web包体积小了100KB——这对网络慢或设备旧的用户是实打实的提升。登录时间显著下降，因为系统一开始就选最可能成功的方式。认证成功率从已经很不错的基础上又提升了2.6%，影响数百万次会话。重复账户减少了27%，因为用户更容易找回原有账户，而不是重新注册。OTP发送量也减少了，因为更多验证通过更高效的方式完成。
读完你能做什么
1. **如果你的产品有登录/注册流程，可以借鉴"先识别身份再选验证方式"的两阶段设计**：先收集用户标识（邮箱、手机号等），再根据用户历史、设备、地区动态选择最优验证方法，而不是固定一种。
2. **想快速验证新流程，用服务器端控流程、客户端只渲染的架构**：这样迭代周期从周缩短到天，不用等应用商店审核。适合需要频繁实验的团队。
3. **避免用户卡死在某个验证环节**：每个验证步骤都提供"换一种方式"的备选方案，让用户能灵活切换，减少流失。
4. **关注低频但关键的用户场景**：像Airbnb这样用户可能几个月才登录一次，认证流程必须为这种模式优化，而不是只考虑高频用户。
内容与图片版权归原作者所有 · 原文: https://medium.com/airbnb-engineering/flexible-authentication-reimagining-authentication-for-millions-of-users-at-airbnb-3a8a4c917137?source=rss----53c7c27702d5---4