السماح بإعادة استخدام مفاتيح المرور في جميع مواقعك الإلكترونية من خلال "طلبات المصدر ذات الصلة"

Maud Nalpas

ترتبط مفاتيح المرور بموقع إلكتروني محدّد، ولا يمكن استخدامها إلا لتسجيل الدخول إلى الموقع الإلكتروني الذي تم إنشاء المفتاح له.

يتم تحديد ذلك في معرّف الجهة المعتمِدة (RP ID)، والذي قد يكون www.example.com أو example.com لمفاتيح المرور التي تم إنشاؤها لنطاق example.com.

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

• المواقع الإلكترونية التي تتضمّن نطاقات متعدّدة: لا يمكن للمستخدمين استخدام مفتاح المرور نفسه لتسجيل الدخول على نطاقات مختلفة خاصة ببلدان معيّنة (مثل example.com وexample.co.uk) تديرها الشركة نفسها.
• النطاقات المرتبطة بعلامة تجارية: لا يمكن للمستخدمين استخدام بيانات الاعتماد نفسها على نطاقات مختلفة تستخدمها علامة تجارية واحدة (مثل acme.com وacmerewards.com).
• التطبيقات المتوافقة مع الأجهزة الجوّالة: غالبًا ما لا يكون للتطبيقات المتوافقة مع الأجهزة الجوّالة نطاق خاص بها، ما يجعل إدارة بيانات الاعتماد أمرًا صعبًا.

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

الحل

باستخدام طلبات المصدر المرتبط، يمكن للموقع الإلكتروني تحديد المصادر المسموح لها باستخدام معرّف الطرف المعتمِد.

يتيح ذلك للمستخدمين إعادة استخدام مفتاح المرور نفسه على مواقع إلكترونية متعدّدة تديرها.

لاستخدام طلبات المصدر ذات الصلة، عليك عرض ملف JSON خاص على عنوان URL محدّد https://{RP ID}/.well-known/webauthn. إذا أراد example.com السماح للمصادر الإضافية باستخدامه كمعرّف RP، عليه عرض الملف التالي على https://example.com/.well-known/webauthn:

{
  "origins": [
    "https://example.co.uk",
    "https://example.de",
    "https://example-rewards.com"
  ]
}

في المرة التالية التي يطلب فيها أي من هذه المواقع الإلكترونية إنشاء مفتاح مرور (navigator.credentials.create) أو إجراء مصادقة (navigator.credentials.get) باستخدام example.com كمعرّف طرف معتمد، سيتعرّف المتصفّح على معرّف طرف معتمد لا يتطابق مع المصدر الذي أرسل الطلب. إذا كان المتصفّح يتيح طلبات المصدر ذي الصلة، سيبحث أولاً عن ملف webauthn في https://{RP ID}/.well-known/webauthn. إذا كان الملف متوفّرًا، يتحقّق المتصفّح مما إذا كان المصدر الذي يرسل الطلب مدرجًا في allowlist. إذا كان الأمر كذلك، سيتم الانتقال إلى خطوات إنشاء مفتاح المرور أو المصادقة.

إذا كان المتصفّح لا يتيح طلبات المصدر المرتبط، سيظهر الخطأ SecurityError.

دعم المتصفح

إعداد طلبات المصدر ذات الصلة

يستخدم العرض التوضيحي التالي موقعَين إلكترونيَين، https://ror-1.glitch.me وhttps://ror-2.glitch.me. ولتمكين المستخدمين من تسجيل الدخول باستخدام مفتاح المرور نفسه على كلا الموقعَين الإلكترونيَين، تستخدم هذه الميزة طلبات المنشأ المرتبط للسماح ror-2.glitch.me باستخدام ror-1.glitch.me كمعرّف RP.

عرض توضيحي

يستخدم https://ror-2.glitch.me طلبات المصدر ذي الصلة لاستخدام ror-1.glitch.me كمعرّف RP، لذا يستخدم كل من ror-1 وror-2 ror-1.glitch.me كمعرّف RP عند إنشاء مفتاح مرور أو المصادقة باستخدامه. لقد أنشأنا أيضًا قاعدة بيانات مشتركة لمفاتيح المرور على هذه المواقع الإلكترونية.

لاحظ تجربة المستخدم التالية:

• يمكنك إنشاء مفتاح مرور والمصادقة باستخدامه بنجاح على ror-2، حتى إذا كان معرّف الجهة الاعتمادية هو ror-1 (وليس ror-2).
• بعد إنشاء مفتاح مرور على ror-1 أو ror-2، يمكنك المصادقة باستخدام هذا المفتاح على كل من ror-1 وror-2. بما أنّ ror-2 يحدّد ror-1 كمعرّف RP، فإنّ تقديم طلب إنشاء مفتاح مرور أو مصادقة من أيّ من هذه المواقع الإلكترونية هو نفسه تقديم الطلب على ror-1. معرّف RP هو العنصر الوحيد الذي يربط الطلب بالمصدر.
• بعد إنشاء مفتاح مرور على ror-1 أو ror-2، يمكن أن يملأه Chrome تلقائيًا على كل من ror-1 وror-2.
• ستتضمّن بيانات الاعتماد التي يتم إنشاؤها على أي من هذه المواقع الإلكترونية معرّف RP بقيمة ror-1.

