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

Maud Nalpas
Maud Nalpas

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

يتم تحديد ذلك في معرّف الطرف الموثوق به (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.
يملؤ Chrome البيانات تلقائيًا في كلا الموقعَين الإلكترونيَين.
بفضل طلبات المصادر ذات الصلة، يمكن للمستخدمين استخدام بيانات اعتماد مفتاح المرور نفسها في ror-1 وror-2. سيملؤها Chrome تلقائيًا أيضًا.

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

الخطوة 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
رسالة خطأ في Chrome عند إنشاء بيانات الاعتماد يتم طرح هذا الخطأ إذا تعذّر العثور على ملف ‎.well-known/webauthn على الرابط ‎https://{RP ID}/.well-known/webauthn.
نافذة منبثقة لرسالة خطأ في Chrome
رسالة الخطأ في Chrome عند إنشاء بيانات الاعتماد يتم طرح هذا الخطأ إذا كان بالإمكان العثور على ملف ‎.well-known/webauthn، ولكنّه لا يسرد المصدر الذي تحاول إنشاء بيانات اعتماد منه.

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

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

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

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

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

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

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