الأصول المرتبطة في WebAuthn: دليل استخدام مفاتيح المرور عبر النطاقات

تُعد مفاتيح المرور (Passkeys) المعيار الجديد للمصادقة الآمنة وسهلة الاستخدام. بالاعتماد على معايير FIDO/WebAuthn، فإنها تستفيد من تشفير المفتاح العام لتوفر مقاومة متأصلة ضد التصيد الاحتيالي (phishing) وحشو بيانات الاعتماد (credential stuffing)، مما يحسن الوضع الأمني بشكل كبير مع تبسيط تجربة تسجيل الدخول للمستخدمين. بالنسبة للمؤسسات، يترجم هذا إلى فوائد تجارية ملموسة: انخفاض التكاليف التشغيلية الناتجة عن إعادة تعيين كلمات المرور والرسائل النصية القصيرة لكلمات المرور لمرة واحدة (SMS OTPs)، وتخفيف المخاطر المالية الناجمة عن الاحتيال للاستيلاء على الحسابات، وزيادة الإيرادات من خلال معدلات تحويل أعلى.

ومع ذلك، فإن إحدى أعظم نقاط القوة الأمنية في WebAuthn - وهي طبيعته الصارمة المرتبطة بالأصل (origin-bound) - تخلق تحديًا حقيقيًا كبيرًا للعلامات التجارية العالمية والشركات ذات البصمات الرقمية المتنوعة. بحكم التصميم، يكون مفتاح المرور الذي يتم إنشاؤه لنطاق ويب معين مقفلاً بشكل تشفيري على هذا النطاق، وهو مبدأ أساسي يمنع هجمات التصيد الاحتيالي. وفي حين أن هذه ميزة أمنية قوية، إلا أنها تؤدي إلى تجربة مستخدم مجزأة ومربكة عندما تعمل علامة تجارية واحدة عبر نطاقات متعددة.

أحد الأمثلة البارزة على هذا التحدي هو إعادة تسمية Twitter إلى X. فالمستخدم الذي أنشأ مفتاح مرور على twitter.com سيجده غير قابل للاستخدام على x.com، مما يجبر الشركة على تنفيذ عمليات إعادة توجيه مرهقة أو مطالبة المستخدمين بإعادة التسجيل، مما يخلق احتكاكًا يعيق التبني مباشرة. وهذه ليست مشكلة معزولة. تعمل الشركات الكبيرة مثل أمازون عبر العديد من نطاقات المستوى الأعلى لرموز البلدان (ccTLDs) مثل amazon.com و amazon.de و amazon.co.uk، وكلها تشترك في نظام حساب مستخدم مشترك. في عالم ما قبل مفاتيح المرور، كانت أدوات إدارة كلمات المرور تتعامل مع هذا التعقيد ببراعة، لكن السلوك الافتراضي لـ WebAuthn يتطلب مفتاح مرور منفصل لكل نطاق، مما يثير إحباط المستخدمين ويقوض وعد تسجيل الدخول السلس.

لحل هذا العائق الحاسم أمام التبني، قدم اتحاد شبكة الويب العالمية (W3C) ميزة جديدة في معيار WebAuthn: طلبات الأصول المرتبطة (Related Origin Requests - ROR). توفر هذه الآلية القوية طريقة موحدة وآمنة لمجموعة من النطاقات الموثوقة لمشاركة مفتاح مرور واحد، مما يخلق تجربة مصادقة موحدة وسلسة عبر النظام الرقمي الكامل للعلامة التجارية. يستكشف هذا التحليل العميق الأسس التقنية لـ ROR، ويقدم دليلاً عمليًا لتنفيذها، ويحلل آثارها الاستراتيجية على بنية المصادقة الحديثة.

يمثل إدخال ROR نضجًا كبيرًا في معيار WebAuthn. أعطت المواصفات الأولية الأولوية لإنشاء المبادئ الأساسية للتشفير والأمان، حيث كان الربط الصارم لبيانات الاعتماد بمعرف الطرف المعتمد (Relying Party) (rpID) حجر الزاوية في تصميمها المضاد لـ التصيد الاحتيالي. مع تحول عمليات النشر الواسعة النطاق في الشركات الكبرى مثل أمازون وجوجل إلى واقع، أصبح الاحتكاك العملي الناجم عن هذه الصرامة واضحًا. هذا الاحتكاك هو عائق مباشر لتحقيق تبني عالٍ من قبل المستخدمين، وهو المقياس النهائي للنجاح لأي مشروع لمفاتيح المرور. يعد تطوير ROR استجابة مباشرة لهذه الملاحظات من الشركات، مما يدل على تطور عملي للمعيار. إنه يقر بأنه لكي يحقق بروتوكول أمني نجاحًا واسع النطاق، يجب أن تتوسع قابليته للاستخدام لتستوعب الحقائق التجارية المعقدة واستراتيجيات العلامات التجارية للمؤسسات التي تنشره.

