احراز هویت یکپارچه و خصوصی کاربر با FedCM: پیاده سازی Seznam'

رهبران صنعت در بخش‌های مختلف درک می‌کنند که حفظ حریم خصوصی در عین ارائه یک تجربه عالی برای همه کاربرانشان چقدر مهم است. Seznam که به ارائه تجربه کاربری و حفظ حریم خصوصی بی‌خطر اختصاص دارد، مدیریت اعتبار فدرال (FedCM) را با موفقیت یکپارچه کرده است.

پروفایل های هدف: شرکت هایی که از FedCM سود می برند

سازمان ها در دامنه های مختلف FedCM را با راه حل های خود ادغام کرده اند. با توجه به طراحی FedCM برای مدیریت هویت فدرال، ارائه دهندگان هویت (IdPs) ذینفعان اصلی آن هستند که از آن برای ارائه یک تجربه ورود بهبودیافته استفاده می کنند. ارائه دهندگان خدمات تجارت الکترونیک و ارائه دهندگان پرداخت، که بسیاری از آنها نیز به عنوان ارائه دهندگان هویت عمل می کنند، فرصت هایی را برای بهبود تجربه کاربر از طریق پیاده سازی FedCM شناسایی کرده اند.

سزنم

Seznam یک شرکت فناوری اروپایی و ارائه دهنده هویت است که 90٪ جمعیت چک را در اختیار دارد. به عنوان یک مرکز اجتماعی، دانش و محتوا عمل می کند. Seznam از FedCM استفاده کرد تا به مشتریان فروشگاه‌های آنلاینی که در پلتفرم‌های شرکای خود کار می‌کنند اجازه دهد تا با استفاده از حساب Seznam خود وارد شوند.

با FedCM، Seznam به افزایش قابل توجهی در نرخ ورود کاربر در شبکه های شرکای خود، تجربه کاربری بهبود یافته و جریان هویت ثابت بدون توجه به در دسترس بودن کوکی های شخص ثالث دست یافت.

انگیزه

انتخاب Seznam برای پیاده سازی FedCM به دلیل چندین مزیت بود که آنها تشخیص دادند:

• FedCM با در نظر گرفتن کاربر نهایی طراحی شده است و به کاربر امکان کنترل اطلاعات ارائه شده به IdP را می دهد. این با دیدگاه Seznam در مورد یک محیط امن و خصوصی برای کاربران خود مطابقت دارد.
• FedCM یک ویژگی داخلی مرورگر است که با تجربه ورود به سیستم موجود Seznam که از استاندارد OAuth 2.0 استفاده می کند، سازگار است.
• FedCM طراحی شده است تا یک رویکرد حفظ حریم خصوصی برای فدراسیون هویت باشد. برای مثال، این واقعیت که کاربر از طرف متکی (RP) بازدید کرده است تنها در صورتی با IdP به اشتراک گذاشته می‌شود که کاربر بخواهد وارد سیستم شود. این با دیدگاه Seznam در مورد تجارت پایدار مطابقت دارد.

جزئیات پیاده سازی

Seznam FedCM را به عنوان یک لایه در بالای راه حل OAuth موجود خود پیاده سازی کرد. در این معماری، جریان FedCM برای انتقال ایمن کد مجوز OAuth از IdP به RP ها استفاده می شود.

تلاش برای اجرا

سزنم تاکید کرد که اجرای FedCM ساده و همسو با رویکرد موجود آنها بود. تحقیق و اجرای API آنها یک ماه طول کشید و به تلاش دو توسعه دهنده نیاز داشت. کمتر از دو ماه طول کشید تا FedCM به تولید برسد. این فرآیند تکراری بود و زمان قابل توجهی به مطالعه دقیق API اختصاص داده شد.

چالش ها

Seznam به‌عنوان یک پذیرنده اولیه، چندین چالش را شناسایی کرد و بازخورد ارزشمندی ارائه کرد که به بلوغ API کمک کرد.

پشتیبانی از چندین ارائه دهنده هویت

Seznam علاقه مند به پشتیبانی FedCM از چندین ارائه دهنده هویت بود. با استفاده از این ویژگی، آنها قصد داشتند به کاربران اجازه دهند بین حساب های Seznam یا Google در RP های شرکای خود یکی را انتخاب کنند. با این حال، زمانی که Seznam برای اولین بار به پیاده سازی FedCM خود نزدیک شد، این ویژگی در مراحل اولیه پیاده سازی بود و توسعه دهندگان ملزم به ثبت نام برای آزمایش اولیه و استفاده از یک توکن برای فعال کردن ویژگی برای کاربران خود بودند. به همین دلیل، Seznam تصمیم گرفت منتظر باشد تا این ویژگی در Chrome Stable ارسال شود.