الاطّلاع على الرمز:

• يمكنك الاطّلاع على إعداد ملف ./well-known/webauthn في قاعدة رموز ror-1.
• اطّلِع على مواضع ورود RP_ID_ROR في قاعدة رموز ror-2.

الخطوة 1: تنفيذ قاعدة بيانات حسابات مشتركة

إذا كنت تريد أن يتمكّن المستخدمون من تسجيل الدخول باستخدام مفتاح المرور نفسه على site-1 وsite-2، عليك تنفيذ قاعدة بيانات حسابات مشترَكة بين هذين الموقعَين الإلكترونيَين.

الخطوة 2: إعداد ملف JSON الخاص بـ ‎ .well-known/webauthn في site-1

أولاً، اضبط site-1.com بحيث يسمح لـ site-2.com باستخدامه كرقم تعريف RP. لإجراء ذلك، أنشِئ ملف JSON الخاص بـ WebAuthn:

{
    "origins": [
        "https://site-2.com"
    ]
}

يجب أن يحتوي عنصر JSON على مفتاح باسم origins تكون قيمته مصفوفة من سلسلة واحدة أو أكثر تحتوي على مصادر الويب.

قيد مهم: 5 تصنيفات كحد أقصى

ستتم معالجة كل عنصر من هذه القائمة لاستخراج التصنيف eTLD + 1. على سبيل المثال، تكون تصنيفات eTLD + 1 لكل من example.co.uk وexample.de هي example. لكنّ تصنيف eTLD + 1 الخاص بـ example-rewards.com هو example-rewards. في Chrome، الحد الأقصى لعدد التصنيفات هو 5.

الخطوة 3: عرض ملف JSON الخاص بـ ‎ .well-known/webauthn في site-1

بعد ذلك، اعرض ملف JSON ضمن site-1.com/.well-known/webauthn.

على سبيل المثال، في Express:

app.get("/.well-known/webauthn", (req, res) => {
  const origins = {
    origins: ["https://site-2.com"],
  };
  return res.json(origins);
});

في هذا المثال، نستخدم res.json السريع، الذي يضبط content-type ('application/json') الصحيح تلقائيًا.

الخطوة 4: تحديد معرّف الجهة الاعتماد في الموقع الإلكتروني 2

في قاعدة رموز site-2، اضبط site-1.com كمعرّف الطرف المستند إلى سياسة الخصوصية في كل مكان مطلوب:

• عند إنشاء بيانات الاعتماد:
  • اضبط site-1.com كمعرّف RP في بيانات إنشاء بيانات الاعتماد options التي يتم تمريرها إلى navigator.credentials.create في طلب الواجهة الأمامية، ويتم إنشاؤها عادةً من جهة الخادم.
  • اضبط site-1.com كمعرّف RP المتوقّع، لأنّك ستجري عمليات التحقّق من بيانات الاعتماد قبل حفظها في قاعدة البيانات.
• بعد المصادقة:
  • اضبط site-1.com كمعرّف RP في بيانات المصادقة options التي يتم تمريرها إلى طلب الواجهة الأمامية navigator.credentials.get، ويتم إنشاؤها عادةً من جهة الخادم.
  • اضبط site-1.com كمعرّف RP المتوقّع الذي سيتم التحقّق منه على الخادم، وذلك عند تنفيذ عمليات التحقّق من بيانات الاعتماد قبل مصادقة المستخدم.

تحديد المشاكل وحلّها

اعتبارات أخرى

مشاركة مفاتيح المرور على المواقع الإلكترونية وتطبيقات الأجهزة الجوّالة

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

• في Chrome: روابط تنقل إلى مواد عرض رقمية يمكنك الاطّلاع على مزيد من المعلومات في مقالة إضافة دعم لروابط مواد العرض الرقمية.
• في Safari: النطاقات المرتبطة

مشاركة كلمات المرور على مواقع إلكترونية مختلفة

تتيح طلبات المصدر ذي الصلة للمستخدمين إعادة استخدام مفتاح مرور على مواقع إلكترونية مختلفة. تختلف حلول مشاركة كلمات المرور على المواقع الإلكترونية بين تطبيقات إدارة كلمات المرور. بالنسبة إلى "مدير كلمات المرور في Google"، استخدِم Digital Asset Links . يستخدم Safari نظامًا مختلفًا.

دور أدوات إدارة بيانات الاعتماد وبرامج وكيل المستخدم

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