مصادقة المستخدمين بسلاسة وبطريقة تحافظ على الخصوصية باستخدام FedCM: نهج Seznam

Natalia Markoborodova
Natalia Markoborodova

تاريخ النشر: 8 سبتمبر 2025

يدرك قادة الصناعة في مختلف القطاعات أهمية حماية الخصوصية مع توفير تجربة رائعة للمستخدمين. تلتزم شركة Seznam بتقديم تجربة استخدام وخصوصية لا مثيل لهما، وقد نجحت في دمج واجهة برمجة التطبيقات Federated Credential Management (FedCM).

الشركات التي تستفيد من FedCM

تدمج المؤسسات في مختلف المجالات واجهة FedCM مع حلولها. بما أنّ FedCM مصمَّمة لإدارة الهوية الموحّدة، فإنّ موفّري الهوية هم المستفيدون الأساسيون منها. ويتم استخدامها لتقديم تجربة تسجيل دخول محسّنة. يحدّد مقدّمو خدمات التجارة الإلكترونية ومقدّمو خدمات الدفع، الذين يعمل العديد منهم أيضًا كموفّري هوية، فرصًا لتحسين تجربة المستخدم من خلال FedCM.

Seznam

‫Seznam هي شركة تكنولوجيا أوروبية ومزوّد خدمة هوية يصل إلى% 90 من سكان التشيك. وهي بمثابة مركز اجتماعي ومعرفي ومحتوى. اعتمدت شركة Seznam واجهة برمجة التطبيقات FedCM للسماح لعملاء المتاجر الإلكترونية التي تعمل على منصات شركائها بتسجيل الدخول باستخدام حساباتهم على Seznam.

مربّع حوار FedCM على eshop.starkl.com يطلب من المستخدم تسجيل الدخول باستخدام حسابه على Seznam
مربع حوار FedCM يطلب من المستخدم تسجيل الدخول باستخدام Seznam على موقع إلكتروني تابع لأحد الشركاء

باستخدام FedCM، حقّقت شركة Seznam زيادة كبيرة في معدّلات تسجيل دخول المستخدمين على شبكات الشركاء، وتحسينًا في تجربة المستخدم، وتدفّقًا ثابتًا للهوية بغض النظر عن توفّر ملفات تعريف الارتباط التابعة لجهات خارجية.

الحافز

اختارت شركة Seznam تنفيذ FedCM بسبب العديد من المزايا المعروفة:

  • تم تصميم FedCM مع مراعاة المستخدم النهائي، ما يمنح المستخدمين التحكّم في المعلومات المقدَّمة إلى موفِّر الهوية. يتوافق ذلك مع رؤية Seznam المتمثلة في توفير بيئة آمنة وخاصة للمستخدمين.
  • ‫FedCM هي ميزة مضمّنة في المتصفّح ومتوافقة مع تجربة تسجيل الدخول الحالية في Seznam التي تستخدم معيار OAuth 2.0.
  • ‫FedCM هي طريقة متّبعة في اتحاد الهوية تركّز على الخصوصية. على سبيل المثال، لا تتم مشاركة زيارة المستخدم إلى الطرف المعتمِد (RP) إلا مع موفِّر الهوية (IdP) إذا سجّل المستخدم الدخول. يتوافق ذلك مع وجهة نظر Seznam بشأن الأعمال التجارية المستدامة.

تفاصيل التنفيذ

نفّذت شركة Seznam واجهة FedCM كطبقة فوق حلّ OAuth الحالي. في هذه البنية، ينقل مسار FedCM رمز تفويض OAuth بشكل آمن من موفّر الهوية إلى الأطراف الاعتمادية.

مسار FedCM، الذي يعرض رمز FedCM المميز الذي تم تبادله برمز تفويض OAuth على جهة موفّر خدمة تحديد الهوية
تم دمج مسار FedCM مع OAuth. اطّلِع على رمز الرسم البياني.

الجهد المطلوب لتنفيذ التغيير

وجدت شركة Seznam أنّ عملية تنفيذ FedCM مباشرة ومتوافقة مع نهجها الحالي. استغرق البحث وتنفيذ واجهة برمجة التطبيقات شهرًا وتطلّب مشاركة مطوّرَين. استغرق طرح FedCM أقل من شهرين. كانت العملية متكررة، وتم تخصيص وقت كبير لدراسة واجهة برمجة التطبيقات.

التحديات

