المشكلة التي تحلّها طلبات المصدر ذات الصلة
ترتبط مفاتيح المرور بموقع إلكتروني معيّن ولا يمكن استخدامها إلا لتسجيل الدخول إلى الموقع الإلكتروني الذي تم إنشاؤها له.
يتم تحديد ذلك في معرّف الطرف الموثوق به (RP ID)، والذي يمكن أن يكون 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: إعداد ملف JSON .well-known/webauthn في الموقع الإلكتروني 1
أولاً، عليك ضبط site-1.com
بحيث يسمح لـ site-2.com
باستخدامه كأحد
أرقام تعريف موفِّري الخدمات. لإجراء ذلك، أنشئ ملف JSON لبروتوكول webauthn:
{
"origins": [
"https://site-2.com"
]
}
يجب أن يحتوي ملف JSON على مصادر رئيسية مُسمّاة تكون قيمتها مصفوفة من سلسلة واحدة أو أكثر تحتوي على مصادر ويب.
قيد مهم: 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 في الموقع الإلكتروني 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 نظامًا مختلفًا.
دور مدراء بيانات الاعتماد ووكلاء المستخدمين
يتجاوز هذا النطاق نطاق عملك كمطوّر مواقع إلكترونية، ولكن يُرجى العلم أنّه في المدّة الطويلة، يجب ألّا يكون رقم تعريف مقدّم الخدمة هو مفهوم يظهر للمستخدم في وكيل المستخدم أو مدير بيانات الاعتماد الذي يستخدمه المستخدمون. بدلاً من ذلك، يجب أن يعرض وكلاء المستخدمين ومديرو بيانات الاعتماد للمستخدمين أماكن استخدام بيانات الاعتماد الخاصة بهم. سيستغرق تنفيذ هذا التغيير بعض الوقت. يمكن أن يكون الحل المؤقت هو عرض كل من الموقع الإلكتروني الحالي وموقع التسجيل الأصلي.