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

Natalia Markoborodova

منتشر شده: ۸ سپتامبر ۲۰۲۵

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

شرکت‌هایی که از FedCM سود می‌برند

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

سزنام

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

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

انگیزه

سزنام به دلیل چندین مزیت شناخته شده، FedCM را پیاده‌سازی کرد:

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

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

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

تلاش برای پیاده‌سازی

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

چالش‌ها

سزنم، به عنوان یکی از اولین استفاده‌کنندگان، چالش‌های متعددی را شناسایی کرد و بازخورد ارزشمندی ارائه داد که به بلوغ API کمک کرد.

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

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

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

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

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

دی‌ان‌اس خصوصی

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

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

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

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

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

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

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

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

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

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

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

سزنام یک مورد خاص دارد: وقتی RP های شریکش در سزنام ثبت نام می‌کنند، داده‌های مبدا RP را درخواست نمی‌کند. این بدان معناست که مبدا RP قابل تأیید نیست.

یکپارچه‌سازی FedCM شرکت Seznam بر اساس یک راهکار OAuth موجود ساخته شده است. این راهکار، مسیر جایگزین اعتبارسنجی client_id و client_secret مربوط به RP را در پیش گرفته تا از ایمن ماندن راهکار بدون بررسی مبدا اطمینان حاصل کند.

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

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

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

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

تأثیر

با API فِدسی‌ام، سِزنام اکنون می‌تواند جریان‌های احراز هویت تک‌لمسی را برای کاربران شریک فراهم کند. این امر مزایای تجربه کاربری فِدسی‌ام را در مقایسه با سایر روش‌های احراز هویت برجسته کرد.

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

نتیجه‌گیری

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