بصفتها من أوائل المستخدمين، حدّدت شركة Seznam العديد من التحديات وقدّمت ملاحظات قيّمة ساعدت في تطوير واجهة برمجة التطبيقات.

إتاحة استخدام عدة موفّري خدمات تعريف الهوية

كانت شركة Seznam مهتمة بإمكانية استخدام واجهة برمجة التطبيقات FedCM API مع عدة موفّري هوية. من خلال هذه الميزة، كان الهدف هو السماح للمستخدمين بالاختيار بين حسابات Seznam أو Google على منصات شركاء الترويج. ومع ذلك، عندما بدأت Seznam في تنفيذ FedCM، كانت الميزة في مرحلة التنفيذ المبكر، وكان على المطوّرين الاشتراك في تجربة المصدر واستخدام رمز مميّز لتفعيل الميزة للمستخدمين. لهذا السبب، اختارت Seznam الانتظار إلى أن يتم طرح الميزة في الإصدار الثابت من Chrome.

تتوفّر هذه الميزة بدءًا من الإصدار 136 من Chrome، ويمكن للمطوّرين ضبط إعدادات التوافق مع العديد من موفّري خدمات تحديد الهوية. على سبيل المثال، لدعم كل من موفِّرَي الهوية Seznam وGoogle، يمكن لموفِّر الهوية تضمين الموفِّرَين في طلب get() واحد، ويمكن لطرف الاعتماد إجراء ذلك بشكل مستقل:

  // 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',
          },
        ],
      },
    });

تشير شركة Seznam إلى أنّ هذه الميزة ستكون جزءًا من حلّها. بالإضافة إلى ذلك، يعمل فريق FedCM على تنفيذ إمكانية استخدام حِزم SDK متعددة، مع إتاحة عمليات استدعاء متعددة get().

نظام أسماء النطاقات الخاص

واجهت شركة Seznam مشكلة متعلّقة بإعدادات الشبكة خلال مرحلة الاختبار. كان خادم موفّر خدمة الهوية التجريبي يقع ضمن شبكة خاصة، ولا يمكن الوصول إليه إلا من خلال نظام أسماء نطاقات خاص. يتم استخدام هذا الإعداد عادةً في بيئات الاختبار والتطوير الداخلي قبل إتاحة التطبيق للجميع.

ومع ذلك، يؤدي هذا الإعداد إلى حدوث مشكلة: بما أنّه يجب عرض ملف 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 في Chrome. عند تفعيل هذه العلامة، يتخطّى المتصفّح جلب ملف well-known لأغراض الاختبار. كيفية تفعيل ميزات تجريبية في Chrome

بيان الإفصاح المخصّص عن المعلومات

أرادت شركة Seznam أيضًا تضمين معلومات إضافية إلى جانب تصميم واجهة المستخدم الأولية لواجهة FedCM. يعرض مربّع الحوار العادي في FedCM رسالة ثابتة للمستخدم تفيد بأنّه تتم مشاركة بيانات معيّنة مع الجهة المقدّمة للخدمة، وهي عادةً صورة الملف الشخصي للمستخدم واسمه وعنوان بريده الإلكتروني.

أخذ فريق FedCM الملاحظات بعين الاعتبار ووسّع نطاق واجهة برمجة التطبيقات لإتاحة تخصيص بيان الإفصاح المعروض للمستخدم. على سبيل المثال، باستخدام ميزة "المتابعة"، يمكن لموفِّر الهوية إعادة توجيه المستخدم إلى صفحة مخصّصة لطلب معلومات أو أذونات إضافية. تتيح ميزتا المَعلمات المخصّصة والحقول، المتوفّرتان بدءًا من الإصدار 132 من Chrome، المزيد من التخصيص.

صفحة موفّر خدمة تحديد الهوية تعرض رسالة تفيد بأنّه على المستخدم منح أذونات إضافية لمواصلة عملية الاشتراك في FedCM، مثل عرض ملفات Drive وأحداث التقويم وتنزيلها.
يمكن للمستخدم مراجعة الأذونات الإضافية التي يمرّرها الطرف المعتمد على RP ومنحها إلى نقطة نهاية تأكيد الهوية باستخدام واجهة برمجة التطبيقات`Parameters`.

التحقّق من صحة مصدر الجهة المعتمدة