این ویژگی در Chrome 136 در دسترس است و توسعه دهندگان می توانند پشتیبانی را برای چندین ارائه دهنده هویت پیکربندی کنند. به عنوان مثال، برای پشتیبانی از هر دو ارائه‌دهنده هویت Seznam و Google، IdP می‌تواند این دو ارائه‌دهنده را در یک فراخوانی get() شامل شود، و RP نیز می‌تواند این کار را به‌طور مستقل انجام دهد:

  // Executed on the RP's side:
    const credential = await navigator.credentials.get({
      identity: {
        providers: [
          {
            // IdP1: Seznam's config file URL
            configURL: 'https://szn.cz/.well-known/web-identity',
            clientId: '123',
          },
          {
            // Also allow Google Sign-in
            configURL: 'https://accounts.google.com/gsi/fedcm.json',
            clientId: '456',
          },
        ],
      },
    });

Seznam اشاره کرده است که این ویژگی بخشی از راه حل آنها خواهد بود. علاوه بر این، تیم FedCM در حال اجرای پشتیبانی از چندین SDK با پشتیبانی از تماس‌های get() متعدد است.

DNS خصوصی

Seznam در مرحله آزمایش با یک چالش مرتبط با پیکربندی شبکه آنها مواجه شد. سرور IdP آزمایشی آنها در یک شبکه خصوصی قرار داشت که فقط از طریق DNS خصوصی قابل دسترسی است. این راه‌اندازی برای محیط‌های آزمایش داخلی و توسعه قبل از نمایش عمومی خدمات رایج است.

با این حال، این راه‌اندازی به یک چالش منجر می‌شود: از آنجا که یک فایل well-known باید از یک eTLD+1 ارائه شود و یک دامنه توسعه خصوصی در فهرست پسوند عمومی ثبت نشده است، مرورگر درخواست‌هایی برای واکشی فایل well-known میزبانی شده در دامنه توسعه ارسال نمی‌کند:

• login.idp.example : نمونه دامنه تولید.
• idp.example/.well-known/web-identity : نمونه فایل شناخته شده در حال تولید.
• login.dev.idp.example : نمونه دامنه توسعه.
• login.dev.idp.example/.well-known/web-identity : نمونه فایل شناخته شده در محیط توسعه.

هنگامی که پیاده سازی FedCM در یک دامنه خصوصی میزبانی می شود، درخواست مرورگر به فایل well-known منجر به این خطا می شود:

The fetch of the well-known file resulted in a network error: ERR_NAME_NOT_RESOLVED

این خطا را می توان با فعال کردن Chrome #fedcm-without-well-known-enforcement flag حل کرد. هنگامی که این پرچم فعال می شود، مرورگر از واکشی فایل well-known برای اهداف آزمایشی خودداری می کند. با نحوه فعال کردن پرچم‌های آزمایشی در Chrome آشنا شوید.

افشای اطلاعات سفارشی

Seznam همچنین به اشتراک گذاشت که آنها می خواهند اطلاعات اضافی را در کنار طراحی اولیه رابط کاربری FedCM اضافه کنند. گفتگوی استاندارد FedCM یک پیام ثابت را به کاربر نمایش می دهد که بیان می کند داده های خاص - معمولاً تصویر نمایه، نام و آدرس ایمیل کاربر - با RP به اشتراک گذاشته می شود.

تیم FedCM بازخورد را ترکیب کرد و API را گسترش داد تا امکان سفارشی سازی افشای ارائه شده به کاربر را فراهم کند. برای مثال، با ویژگی Continue on ، IdP می‌تواند کاربر را به یک صفحه سفارشی هدایت کند تا اطلاعات یا مجوزهای بیشتری درخواست کند. پارامترهای سفارشی و ویژگی‌های Fields که از Chrome 132 پشتیبانی می‌شوند، امکان سفارشی‌سازی بیشتر را فراهم می‌کنند.

اعتبارسنجی مبدأ طرف متکی

