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

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

الملفات الشخصية المستهدَفة: الشركات التي تستفيد من FedCM

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

Seznam

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

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

الحافز

استند قرار Seznam بتنفيذ FedCM إلى العديد من المزايا التي أدركتها الشركة:

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

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

نفّذت شركة Seznam واجهة 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'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() متعددة.

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

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

ومع ذلك، يؤدي هذا الإعداد إلى حدوث مشكلة، لأنّه يجب عرض ملف 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: مثال على ملف ‎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 رسالة ثابتة للمستخدم تفيد بأنّه تتم مشاركة بيانات معيّنة مع RP، وهي عادةً صورة الملف الشخصي للمستخدم واسمه وعنوان بريده الإلكتروني.

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

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

يجب أن يتحقّق خادم موفِّر الهوية من عنوان 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 مع عدّة مقدّمي خدمات تحديد الهوية.