يجب أن يتحقّق خادم موفِّر الهوية من عنوان HTTP Origin في طلب FedCM وارد للتأكّد من أنّ الطلب يتطابق مع المصدر الذي سجّله الطرف الاعتماد مسبقًا لدى موفِّر الهوية. يضمن ذلك أنّ طلب تأكيد الهوية في FedCM يأتي من جهة معتمدة، وليس من مهاجم يستخدم client_id.

لدى Seznam حالة استخدام خاصة: عندما تسجّل منصات نشر تابعة لشركاء في Seznam، لا تطلب المنصة بيانات المصدر الخاصة بمنصة النشر. وهذا يعني أنّه لا يمكن التحقّق من مصدر RP.

تستند عملية دمج FedCM في Seznam إلى أحد حلول OAuth الحالية. اتّبعت هذه الطريقة مسارًا بديلاً للتحقّق من صحة كل من client_id وclient_secret في RP لضمان بقاء الحلّ آمنًا بدون التحقّق من المصدر.

نطاق موفِّر الهوية الذي يظهر للمستخدم

تعمل البنية الأساسية لمصادقة المستخدم في Seznam بشكل أساسي على النطاق szn.cz، حيث تتم استضافة نقاط نهاية موفِّر الهوية اللازمة لواجهة FedCM. ومع ذلك، فإنّ هوية الشركة الرئيسية والنطاق الذي يتعرّف المستخدمون على خدماتها ويثقون بها على نطاق واسع هما seznam.cz.

يعرض مربّع حوار FedCM نطاق المصدر الفعلي لنقاط نهاية موفِّر الهوية: szn.cz. قد يشعر المستخدمون الذين يعرفون العلامة التجارية seznam.cz بالارتباك ويترددون عند مطالبتهم بتسجيل الدخول باستخدام النطاق szn.cz الأقل شيوعًا أثناء عملية تسجيل الدخول.

اعتبارًا من الإصدار 141 من Chrome، لا تسمح FedCM بعرض نطاق مختلف عن النطاق الذي يستضيف تنفيذ موفّر خدمة الهوية. هذا القيد هو خيار تصميم متعمّد يهدف إلى ضمان الشفافية للمستخدم. ومع ذلك، يدرك فريق FedCM التحديات التي قد يفرضها هذا القيد، وهو يناقش التعديلات المحتملة.

التأثير

باستخدام FedCM API، يمكن لشركة Seznam الآن توفير عمليات تفويض بنقرة واحدة للمستخدمين الشركاء. وقد سلّط الضوء على مزايا تجربة المستخدم في FedCM مقارنةً بطُرق المصادقة الأخرى.

على الرغم من أنّ Seznam لاحظت زيادة كبيرة في تفاعل المستخدمين على المواقع الإلكترونية التي انتقلت إلى تسجيل الدخول باستخدام FedCM، لم تُجرِ تحليلًا شاملاً لعزل التأثير المباشر الدقيق عن العوامل الأخرى. قبل دمج FedCM، كانت عملية التنفيذ تسمح بإتمام عمليات الدفع كضيف باستخدام عناوين البريد الإلكتروني المجزأة التي تمت الموافقة عليها لتحديد هوية المستخدم. كان التحدّي الذي يواجه إجراء مثل هذا التحليل هو تقدير ما إذا كان يمكن إرجاع إحالة المستخدم الناجحة إلى FedCM، أو ما إذا كان المستخدم سيُكمل عملية شراء باستخدام ميزة "الدفع كضيف". تشير فرضية Seznam إلى أنّ سهولة استخدام FedCM المحسّنة ربما ساهمت في ارتفاع معدّل الإحالات الناجحة هذا.

الخاتمة

نفّذت شركة Seznam واجهة FedCM API بنجاح، ما أتاح لها توفير مسار تفويض بديل إلى جانب حلّ OAuth الحالي. على الرغم من أنّ Seznam واجهت بعض التحديات المتعلّقة بتوافق موفّر الهوية وإعدادات نظام أسماء النطاقات الخاص وتخصيص نص الإفصاح والتحقّق من صحة مصدر الطرف المعتمِد وعرض النطاق للمستخدم، فقد تطوّرت واجهة برمجة التطبيقات منذ تنفيذها. أخذ فريق FedCM في الاعتبار الملاحظات الواردة من Seznam وغيرهم من المستخدمين الأوائل، ما أتاح توفير أدوات أفضل لمواجهة هذه التحديات. كخطوة تالية، تخطّط شركة Seznam لتنفيذ ميزة FedCM التي تتيح استخدام عدّة موفّري هوية.