سرور IdP باید سرصفحه Origin HTTP را در یک درخواست FedCM ورودی اعتبار سنجی کند تا اطمینان حاصل شود که درخواست با مبدای که RP از قبل با IdP ثبت شده مطابقت دارد. این تضمین می‌کند که درخواست ادعای FedCM ID از یک RP مجاز می‌آید و نه از مهاجمی که از client_id استفاده می‌کند.

Seznam یک موقعیت گوشه ای دارد: وقتی RP های شریک آنها در Seznam ثبت نام می کنند، اطلاعات مبدا RP را درخواست نمی کنند. این بدان معنی است که منشاء RP را نمی توان تأیید کرد.

ادغام FedCM Seznam بر روی یک راه حل موجود OAuth ساخته شده است. آنها مسیر جایگزین اعتبار سنجی client_id و client_secret RP را انتخاب کردند تا مطمئن شوند که راه حل بدون نیاز به بررسی مبدا امن باقی می ماند.

دامنه روبروی کاربر ارائه دهنده هویت

زیرساخت احراز هویت کاربر Seznam عمدتاً در دامنه szn.cz کار می کند، جایی که نقاط پایانی IdP لازم برای FedCM میزبانی می شود. با این حال، هویت شرکتی اصلی آنها و دامنه‌ای که کاربران به طور گسترده خدمات آنها را می‌شناسند و به آن اعتماد می‌کنند، seznam.cz است.

گفتگوی FedCM دامنه اصلی اصلی نقاط پایانی IdP را نشان می دهد - در این مورد، szn.cz کاربرانی که با نام تجاری seznam.cz آشنا هستند ممکن است دچار سردرگمی شوند و وقتی از آنها خواسته می شود با دامنه کمتر آشنا szn.cz در طول فرآیند ورود به سیستم وارد شوند، تردید کنند.

از Chrome 141، FedCM اجازه نمایش دامنه ای متفاوت از دامنه ای که اجرای IdP را میزبانی می کند، نمی دهد. این محدودیت یک انتخاب طراحی عمدی است که برای اطمینان از شفافیت برای کاربر در نظر گرفته شده است. با این حال، تیم FedCM چالش‌هایی را که این محدودیت ممکن است ایجاد کند تشخیص می‌دهد و در حال بحث در مورد تنظیمات بالقوه است.

تاثیر

با FedCM API، Seznam اکنون می‌تواند جریان‌های مجوز تک ضربه را برای کاربران شرکای خود فراهم کند. آنها مزایای ارائه شده توسط UX FedCM را در مقایسه با سایر روش های احراز هویت برجسته کردند.

در حالی که Seznam به افزایش قابل توجهی در تعامل کاربر در وب‌سایت‌هایی که به ورود به سیستم FedCM منتقل شده‌اند اشاره کرد، آنها تجزیه و تحلیل جامعی برای جدا کردن تأثیر مستقیم دقیق از سایر عوامل انجام ندادند. قبل از ادغام FedCM، پیاده سازی امکان پرداخت مهمان را با استفاده از ایمیل های هش شده برای شناسایی کاربر فراهم می کرد. چالش انجام چنین تحلیلی این بود که تخمین بزنیم آیا تبدیل کاربر را می‌توان به FedCM نسبت داد، یا اینکه آیا کاربر با استفاده از پرداخت مهمان، خرید خود را تکمیل می‌کرد. فرضیه Seznam نشان می دهد که سهولت استفاده بهبود یافته توسط FedCM ممکن است به این نرخ تبدیل بالاتر کمک کرده باشد.

نتیجه گیری

Seznam با موفقیت FedCM را پیاده سازی کرد و یک جریان مجوز جایگزین را در کنار راه حل OAuth موجود خود ارائه کرد. در حالی که توسعه‌دهندگان Seznam با برخی چالش‌های مربوط به پشتیبانی از ارائه‌دهنده هویت، تنظیمات DNS خصوصی، سفارشی‌سازی متن افشا، اعتبارسنجی مبدأ طرف و نمایش دامنه رو به روی کاربر مواجه بودند، API از زمان اجرای آن‌ها به بلوغ رسیده است. تیم FedCM بازخورد Seznam و دیگر پذیرندگان اولیه را در خود جای داده است که به ابزارهای بهتری برای حل این چالش ها اجازه می دهد. به عنوان گام بعدی، Seznam قصد دارد پشتیبانی FedCM را برای چندین ارائه دهنده هویت اجرا کند.