يجيب هذا الدليل الشامل على خمسة أسئلة حاسمة لتنفيذ طلبات الأصول المرتبطة في WebAuthn:

1. لماذا تفشل مفاتيح المرور عبر نطاقات متعددة؟ فهم نموذج الأمان المرتبط بالأصل في WebAuthn ونقاط الاحتكاك في العالم الحقيقي.
2. كيف تعمل طلبات الأصول المرتبطة تقنيًا؟ نظرة عميقة على تدفق التحقق في المتصفح وآلية URI .well-known.
3. ما هو المطلوب لتنفيذ ROR؟ تكوين خطوة بخطوة من جانب الخادم والعميل مع أمثلة عملية للكود.
4. متى يجب عليك اختيار ROR بدلاً من تسجيل الدخول الموحد (federated login)؟ إطار عمل لاتخاذ القرارات الاستراتيجية يقارن ROR بأساليب OIDC/SAML.
5. كيف تتعامل مع توافق المتصفحات والاعتبارات الأمنية؟ مصفوفة الدعم الحالية وأفضل الممارسات الأمنية.

لمزيد من التفاصيل الفنية، راجع الشرح الرسمي لطلبات الأصول المرتبطة في WebAuthn.

لتقدير أناقة حل طلبات الأصول المرتبطة بشكل كامل، من الضروري أولاً فهم المفاهيم التقنية الأساسية التي تستلزم وجوده: سياسة نفس الأصل (Same-Origin Policy) على الويب وقواعد تحديد نطاق معرّف الطرف المعتمد (rpID) في WebAuthn. هذه الآليات أساسية لأمان الويب ولكنها تخلق نفس الاحتكاك الذي صُمم ROR للتخفيف منه.

"أصل" الويب هو مفهوم أمني حاسم يُعرَّف بالمزيج الفريد من البروتوكول (مثل https)، والنطاق (مثل app.example.com)، والمنفذ (مثل 443) الذي يُقدم منه المحتوى. سياسة نفس الأصل (Same-Origin Policy) هي آلية أمنية يفرضها المتصفح تقيد كيفية تفاعل نص برمجي (script) تم تحميله من أصل واحد مع مورد من أصل آخر. وهي عنصر مهم في أمان الويب، حيث تعزل بشكل فعال المستندات التي قد تكون ضارة وتمنع موقعًا إلكترونيًا احتياليًا، على سبيل المثال، من قراءة البيانات الحساسة من جلسة بريد إلكتروني مصادق عليها للمستخدم في علامة تبويب أخرى.

في نظام WebAuthn، "الطرف المعتمد" (RP) هو موقع الويب أو التطبيق الذي يحاول المستخدم المصادقة معه. يتم ربط كل مفتاح مرور تشفيريًا بـ معرّف الطرف المعتمد (rpID) في لحظة إنشائه. إن rpID هو اسم نطاق يحدد نطاق وحدود بيانات الاعتماد تلك.

بشكل افتراضي، يكون rpID هو النطاق الفعلي للأصل حيث يتم إنشاء مفتاح المرور. تسمح قواعد تحديد النطاق في WebAuthn للأصل بتعيين rpID يكون إما مساويًا لنطاقه الخاص أو لاحقة نطاق قابلة للتسجيل. على سبيل المثال، يمكن لنص برمجي يعمل على https://www.accounts.example.co.uk إنشاء مفتاح مرور بـ rpID كالتالي:

• www.accounts.example.co.uk (النطاق الكامل)
• accounts.example.co.uk
• example.co.uk

تتيح هذه المرونة استخدام مفتاح مرور تم إنشاؤه على نطاق فرعي واحد عبر نطاقات فرعية أخرى لنفس النطاق الأصلي، وهو نمط شائع وضروري. ومع ذلك، تمنع القواعد بشكل صارم تعيين rpID ليس لاحقة. لا يمكن لنفس النص البرمجي على www.accounts.example.co.uk إنشاء مفتاح مرور بـ rpID example.com، لأن .com هو نطاق مستوى أعلى مختلف.

يخدم هذا الربط الصارم غرضًا مهمًا: فصل بيانات الاعتماد حسب نطاق النطاق. لا يمكن ممارسة مفتاح مرور تم إنشاؤه لـ mybank.com على phishing-site.com لأن الموقع الضار لا يمكنه المطالبة بـ rpID الشرعي لـ mybank.com. لن يقدم المتصفح حتى مفتاح المرور كخيار.

