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

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 السماح للمصادر الإضافية باستخدامه كمعرّف طرف معتمِد، عليه عرض الملف التالي على 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.

المتصفحات المتوافقة

تتوافق "طلبات المصدر ذات الصلة" مع متصفّحَي Chrome وSafari. اعتبارًا من يناير 2026، لا يزال Firefox يدرس هذه الميزة. يمكنك تتبُّع حالتها في مشكلة موقف معايير Mozilla.

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

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

عرض توضيحي

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

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

• يمكنك إنشاء مفتاح مرور والمصادقة باستخدام هذا المفتاح بنجاح على ror-2، حتى إذا كان معرّف الطرف المعتمِد هو ror-1 (وليس ror-2).
• بعد إنشاء مفتاح مرور على ror-1 أو ror-2، يمكنك المصادقة باستخدام هذا المفتاح على كل من ror-1 وror-2. بما أنّ ror-2 يحدّد ror-1 كمعرّف طرف معتمِد، فإنّ إجراء طلب لإنشاء مفتاح مرور أو المصادقة باستخدام هذا المفتاح من أي من هذه المواقع الإلكترونية هو نفسه إجراء الطلب على ror-1. معرّف الطرف المعتمِد هو العنصر الوحيد الذي يربط الطلب بمصدر معيّن.
• بعد إنشاء مفتاح مرور على ror-1 أو ror-2، يمكن لـ Chrome ملء هذا المفتاح تلقائيًا على كل من ror-1 وror-2.
• ستكون بيانات الاعتماد التي يتم إنشاؤها على أي من هذه المواقع الإلكترونية لها معرّف طرف معتمِد هو 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 باستخدامه كمعرّف طرف معتمِد. لإجراء ذلك، أنشئ ملف webauthn JSON:

{
    "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);
});

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

الخطوة 4: تحديد معرّف الطرف المعتمِد في site-2

في قاعدة الرموز البرمجية لـ site-2، اضبط site-1.com كمعرّف طرف معتمِد في كل مكان مطلوب:

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

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

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

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

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

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

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

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

دور مديري بيانات الاعتماد ووكلاء المستخدمين

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