تمت ترجمة هذه الصفحة بواسطة Cloud Translation API‏.

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

Maud Nalpas

المشكلة التي تواجهها "طلبات المصدر ذات الصلة"

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

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

يتم ملء Chrome تلقائيًا على كلا الموقعَين الإلكترونيَين. — بفضل "طلبات المصدر ذات الصلة"، يمكن للمستخدمين استخدام بيانات اعتماد مفتاح المرور نفسها في ror-1 وror-2. وسيقوم Chrome أيضًا بالملء التلقائي لبيانات الاعتماد.

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

يمكنك الاطّلاع على ملف ./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: عرض ملف .well-known/webauthn JSON في site-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: مادة العرض الرقمية الروابط: مزيد من المعلومات على إتاحة ميزة "روابط مواد العرض الرقمية"
في Safari: النطاقات المرتبطة:

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

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

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

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