ومع ذلك، فإن rpID نفسه ليس هو التحكم الأساسي لمكافحة التصيد الاحتيالي. تأتي حماية WebAuthn من التصيد الاحتيالي فعليًا من التحقق من الأصل في كائن clientDataJSON. خلال كل عملية WebAuthn، ينشئ المتصفح كائن JSON يحتوي على سياق حاسم، بما في ذلك الأصل الدقيق الذي بدأ الطلب. ثم يتم توقيع هذا الكائن بالكامل بشكل تشفيري بواسطة المفتاح الخاص لـ أداة المصادقة (authenticator). يجب على الخادم (الطرف المعتمد) التحقق من هذا التوقيع، وبشكل حاسم، التحقق من أن حقل الأصل في clientDataJSON الموقع يتطابق مع قيمة متوقعة وموثوقة. هذا التحقق من الأصل هو ما يمنع هجمات التصيد الاحتيالي.

مع طلبات الأصول المرتبطة، يتم تخفيف قيود نطاق rpID - مما يسمح لـ bar.com بالمطالبة بشكل شرعي بـ rpID الخاص بـ foo.com بعد أن يتحقق المتصفح من ملف .well-known/webauthn - ولكن يظل شرط التحقق من الأصل دون تغيير. سيظل clientDataJSON يبلغ بصدق عن الأصل كـ bar.com. يتلقى الخادم في foo.com هذه البيانات الموقعة، ويتحقق منها، ويرى أن الطلب جاء من bar.com. يجب على الخادم بعد ذلك التحقق من أن bar.com هو أصل مرتبط متوقع قبل قبول المصادقة. وهذا يوضح نهجًا متعدد الطبقات يسمح بمرونة أكبر دون التضحية بالمبدأ الأساسي للتحقق من الأصل.

تقدم آلية طلبات الأصول المرتبطة طريقة أنيقة وموحدة للنطاقات للإعلان علنًا عن علاقة ثقة لغرض مشاركة مفاتيح المرور. إنها تستفيد من نمط ويب راسخ - /.well-known/ URI لإنشاء "قائمة سماح" قابلة للتحقق وقابلة للقراءة آليًا يمكن للمتصفحات الرجوع إليها.

المفهوم الأساسي واضح ومباشر: يمكن للنطاق الذي يعمل كـ rpID الأساسي والموثوق لمجموعة من المواقع المرتبطة استضافة ملف JSON خاص على عنوان URL موحد و "معروف جيدًا": https://{rpID}/.well-known/webauthn. يعمل هذا الملف كبيان عام، حيث يسرد صراحة جميع الأصول الأخرى المصرح لها رسميًا بإنشاء واستخدام مفاتيح المرور تحت هذا rpID الأساسي.

يتم تشغيل تدفق التحقق في المتصفح كلما واجه عدم تطابق بين الأصل الحالي و rpID المطلوب:

1. يبدأ مستخدم على موقع "مرتبط"، مثل https://example.co.uk، عملية مفتاح مرور (إنشاء أو مصادقة) حيث يحدد الكود من جانب العميل نطاقًا مختلفًا كـ rpID، على سبيل المثال، example.com.
2. يكتشف المتصفح عدم التطابق هذا. بموجب القواعد القديمة، كان هذا سيؤدي على الفور إلى خطأ أمني (SecurityError).
3. مع دعم ROR، يقوم المتصفح، قبل أن يفشل، بإجراء طلب HTTPS GET آمن إلى عنوان URL المعروف جيدًا لـ rpID المطالب به: https://example.com/.well-known/webauthn. يتم هذا الطلب بدون بيانات اعتماد المستخدم (مثل ملفات تعريف الارتباط) وبدون ترويسة المُحيل (referrer header) لحماية خصوصية المستخدم ومنع التتبع.
4. يتلقى المتصفح استجابة JSON من الخادم. يقوم بتحليل الملف ويتحقق مما إذا كان الأصل الحالي (https://example.co.uk) موجودًا في مصفوفة origins داخل كائن JSON.
5. إذا تم العثور على الأصل في قائمة السماح، يُسمح لعملية WebAuthn بالمتابعة باستخدام example.com كـ rpID صالح. إذا لم يتم العثور على الأصل، أو إذا كان الملف مفقودًا أو تالفًا، تفشل العملية كما كانت ستفعل سابقًا.

إن اختيار استخدام /.well-known/ URI هو أمر مقصود ويتوافق مع معايير الويب الراسخة لاكتشاف الخدمات والتحقق من التحكم في النطاق. يُستخدم مسار URI هذا، المحدد في RFC 8615، بالفعل من قبل العديد من البروتوكولات الهامة، بما في ذلك acme-challenge لإصدار شهادات Let's Encrypt SSL و assetlinks.json لربط مواقع الويب بتطبيقات Android. من خلال تبني هذا التقليد، يستفيد W3C من نمط يعني ضمنيًا ملكية النطاق. لوضع ملف في هذا المسار المحدد والموحد، يجب أن يكون لديك تحكم إداري في خادم الويب لذلك النطاق. يوفر هذا إثباتًا بسيطًا ولكنه فعال للتحكم، مما يجعل إعلان الثقة قابلاً للتحقق. عندما يقوم مالك example.com بتقديم ملف يسرد example.co.uk كأصل مرتبط، يكون هذا ادعاءً قابلاً للتحقق. هذا النهج الأصلي للويب أبسط وأكثر قوة من البدائل التي تم النظر فيها ورفضها أثناء عملية التوحيد القياسي، مثل استخدام مفاتيح التشفير لتوقيع التراخيص (RP Keys) أو المعرفات العشوائية غير المستندة إلى النطاق (RP UUIDs). يرتكز ROR على علاقة الثقة في نموذج التحكم في النطاق الحالي والمفهوم جيدًا للويب.

يتطلب تنفيذ طلبات الأصول المرتبطة تغييرات منسقة على كل من جانب الخادم، للسماح للأصول، وجانب العميل، لاستدعاء rpID المشترك. يوفر هذا القسم تفاصيل الكود والتكوين العملية اللازمة لتمكين تجربة مفتاح مرور موحدة عبر نطاقاتك.

الخادم الذي يستضيف rpID الأساسي هو المسؤول عن نشر قائمة السماح للأصول المرتبطة.

يجب وضع ملف التفويض في المسار الدقيق /.well-known/webauthn بالنسبة إلى جذر نطاق rpID الأساسي. من الأهمية بمكان أن يتم تقديم هذا الملف بالشروط التالية:

• البروتوكول: يجب تقديمه عبر HTTPS.
• نوع المحتوى (Content-Type): يجب تعيين ترويسة استجابة HTTP Content-Type إلى application/json.
• امتداد الملف: يجب ألا يتضمن عنوان URL امتداد .json. المسار الصحيح هو /webauthn، وليس /webauthn.json.

يجب أن يحتوي الملف على كائن JSON واحد بمفتاح واحد، origins، تكون قيمته مصفوفة من السلاسل النصية. كل سلسلة نصية في المصفوفة هي الأصل الكامل (البروتوكول، النطاق، والمنفذ الاختياري) الذي يتم التصريح به.

{
    "origins": ["https://example.co.uk", "https://example.de", "https://example.fr"]
}

مثال: بالنسبة لـ rpID example.com، يجب تقديم الملف على https://example.com/.well-known/webauthn (ملاحظة: لا يوجد امتداد .json).

بمجرد تكوين الخادم بملف .well-known/webauthn، يجب على جميع النطاقات المرتبطة استخدام نفس rpID المشترك باستمرار في استدعاءات WebAuthn API الخاصة بها. هذا التنسيق حاسم لكي تعمل ROR بشكل صحيح.

متطلبات التنسيق الرئيسية:

1. مسؤولية الواجهة الخلفية (Backend): يقوم الخادم بإنشاء التحدي التشفيري (cryptographic challenge) ويحدد rpID المشترك في كل من طلبات إنشاء بيانات الاعتماد والمصادقة.
2. مسؤولية الواجهة الأمامية (Frontend): يجب على جميع تطبيقات العميل (example.com، example.co.uk، example.de) تمرير نفس rpID المشترك إلى واجهة برمجة تطبيقات navigator.credentials في المتصفح.
3. إدارة التكوين: يجب التعامل مع rpID المشترك كقيمة تكوين عامة وحاسمة يتم تطبيقها باستمرار عبر جميع المواقع المرتبطة.

سيؤدي أي تكوين خاطئ حتى في موقع واحد - حيث يستخدم أصله الخاص كـ rpID افتراضيًا بدلاً من القيمة المشتركة - إلى كسر تجربة مفتاح المرور الموحدة للمستخدمين على هذا النطاق.

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

تحل طلبات الأصول المرتبطة (ROR) وبروتوكولات الهوية الموحدة (OIDC/SAML) مشاكل مختلفة. ROR ليس بديلاً لـ تسجيل الدخول الموحد (Single Sign-On) - بل هو مكمل يعالج حالة استخدام ضيقة ومحددة.

ROR مناسب لتطبيق منطقي واحد موزع عبر نطاقات متعددة مرتبطة تشترك في نفس قاعدة بيانات المستخدمين:

• علامة تجارية واحدة تعمل على نطاقات TLD متعددة خاصة بالبلدان (مثل amazon.com, amazon.de, amazon.co.uk)
• تشترك جميع النطاقات في نفس نظام المصادقة الخلفي وقاعدة بيانات المستخدمين
• تريد تجنب التدفقات القائمة على إعادة التوجيه والحفاظ على المصادقة في سياق كل نطاق
• تقع نطاقاتك ضمن حد الـ 5 تسميات (5-label limit)
• يجب أن يختبر المستخدمون جميع النطاقات كخدمة واحدة متماسكة

ما يقدمه ROR: يعمل نفس مفتاح المرور عبر جميع النطاقات المرتبطة، مما يلغي حاجة المستخدمين لإنشاء مفاتيح مرور منفصلة لكل موقع إقليمي.

استخدم بروتوكولات الهوية الموحدة لـ تسجيل دخول موحد حقيقي عبر تطبيقات متميزة:

• خدمات متعددة مع قواعد بيانات مستخدمين أو أنظمة هوية منفصلة
• سيناريوهات الشركات حيث يحتاج المستخدمون إلى الوصول إلى العديد من التطبيقات المختلفة (Salesforce, Office 365, الأدوات الداخلية)
• تكامل تطبيقات الطرف الثالث
• تحتاج إلى تحكم مركزي في الوصول، ومسارات تدقيق، وإدارة هوية
• تتجاوز حد الـ 5 تسميات للأصول المرتبطة

ما يقدمه OIDC/SAML: مصادقة مركزية حيث يقوم المستخدمون بتسجيل الدخول مرة واحدة في مزود الهوية (Identity Provider) (IdP) ويحصلون على حق الوصول إلى العديد من مزودي الخدمة (SPs) من خلال رموز آمنة.

هام: يمكن استخدام مفاتيح المرور مع كلا النهجين. يمكنك تنفيذ مفاتيح المرور في IdP مركزي لـ SSO الموحد، أو استخدام ROR لتطبيق واحد متعدد النطاقات. اختر بناءً على بنيتك التحتية، وليس طريقة المصادقة الخاصة بك.

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

أحد القيود الرئيسية لـ ROR هو "حد التسميات". تشير "التسمية" في هذا السياق إلى نطاق المستوى الأعلى الفعال بالإضافة إلى مستوى واحد (eTLD+1)، وهو الجزء القابل للتسجيل من اسم النطاق. على سبيل المثال:

• shopping.com و shopping.co.uk و shopping.ca تشترك جميعها في تسمية واحدة هي "shopping"
• myshoppingrewards.com يقدم تسمية جديدة ومتميزة: "myshoppingrewards"
• travel.shopping.com لا يزال يندرج تحت تسمية "shopping"

تتطلب مواصفات WebAuthn المستوى 3 أن تدعم تطبيقات المتصفح ما لا يقل عن خمس تسميات فريدة في قائمة origins. اعتبارًا من عام 2025، لا يوجد متصفح معروف يدعم أكثر من هذا الحد الأدنى البالغ خمس تسميات. لذلك، يجب على المؤسسات تصميم عمليات نشر ROR الخاصة بها مع أخذ هذا الحد الصارم في الاعتبار - تعامل مع خمسة باعتبارها الحد الأقصى الفعلي.

هذا الحد هو آلية متعمدة لمكافحة إساءة الاستخدام مصممة لمنع الاستخدام الخاطئ. فهو يمنع كيانات مثل مزودي الاستضافة المشتركة (مثل wordpress.com) من إنشاء مفتاح مرور عالمي يمكن أن يعمل عبر آلاف النطاقات الفرعية للعملاء غير المرتبطين، مما قد يقوض نموذج الأمان.

بالنسبة لمعظم المؤسسات، حتى العلامات التجارية الكبيرة متعددة الجنسيات، فإن حد الخمس تسميات هذا كافٍ. على سبيل المثال، تشترك نطاقات TLD المختلفة الخاصة بأمازون حسب البلد (amazon.com, amazon.de, amazon.co.uk, etc.) جميعها في تسمية "amazon"، مما يترك أربع خانات تسمية إضافية متاحة للعلامات التجارية الأخرى في محفظتها مثل "audible" أو "zappos".

تعتمد مدى تعقيد تنفيذ ROR بشكل كبير على ما إذا كان يتم إدخاله في نظام جديد أو تحديث نظام قائم.

• عمليات النشر الجديدة (Greenfield): بالنسبة للمشاريع الجديدة، تكون الاستراتيجية واضحة. يجب اختيار نطاق واحد أساسي ليكون rpID المشترك منذ البداية (على سبيل المثال، النطاق الأساسي .com). يجب بعد ذلك استخدام rpID هذا باستمرار في تكوين جميع مواقع الويب والتطبيقات المرتبطة من اليوم الأول.
• عمليات النشر الحالية: يعد تحديث ROR على نظام يحتوي بالفعل على مفاتيح مرور منشورة بـ rpIDs مختلفة عبر نطاقاته أكثر تعقيدًا بكثير. لا يمكن إجراء ترحيل مباشر، حيث أن مفاتيح المرور الحالية مرتبطة بشكل دائم بـ rpIDs الأصلية الخاصة بها. النهج الموصى به في هذا السيناريو هو تنفيذ تدفق تسجيل دخول "المعرف أولاً". يُطلب من المستخدم أولاً إدخال اسم المستخدم أو البريد الإلكتروني. ثم يقوم الخادم الخلفي بإجراء بحث لتحديد rpID الذي يرتبط به مفتاح المرور الحالي الخاص به. أخيرًا، يتم إعادة توجيه المستخدم إلى الأصل الصحيح المقابل لـ rpID هذا لإكمال عملية المصادقة. بعد تسجيل دخول ناجح، يمكن إعادة توجيههم إلى موقعهم الأصلي. هذا مشروع معماري كبير يتطلب تخطيطًا وتنفيذًا دقيقين.

يوفر فهم كيفية تنفيذ الشركات الراسخة لطلبات الأصول المرتبطة رؤى قيمة لاستراتيجية النشر الخاصة بك. فيما يلي أمثلة تستند إلى تطبيقات فعلية (اعتبارًا من أكتوبر 2025):

تستخدم Microsoft ROR في البنية التحتية للمصادقة الخاصة بها. يتضمن التكوين الفعلي في login.microsoftonline.com ما يلي:

// https://login.microsoftonline.com/.well-known/webauthn
{
    "origins": ["https://login.microsoftonline.com", "https://login.live.com"]
}

يمكّن هذا النهج المحافظ مشاركة مفاتيح المرور بين بوابات تسجيل الدخول للمؤسسات والمستهلكين في Microsoft مع الحفاظ على محيط أمني مركز.

تطبق Shopify ROR لتوحيد المصادقة عبر نطاقات محددة:

// https://shopify.com/.well-known/webauthn
{
    "origins": ["https://shopify.com", "https://shop.app"]
}

يسمح هذا التكوين لـ Shopify بربط منصتها الرئيسية بتطبيق Shop الخاص بها، مما يوضح نهجًا مركزًا للأصول المرتبطة.

لدى أمازون ملف كبير نوعًا ما:

// https://amazon.com/.well-known/webauthn
{
    "origins": [
        "https://www.amazon.com",
        "https://www.amazon.com.br",
        "https://www.amazon.com.mx",
        "https://www.amazon.ca",
        "https://www.amazon.co.uk",
        "https://www.amazon.de",
        "https://www.amazon.it",
        "https://www.amazon.es",
        "https://www.amazon.nl",
        "https://www.amazon.se",
        "https://www.amazon.sa",
        "https://www.amazon.pl",
        "https://www.amazon.com.tr",
        "https://www.amazon.fr",
        "https://www.amazon.com.au",
        "https://www.amazon.sg",
        "https://www.amazon.ae",
        "https://www.amazon.eg",
        "https://www.amazon.co.za",
        "https://www.amazon.in",
        "https://brandregistry.amazon.com",
        "https://sellercentral.amazon.com",
        "https://sellercentral.amazon.com.br",
        "https://sellercentral.amazon.com.mx",
        "https://sellercentral.amazon.ca",
        "https://sellercentral.amazon.co.uk",
        "https://sellercentral.amazon.de",
        "https://sellercentral.amazon.it",
        "https://sellercentral.amazon.es",
        "https://sellercentral.amazon.nl",
        "https://sellercentral.amazon.se",
        "https://sellercentral.amazon.sa",
        "https://sellercentral.amazon.pl",
        "https://sellercentral.amazon.com.tr",
        "https://sellercentral.amazon.fr",
        "https://sellercentral.amazon.com.au",
        "https://sellercentral.amazon.sg",
        "https://sellercentral.amazon.ae",
        "https://sellercentral.amazon.eg",
        "https://sellercentral.amazon.co.za",
        "https://sellercentral.amazon.in",
        "https://na.account.amazon.com",
        "https://vendorcentral.amazon.com",
        "https://vendorcentral.amazon.com.br",
        "https://vendorcentral.amazon.com.mx",
        "https://vendorcentral.amazon.ca",
        "https://vendorcentral.amazon.co.uk",
        "https://vendorcentral.amazon.de",
        "https://vendorcentral.amazon.it",
        "https://vendorcentral.amazon.es",
        "https://vendorcentral.amazon.nl",
        "https://vendorcentral.amazon.se",
        "https://vendorcentral.amazon.pl",
        "https://vendorcentral.amazon.com.tr",
        "https://vendorcentral.amazon.fr",
        "https://vendorcentral.amazon.com.au",
        "https://vendorcentral.amazon.co.za"
    ]
}

يسمح هذا النمط للعلامة التجارية بتوفير مصادقة موحدة لمفاتيح المرور عبر النطاقات الإقليمية مع استخدام النطاق الأساسي .com كـ rpID.

تكشف هذه الأمثلة الواقعية عن عدة أنماط رئيسية:

1. النطاق الأساسي كـ rpID: تستخدم جميع الشركات نطاق .com الأساسي الخاص بها كـ rpID الأساسي.
2. التجميع المنطقي: يتم تجميع الأصول حسب الوظيفة التجارية بدلاً من البنية التقنية.
3. النطاق المحافظ: تظل معظم التطبيقات أقل بكثير من حد الـ 5 تسميات، وعادة ما تستخدم 3-4 أصول.
4. استراتيجية النطاقات الفرعية: يستخدم الكثيرون نطاقات فرعية من النطاق الأساسي للحفاظ على اتساق العلامة التجارية.

كمعيار ويب حديث، تم تصميم ROR مع اعتبار الأمان كأولوية قصوى ويشهد تبنيًا نشطًا عبر المتصفحات الرئيسية.

لا تساوم طلبات الأصول المرتبطة على ضمانات WebAuthn الأساسية لمكافحة التصيد الاحتيالي. تم تصميم الآلية بعناية للحفاظ على وضع أمني قوي:

• التحقق من الأصل: كما تمت مناقشته، لا يزال المتصفح يتضمن الأصل الحقيقي للطلب في clientDataJSON الموقع. يجب على خادم الطرف المعتمد التحقق من هذا الأصل لضمان أن الطلب يأتي من مصدر متوقع، مما يمنع أصلًا مرتبطًا مخترقًا من انتحال هوية أصل آخر.
• الجلب الآمن: يتم طلب المتصفح لملف .well-known/webauthn عبر HTTPS. علاوة على ذلك، تنص المواصفات على أن يتم هذا الجلب بدون بيانات اعتماد (مثل ملفات تعريف الارتباط) وبدون ترويسة Referer. يمنع هذا استخدام الطلب لتسريب معلومات المستخدم أو لأغراض التتبع عبر المواقع.
• أمان الخادم: يصبح ملف .well-known/webauthn نفسه أحد الأصول الأمنية الهامة. يمكن للمهاجم الذي يسيطر على خادم الويب الذي يستضيف rpID الأساسي أن يعدل هذا الملف لإضافة نطاقه الضار إلى قائمة السماح. لذلك، فإن تأمين البنية التحتية التي تخدم هذا الملف له أهمية قصوى.

تعد طلبات الأصول المرتبطة ميزة في مواصفات WebAuthn Level 3. بدأ دعم المتصفحات في الظهور في أواخر عام 2024:

حقائق رئيسية:

• Chrome و Edge: تمت إضافة دعم ROR في الإصدار 128 (أغسطس 2024)
• Safari: تمت إضافة دعم ROR في Safari 18، المتاح على macOS 15 و iOS 18 (سبتمبر 2024)
• Firefox: لا يوجد دعم حالي لـ ROR؛ اكتشف الميزة وقم بتنفيذ تدفقات بديلة

للتطبيقات التي تحتاج إلى دعم المتصفحات القديمة أو Firefox، قم بتنفيذ استراتيجية بديلة:

1. اكتشاف الميزة: تحقق من دعم ROR باستخدام PublicKeyCredential.getClientCapabilities()
2. تدفق المعرف أولاً: اطلب اسم المستخدم/البريد الإلكتروني، وابحث عن rpID المرتبط بالمستخدم، ثم أعد توجيهه إلى الأصل المناسب للمصادقة
3. التدهور التدريجي: اسمح للمستخدمين بإنشاء مفاتيح مرور منفصلة لكل نطاق إذا لم يكن ROR متاحًا

تستند البيانات إلى مصفوفات الدعم الحالية اعتبارًا من أكتوبر 2025.

يتطلب تنفيذ طلبات الأصول المرتبطة تنسيقًا دقيقًا بين فرق فنية متعددة وخبرة عميقة في بروتوكولات WebAuthn. تزيل منصة تبني مفاتيح المرور من Corbado هذا التعقيد من خلال توفير حلول جاهزة للمؤسسات لعمليات نشر مفاتيح المرور متعددة النطاقات.

تتعامل Corbado مع التعقيد الفني لطلبات الأصول المرتبطة من خلال:

• التكوين الآلي: تنشئ منصتنا وتستضيف ملفات .well-known/webauthn المطلوبة تلقائيًا مع ترويسات الأمان المناسبة وتنسيق JSON
• لوحة تحكم متعددة النطاقات: واجهة إدارة مركزية لتكوين الأصول المرتبطة عبر محفظة النطاقات بأكملها
• أدوات التحقق: اختبار وتحقق مدمجان لضمان عمل تكوين ROR الخاص بك بشكل صحيح عبر جميع المتصفحات والمنصات

بالإضافة إلى التنفيذ الفني، توفر Corbado إطار الأمان الذي تحتاجه المؤسسات:

• التحقق من الأصل: التحقق التلقائي من أصول clientDataJSON لمنع إساءة استخدام النطاقات المرتبطة
• تسجيل التدقيق: تتبع شامل لاستخدام مفاتيح المرور عبر جميع النطاقات المرتبطة للمراقبة الأمنية والامتثال
• الاستجابة للحوادث: تنبيهات في الوقت الفعلي واستجابات آلية لمحاولات المصادقة عبر النطاقات المشبوهة

بالنسبة للمؤسسات التي لديها عمليات نشر حالية لمفاتيح المرور، تقدم Corbado:

• أدوات ترحيل الأنظمة القديمة: تحليل آلي لتكوينات rpID الحالية وتوصيات مسار الترحيل
• تدفقات المعرف أولاً: مكونات تسجيل دخول مسبقة الصنع تتعامل مع سيناريوهات multi-rpID المعقدة خلال فترات الانتقال
• تكامل API: واجهات برمجة تطبيقات RESTful و SDKs تتكامل بسلاسة مع البنية التحتية للمصادقة الحالية الخاصة بك

هل أنت مستعد لتنفيذ طلبات الأصول المرتبطة لمؤسستك؟ يمكن لفريق خبراء Corbado مساعدتك في تصميم ونشر تجربة مفتاح مرور موحدة عبر نظامك الرقمي بالكامل. اتصل بفريق الحلول لدينا لمناقشة متطلباتك المحددة والجدول الزمني.

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

توفر طلبات الأصول المرتبطة في WebAuthn الحل الموحد والآمن والأنيق لهذه المشكلة. من خلال السماح لمفتاح مرور واحد بالعمل بسلاسة عبر مجموعة موثوقة من النطاقات المرتبطة، يزيل ROR نقطة رئيسية من الارتباك والإحباط لدى المستخدم.

تناول هذا الدليل خمسة أسئلة حاسمة لتنفيذ طلبات الأصول المرتبطة في WebAuthn:

1. لماذا تفشل مفاتيح المرور عبر نطاقات متعددة؟ يقوم نموذج الأمان المرتبط بالأصل في WebAuthn بقفل مفاتيح المرور بشكل تشفيري على نطاقات محددة لمنع التصيد الاحتيالي، ولكن هذا يخلق احتكاكًا عندما تعمل العلامات التجارية عبر نطاقات متعددة مثل نطاقات TLD الخاصة بالبلدان المختلفة.
2. كيف تعمل طلبات الأصول المرتبطة تقنيًا؟ يستخدم ROR ملف .well-known/webauthn موحدًا لإنشاء قائمة سماح قابلة للتحقق من النطاقات المرتبطة، مما يمكّن المتصفحات من التحقق من استخدام مفاتيح المرور عبر النطاقات من خلال عملية جلب آمنة عبر HTTPS.
3. ما هو المطلوب لتنفيذ ROR؟ يتطلب التنفيذ تكوينًا من جانب الخادم لملف بيان .well-known/webauthn وتنسيقًا من جانب العميل لاستخدام rpID مشترك باستمرار عبر جميع الأصول المرتبطة.
4. متى يجب عليك اختيار ROR بدلاً من تسجيل الدخول الموحد؟ استخدم ROR لتجارب العلامة التجارية الموحدة عبر النطاقات المرتبطة مع قواعد بيانات مستخدمين مشتركة؛ استخدم OIDC/SAML لـ SSO الحقيقي عبر تطبيقات متميزة أو عند تجاوز حد الـ 5 تسميات.
5. كيف تتعامل مع توافق المتصفحات والاعتبارات الأمنية؟ ROR مدعوم في المتصفحات الرئيسية من Chrome/Firefox 128+، و Safari على macOS 15+، و iOS 18+، مع توفر استراتيجيات بديلة للمتصفحات القديمة من خلال تدفقات المعرف أولاً.

بالنسبة للفرق الفنية وقادة المنتجات، النقاط الأساسية هي:

• يتيح ROR تجربة مفتاح مرور موحدة لتطبيق منطقي واحد موزع عبر نطاقات متعددة، مثل تلك التي تحتوي على نطاقات TLD مختلفة خاصة بالبلدان أو علامات تجارية بديلة.
• يتطلب التنفيذ جهدًا منسقًا: يجب نشر ملف .well-known/webauthn من جانب الخادم على نطاق rpID الأساسي، ويجب تكوين جميع تطبيقات جانب العميل لاستخدام نفس rpID المشترك.
• إن قرار استخدام ROR هو قرار استراتيجي. إنه أداة ممتازة لحالات استخدامه المحددة ولكن يجب الموازنة بينه وبين بنية تسجيل دخول موحد أكثر تقليدية (OIDC/SAML)، خاصة في السيناريوهات التي تتضمن تسجيل دخول موحد (Single Sign-On) حقيقي عبر تطبيقات متباينة.

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