Airbnb با انتقال منطق تصمیم‌گیری احراز هویت از کلاینت به یک موتور سیاست‌گذاری سمت سرور توانست کدهای مرتبط با احراز هویت را تا 60% کاهش دهد، اندازهٔ باندل وب را حدود 100 کیلوبایت کوچک‌تر کند و نرخ موفقیت ورود کاربران را 2.6% افزایش دهد؛ همچنین ثبت حساب‌های تکراری 27% کاهش یافت.

معماری «شناسایی سپس چالش»

رویکرد احراز هویت هدایت‌شده توسط سرور در دو مرحله پیاده‌سازی شده: ابتدا کاربر شناسه‌ای مانند ایمیل، شماره تلفن یا ورود اجتماعی وارد می‌کند؛ سپس سرور بر اساس اطلاعات حساب، سابقهٔ نشست و زمینهٔ منطقه‌ای بهترین روش احراز هویت را انتخاب می‌کند. انتخاب ممکن است براساس منطقهٔ جغرافیایی، روش‌های پیشین موفق یا در دسترس بودن پلتفرم تغییر کند؛ برای مثال، ارسال کد یک‌بار مصرف (OTP) از طریق واتس‌اپ برای کاربرانی در برزیل یا استفاده از ارائه‌دهنده هویت محلی در کرهٔ جنوبی.

چرا تصمیم‌گیری روی سرور اهمیت دارد

  • کلاینت‌ها از نگهداری منطق پیچیدهٔ انتخاب روش بی‌نیاز می‌شوند.
  • به‌روزرسانی سیاست‌های احراز هویت بدون انتشار نسخهٔ جدید کلاینت ممکن می‌شود.
  • قابلیت اجرای سریع‌تر آزمایش‌های A/B و اعمال سیاست‌های منطقه‌ای در مقیاس فراهم می‌آید.
صفحهٔ ورود هدایت‌شده توسط سرور در Airbnb

انتخاب‌گر چالش (Challenge Picker)

انتخاب‌گر چالش سمت سرور پس از شکست یک روش، بدون نیاز به شروع مجدد، گزینه‌های جایگزین را پیشنهاد می‌دهد. هر چالش شامل گزینهٔ «روش دیگری را امتحان کنید» است و سرور بر اساس سابقهٔ موفقیت، روش‌های ثبت‌شده و در دسترس بودن پلتفرم، جایگزین‌ها را رتبه‌بندی می‌کند. این مکانیزم تجربهٔ بازیابی از خطا را هموارتر کرده و نرخ موفقیت را افزایش می‌دهد.

نمایش صفحات تعریف‌شده توسط سرور در همهٔ کلاینت‌ها

در این مدل، سرور صفحات (screen) را با اسکیمای مشخص تعریف می‌کند و کلاینت‌های وب، iOS و Android این صفحات را رندر و اقدامات کاربر را به سرور ارسال می‌کنند. اسکیمای سمت سرور همچنین تعاریف نوع (type definitions) تولید می‌کند تا ناسازگاری‌ها در زمان توسعه زودتر کشف شوند و توسعهٔ مشترک میان تیم‌ها تسهیل گردد.

تأثیر بر چرخهٔ آزمایش و توسعه

با تمرکز منطق جریان روی سرور، Airbnb توانست در سه ماه اول پس از پیاده‌سازی بیش از 20 آزمایش اجرا کند. آزمایش‌هایی که نیازی به تغییر در کلاینت نداشتند از ایده تا نتیجه در روزها به‌جای هفته‌ها رسیدند و این امکان را فراهم ساخت سیاست‌های محلی و تجربهٔ کاربری را سریع‌تر اندازه‌گیری و اصلاح کنند.

نتایج عددی و مزایا

  • کاهش حجم کد مرتبط با احراز هویت: 60%
  • کاهش اندازهٔ باندل وب: حدود 100 کیلوبایت
  • افزایش نرخ موفقیت ورود: 2.6%
  • کاهش ثبت حساب‌های تکراری: 27%
  • کاهش هزینه‌های ارسال OTP: تقریباً 11%

چالش‌ها و درس‌های طراحی تجربه

نسخهٔ اولیهٔ مینیمالیستی باعث شد کاربران گزینه‌ها را نادیده بگیرند و تعامل کاهش یابد؛ تیم طراحی مجبور شد بین سادگی رابط و هدایت کاربر برای تکمیل فرایند متعادل کند. یافتن این تعادل و ارائهٔ بازخوردهای واضح هنگام شکست یک روش، برای نرخ تبدیل حیاتی بود.

نکات فنی و اجرایی برای مهندسان

  • پیاده‌سازی یک رنکر سمت سرور برای رتبه‌بندی روش‌ها بر اساس نرخ موفقیت و هزینه.
  • تعریف اسکیمای واحد برای screens و تولید type definitions برای جلوگیری از ناسازگاری بین کلاینت‌ها.
  • طراحی جریان‌های پشتیبان (fallback) واضح تا کاربر در صورت شکست یک روش بدون توقف ادامه دهد.
  • نظارت و جمع‌آوری متریک‌های دقیق برای هر روش (نرخ موفقیت، زمان تکمیل، هزینهٔ ارسال OTP و...)، و استفاده از این داده‌ها در تصمیم‌گیری‌های بلادرنگ.
  • قابلیت به‌روزرسانی سیاست‌ها و محتوای صفحه بدون نیاز به انتشار نسخهٔ جدید کلاینت.

پیامد برای تیم‌های محصول و مهندسی

مدل احراز هویت هدایت‌شده توسط سرور نمونه‌ای روشن از جدا کردن منطق تصمیم‌گیری از رابط کاربری است. این رویکرد به تیم‌ها امکان می‌دهد رفتار سیستم را سریع و با ریسک کمتر تغییر دهند و سیاست‌های محلی را به‌صورت هدفمند اجرا کنند. برای مروری فنی بیشتر دربارهٔ احراز هویت می‌توانید به منابع مرجع مراجعه کنید: Authentication (Wikipedia) و صفحات مهندسی Airbnb: airbnb.io.

چشم‌انداز

معماری سرور-محور احراز هویت به Airbnb امکان می‌دهد آزمایش روش‌های جدید، اعمال سیاست‌های منطقه‌ای و بهینه‌سازی هزینه‌ها را بدون تغییر گسترده در اپلیکیشن‌ها ادامه دهد. این الگو برای سرویس‌های بزرگ با تنوع کاربران و روش‌های ورود می‌تواند الگوی عملی و مقیاس‌پذیر فراهم سازد.