ترتبط مفاتيح المرور بموقع إلكتروني محدّد، ولا يمكن استخدامها إلا لتسجيل الدخول إلى الموقع الإلكتروني الذي تم إنشاؤها له.
يتم تحديد ذلك في معرّف الجهة المعتمِدة (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 كمعرّف RP، سيتعرّف المتصفّح على معرّف RP لا يتطابق مع المصدر الذي أرسل الطلب. إذا كان المتصفّح يتيح طلبات المصدر ذي الصلة، سيبحث أولاً عن ملف 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 كمعرّف 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 في الموقع الإلكتروني 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"، استخدِم روابط مواد العرض الرقمية . يستخدم Safari نظامًا مختلفًا.
دور مدراء بيانات الاعتماد وبرامج وكيل المستخدم
هذا الإجراء يتجاوز نطاق عملك كمطوّر مواقع إلكترونية، ولكن تجدر الإشارة إلى أنّه على المدى الطويل، يجب ألا يكون معرّف الجهة الاعتمادية مفهومًا مرئيًا للمستخدم في وكيل المستخدم أو أداة إدارة بيانات الاعتماد التي يستخدمها المستخدمون. بدلاً من ذلك، يجب أن تعرض وكلاء المستخدمين ومدراء بيانات الاعتماد للمستخدمين الأماكن التي تم فيها استخدام بيانات الاعتماد. سيستغرق تنفيذ هذا التغيير بعض الوقت. يمكنك كحلّ مؤقت عرض الموقع الإلكتروني الحالي وموقع التسجيل الأصلي.