المشكلة التي تحلّها طلبات المصدر ذات الصلة
ترتبط مفاتيح المرور بموقع إلكتروني معيّن ولا يمكن استخدامها إلا لتسجيل الدخول إلى الموقع الإلكتروني الذي تم إنشاؤها له.
ويتم تحديد ذلك في رقم تعريف الجهة الموثوقة (رقم تعريف الجهة المحظورة)، والذي يمكن أن يكون www.example.com أو example.com لمفاتيح المرور التي تم إنشاؤها لنطاق example.com.
على الرغم من أنّ أرقام تعريف موفّري خدمات الربط تمنع استخدام مفاتيح المرور كمستند اعتماد واحد لتأكيد الهوية في كل مكان، إلا أنّها تتسبّب في مشاكل في ما يلي:
- المواقع الإلكترونية التي تتضمّن نطاقات متعددة: لا يمكن للمستخدمين استخدام مفتاح المرور نفسه لتسجيل الدخول على نطاقات مختلفة خاصة ببلدان مختلفة (مثل
example.comوexample.co.uk) تديرها الشركة نفسها. - النطاقات التي تحمل علامة تجارية: لا يمكن للمستخدمين استخدام بيانات الاعتماد نفسها في
نطاقات مختلفة تستخدمها علامة تجارية واحدة (على سبيل المثال،
acme.comوacmerewards.com). - تطبيقات الأجهزة الجوّالة: لا تحتوي تطبيقات الأجهزة الجوّالة غالبًا على نطاقها الخاص، ما يجعل إدارة بيانات الاعتماد صعبة.
هناك حلول بديلة تستند إلى عملية ربط الهوية، وأخرى تستند إلى استخدام علامات div، ولكنّها غير ملائمة في بعض الحالات. توفّر طلبات المصادر ذات الصلة حلّاً.
الحل
باستخدام طلبات المصادر ذات الصلة، يمكن لموقع إلكتروني تحديد المصادر المسموح لها باستخدام رقم تعريف طلب المصدر.
يتيح ذلك للمستخدمين إعادة استخدام مفتاح المرور نفسه على مستوى مواقع إلكترونية متعددة تديرها.
لاستخدام "طلبات المصدر ذي الصلة"، يجب عرض ملف 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. في حال توفّر الملف، يتحقّق المتصفّح مما إذا كان المصدر الذي يقدّم الطلب مدرَجًا في القائمة المسموح بها في ذلك
الملف. وإذا كان الأمر كذلك، ينتقل إلى خطوات إنشاء مفتاح المرور أو المصادقة.
وإذا لم يكن المتصفّح متوافقًا مع "طلبات المصدر ذات الصلة"، يعرض الرمز SecurityError.
دعم المتصفح
- Chrome: متاح بدءًا من Chrome 128.
- Safari: متوافق مع الإصدار 3 من الإصدار التجريبي من نظام التشغيل macOS 15 والإصدار 3 من الإصدار التجريبي من نظام التشغيل iOS 18 على الأجهزة الجوّالة.
- Firefox: في انتظار تحديد موضع.
كيفية إعداد طلبات المصادر ذات الصلة
يستخدم العرض التوضيحي التالي مثالًا لموقعَين إلكترونيَّين، https://ror-1.glitch.me وhttps://ror-2.glitch.me.
لتمكين المستخدمين من تسجيل الدخول باستخدام مفتاح المرور نفسه على كلا الموقعَين الإلكترونيَين، يستخدم الموقع الإلكتروني 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. معرّف RP هو العنصر الوحيد الذي يربط الطلب بمصدر. - بعد إنشاء مفتاح مرور على "
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: إعداد ملف .well-known/webauthn JSON في site-1
أولاً، عليك ضبط site-1.com بحيث يسمح لـ site-2.com باستخدامه كأحد
أرقام تعريف موفِّري الخدمات. لإجراء ذلك، أنشِئ ملف webauthn بتنسيق JSON:
{
"origins": [
"https://site-2.com"
]
}
يجب أن يحتوي ملف JSON على مصادر رئيسية مُسمّاة تكون قيمتها مصفوفة من سلسلة واحدة أو أكثر تحتوي على مصادر ويب.
قيد مهم: 5 تصنيفات كحد أقصى
ستتم معالجة كل عنصر من هذه القائمة لاستخراج نطاق eTLD + تصنيف واحد.
على سبيل المثال، علامتا eTLD + 1 لكل من example.co.uk وexample.de هما
example. ولكنّ تصنيف eTLD + 1 لنطاق example-rewards.com هو example-rewards.
في Chrome، يبلغ الحد الأقصى لعدد التصنيفات 5.
الخطوة 3: عرض ملف JSON.well-known/webauthn في الموقع الإلكتروني 1
بعد ذلك، يمكنك عرض ملف JSON ضمن "site-1.com/.well-known/webauthn".
على سبيل المثال، في وضع "العرض السريع":
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كرقم تعريف الجهة المحظورة في عملية إنشاء بيانات الاعتمادoptionsالتي يتم تمريرها إلى استدعاء الواجهة الأماميةnavigator.credentials.createوالتي يتم إنشاؤها عادةً من جهة الخادم. - اضبط
site-1.comعلى أنّه معرّف مقدّم الخدمة المتوقّع، أثناء تنفيذ عمليات التحقّق من بيانات الاعتماد قبل حفظها في قاعدة بياناتك.
- عليك ضبط
- بعد المصادقة:
- اضبط
site-1.comعلى أنّه معرّف مقدّم الخدمة فيoptionsمصادقة التي يتم تمريرها إلى طلب الواجهة الأماميةnavigator.credentials.get، والتي يتم عادةً إنشاؤها من جهة الخادم. - اضبط
site-1.comعلى أنّه معرّف مقدَّر لموفّر الهوية ليتم التحقّق منه على الخادم، أثناء تنفيذ عمليات التحقّق من بيانات الاعتماد قبل مصادقة المستخدم.
- اضبط
تحديد المشاكل وحلّها
اعتبارات أخرى
مشاركة مفاتيح المرور على جميع المواقع الإلكترونية والتطبيقات المتوافقة مع الأجهزة الجوّالة
تسمح طلبات المصدر ذات الصلة للمستخدمين بإعادة استخدام مفتاح مرور على مواقع متعددة. للسماح للمستخدمين بإعادة استخدام مفتاح مرور على موقع إلكتروني وتطبيق متوافق مع الأجهزة الجوّالة، استخدِم الأساليب التالية:
- في Chrome: روابط تنقل إلى مواد عرض رقمية . اطّلِع على مزيد من المعلومات على الرابط إتاحة روابط مواد العرض الرقمية.
- في Safari: النطاقات المرتبطة.
مشاركة كلمات المرور على جميع المواقع الإلكترونية
تسمح طلبات المصدر ذات الصلة للمستخدمين بإعادة استخدام مفتاح مرور على جميع المواقع الإلكترونية. تختلف حلول مشاركة كلمات المرور على مستوى المواقع الإلكترونية من خدمة إلى أخرى. بالنسبة إلى "مدير كلمات المرور في Google"، استخدِم روابط مواد العرض الرقمية. يستخدم Safari نظامًا مختلفًا.
دور مدراء بيانات الاعتماد ووكلاء المستخدمين
يتجاوز ذلك نطاق عملك كمطوّر مواقع إلكترونية، ولكن يُرجى العِلم أنّه في المدّة الطويلة، يجب ألّا يكون رقم تعريف مقدّم طلب المصادقة مفهومًا يظهر للمستخدم في وكيل المستخدم أو في أداة إدارة بيانات الاعتماد التي يستخدمها المستخدمون. بدلاً من ذلك، يجب أن يعرض وكلاء المستخدمين ومديرو بيانات الاعتماد للمستخدمين أماكن استخدام بيانات الاعتماد الخاصة بهم. سيستغرق تنفيذ هذا التغيير بعض الوقت. يمكن أن يكون الحل المؤقت هو عرض كل من الموقع الإلكتروني الحالي وموقع التسجيل الأصلي.