--- url: 'https://www.corbado.com/ar/blog/webauthn-relying-party-id-rpid-passkeys-ar' title: 'Relying Party ID (rpID) لتقنية WebAuthn ومفاتيح المرور: النطاقات والتطبيقات الأصلية' description: 'تشرح هذه التدوينة أهمية Relying Party ID لتقنية WebAuthn في مصادقة مفاتيح المرور. وتوضح التكوين الصحيح، ومطابقة النطاقات، وإعدادات التطبيقات الأصلية.' lang: 'ar' author: 'Vincent Delitz' date: '2026-06-15T13:56:07.601Z' lastModified: '2026-06-17T06:05:14.542Z' keywords: 'relying party id, webauthn, مفاتيح المرور, مصادقة, نطاقات, تطبيقات أصلية' category: 'WebAuthn Know-How' --- # Relying Party ID (rpID) لتقنية WebAuthn ومفاتيح المرور: النطاقات والتطبيقات الأصلية ## Key Facts - يعد **Relying Party ID** نطاقاً مدمجاً في كل مفتاح مرور. تفشل المصادقة إذا كان أصل المتصفح لا يتطابق، مما يجعل مفاتيح المرور مقاومة بشدة للتصيد الاحتيالي. - يجب ألا يكون **RP ID** مدرجاً في **قائمة اللواحق العامة** (Public Suffix List)، ويؤدي تغييره إلى إبطال جميع مفاتيح المرور الحالية. استخدم النطاق الجذري افتراضياً لضمان التوافق المستقبلي. - تتطلب تطبيقات iOS ملف **apple-app-site-association** في المسار `/.well-known/` تحت RP ID. ويتطلب Android ملف **assetlinks.json** في نفس المسار. قد تستغرق الملفات الجديدة ما يصل إلى 24 ساعة ليتم تخزينها مؤقتاً. - تتطلب النطاقات الجذرية المتعددة **طلبات الأصل ذات الصلة** (Related Origin Requests) عبر `.well-known/webauthn` لمشاركة مفاتيح المرور. استخدم خادم WebAuthn واحداً مع RP ID واحد لجميع التطبيقات، سواء كانت ويب أو تطبيقات أصلية. ## 1. مقدمة أصبحت مصادقة مفاتيح المرور هي المعيار الجديد بسرعة حيث تقوم شركات التكنولوجيا العملاقة مثل [TikTok](https://www.corbado.com/blog/tiktok-passkeys) و GitHub و [WhatsApp](https://www.corbado.com/blog/whatsapp-passkeys) و X (Twitter) و [LinkedIn](https://www.corbado.com/blog/linkedin-passkeys) و Amazon بطرحها أو قامت بذلك بالفعل. من الواضح أن عالم التكنولوجيا يدرك أهمية المصادقة البسيطة والآمنة. بعيداً عن تجربة المستخدم السلسة للمصادقة باستخدام [Face ID](https://www.corbado.com/faq/is-face-id-passkey) أو Touch ID أو [Windows Hello](https://www.corbado.com/glossary/windows-hello)، توفر مفاتيح المرور أماناً لا مثيل له مقارنة بطرق المصادقة التقليدية مثل كلمات المرور. إحدى الميزات البارزة هي مقاومتها القوية للتصيد الاحتيالي. هجوم التصيد الاحتيالي هو هجوم يتم فيه خداع الضحية لتقديم بيانات الاعتماد لموقع مزيف يحاكي الموقع الأصلي. على سبيل المثال، تخيل تلقي رسالة بريد إلكتروني تبدو وكأنها من البنك الذي تتعامل معه، تطلب منك تسجيل الدخول. تنقر على الرابط، ويبدو الموقع الويب شرعياً، فتقوم بإدخال بيانات الاعتماد الخاصة بك ويمكن للمهاجم استخدامها لتسجيل الدخول إلى الموقع الأصلي. أصبحت هذه مشكلة متزايدة في العصر الرقمي، وحتى الشركات الكبرى مثل [Okta ](https://www.darkreading.com/application-security/okta-flaw-involved-mgm-resorts-breach-attackers-claim) (مزود مصادقة!) أو [Retool ](https://retool.com/blog/mfa-isnt-mfa/) وقعت ضحية لهجمات التصيد الموجه (spear-[phishing](https://www.corbado.com/glossary/phishing))، وهو شكل خاص من التصيد حيث يتم استهداف ضحايا محددين بشكل خاص بحيل تصيد شخصية جداً، مما يؤكد الحاجة إلى تدابير أمنية قوية. على العكس من ذلك، إذا كنت تستخدم مفتاح مرور، وكان الموقع مزيفاً، فستفشل المصادقة الخاصة بك. وذلك لأن مفاتيح المرور مرتبطة بالنطاقات التي تم إنشاؤها من أجلها عبر **Relying Party ID**. > لا يمكنك تسجيل الدخول باستخدام مفتاح مرور على أي موقع آخر، مما يجعل مفاتيح المرور مقاومة > بشدة للتصيد الاحتيالي (على الرغم من عدم وجود نظام محصن تماماً ضد جميع نواقل الهجوم). هذه الآلية مدمجة في WebAuthn، وهو معيار الويب الأساسي لمفاتيح المرور للمصادقة بدون كلمة مرور. يعتمد WebAuthn على عمليتين أساسيتين: عملية التسجيل وعملية المصادقة. أثناء عملية التسجيل (sign-up)، يتم إنشاء مفتاح مرور جديد لخدمة عبر الإنترنت (Relying Party) عبر تطبيق ويب أو تطبيق أصلي. في هذه العملية، يتم تخزين النطاق (Relying Party ID) الذي تم إنشاء مفتاح المرور من أجله داخل مفتاح المرور. يسمح هذا لعملية المصادقة (login) بالتحقق مما إذا كانت الخدمة عبر الإنترنت (Relying Party)، التي ينتمي إليها تطبيق الويب أو التطبيق الأصلي، تتطابق مع [Relying Party](https://www.corbado.com/glossary/relying-party) ID المخزن في مفتاح المرور. فيما يلي، سنرى بالتفصيل كيف تعمل عملية [مطابقة النطاق](#what-relying-party-id) وكيف يتم تأمين التطبيقات الأصلية بشكل خاص. ## 2. ما هو Relying Party ID؟ [**Relying Party ID**](https://www.w3.org/TR/webauthn-2/#relying-party-identifier) هو في الأساس نطاق مخزن داخل مفتاح المرور، مما يضمن أن مفتاح المرور يعمل فقط إذا كان عنوان URL الحالي للمتصفح (أصل المستخدم الذي يتم إرساله تلقائياً في كل طلب) يتطابق معه (انظر نهج التطبيق الأصلي [أدناه](#integration-options-native-apps)). إنه مكون حاسم في مواصفات WebAuthn، والتي يمكنك التعمق فيها [هنا](https://www.w3.org/TR/webauthn-2/). يمكن أن يكون [Relying Party](https://www.corbado.com/glossary/relying-party) ID هو النطاق الجذري (مثل `corbado.com`) أو نطاقاً فرعياً (`auth.corbado.com`). لا يمكنك تخزين النطاق الجذري كـ [Relying Party](https://www.corbado.com/glossary/relying-party) ID إذا كان مدرجاً في قائمة اللواحق العامة (ابحث عن القائمة والمكتبات لاكتشاف اللواحق العامة [هنا](https://publicsuffix.org/learn/)). سيؤدي تغيير Relying Party ID لخدمة عبر الإنترنت إلى كسر مفاتيح المرور الحالية (الاستثناءات: Relying Party ID الجديد هو نطاق فرعي من Relying Party ID القديم، أو تم تكوين طلبات الأصل ذات الصلة عبر `.well-known/webauthn` للسماح بإعادة استخدام مفتاح المرور عبر النطاقات ذات الصلة). أثناء عملية المصادقة، يتم فحص Relying Party ID مقابل عنوان URL للمتصفح (أصل المستخدم) لضمان تطابقهما. المطابقة بهذا المعنى تعني إما: - عنوان URL للمتصفح (أصل المستخدم) يتطابق بدقة مع Relying Party ID، أو - عنوان URL للمتصفح (أصل المستخدم) هو نطاق فرعي يتطابق مع Relying Party ID والنطاق الأصل قابل للتسجيل (على سبيل المثال، لا تعمل `com` أو أي نطاق في قائمة اللواحق العامة) فيما يلي مخطط تفصيلي يوضح أي _originalHost_ (العمود الثاني) يُسمح له بالوصول إلى النطاق الأصل الخاص به: ![جدول Relying Party ID](https://www.corbado.com/website-assets/relying_party_id_table_4c98cc04f4.jpg) فيما يلي، ترى [**PublicKeyCredentialCreationOptions**](https://www.w3.org/TR/webauthn-2/#iface-pkcredential) الذي تم تحليله: ```json { "publicKey": { "attestation": "direct", "authenticatorSelection": { "authenticatorAttachment": "platform", "requireResidentKey": false, "userVerification": "preferred" }, "challenge": "qNqrdXUrk5S7dCM1MAYH3qSVDXznb-6prQoGqiACR10=", "excludeCredentials": [], "pubKeyCredParams": [ { "alg": -7, "type": "public-key" } ], "rp": { "id": "corbado.com", "name": "Corbado" }, "timeout": 30000, "user": { "displayName": "Corbado user", "id": "bz9ZDfHzOBLycqISTAdWwWIZt8VO-6mT3hBNXS5jwmY=" } } } ``` تشير `rp` إلى Relying Party. إحدى الفوائد الرئيسية لـ Relying Party ID هي منع هجمات التصيد الاحتيالي. تخيل السيناريو التالي: 1. يطور أحد المهاجمين نسخة مقلدة من [PayPal](https://www.corbado.com/blog/paypal-passkeys) وهي عبارة عن موقع ويب مزيف يحاول سرقة بيانات اعتماد [PayPal](https://www.corbado.com/blog/paypal-passkeys) الخاصة بك لتسجيل الدخول باسمك وإرسال الأموال إلى حساب المهاجم. تتم استضافة هذا الموقع المزيف لـ [PayPal](https://www.corbado.com/blog/paypal-passkeys) على النطاق paybal.com (لذلك غالباً ما لا يكون من الواضح أنه نطاق مختلف للوهلة الأولى). 2. لقد قمت بالفعل بإنشاء مفتاح مرور في الماضي لموقع PayPal الشرعي. قام مفتاح المرور هذا بتخزين Relying Party ID كـ paypal.com. 3. تزور موقع PayPal المزيف على paybal.com (أثناء زيارتك لهذا الموقع، يكون أصل طلبك هو paybal.com\*) ويرسل الموقع لجهازك (المصدق) تحدياً لـ Relying Party ID `paypal.com` (هنا يحاول خداعك) ويطلب منك توقيعه بمفتاح المرور الخاص بك لـ Relying Party ID `paypal.com`. 4. يتحقق جهازك (المصدق) مما إذا كان أصل الطلب (`paypal.com`) و Relying Party ID الذي قام بتخزينه في مفتاح المرور (`paypal.com`) متطابقين. 5. نظراً لأنهما من الواضح أنهما غير متطابقين، تفشل المصادقة وتنقذك من منح بعض المهاجمين حق الوصول إلى حساب PayPal الخاص بك. يوضح الرسم البياني التالي آلية منع التصيد الاحتيالي هذه. _في حالة التطبيق الأصلي، تختلف معالجة الأصل حسب النظام الأساسي: على Android، يتم تنسيق الأصل كـ `android:apk-key-hash:`. على iOS، أصل WebAuthn هو أصل الويب الخاص بـ RP (مثل `https://paypal.com`). في كلتا الحالتين، يتم التحقق من الثقة بين تطبيقك الأصلي والخادم عبر ملف الارتباط المقابل (انظر [أدناه](#configuring-relying-party-native-apps)). للحصول على معلومات مفصلة حول كيفية عمل التحقق من الأصل للتطبيقات الأصلية، راجع دليلنا المخصص حول التحقق من أصل WebAuthn للتطبيقات الأصلية._ ## 3. خيارا التكامل المختلفان للتطبيقات الأصلية لتنفيذ مفاتيح المرور في تطبيق أصلي، يمكن للمطور أن يقرر بين إضافتها عبر [WebView](https://www.corbado.com/blog/native-app-passkeys) أو بشكل أصلي. دعونا نفحص فوائد وعيوب كلا النهجين فيما يلي. ### 3.1 تكامل مفتاح المرور عبر WebView ![تكامل مفتاح المرور عبر WebView (GitHub)](https://www.corbado.com/website-assets/650c601b1eb462e25702a870_android_webview_passkey_github_8bc81d9852.jpg) يعني استخدام **WebView**\* لدمج مفاتيح المرور تضمين متصفح ويب داخل التطبيق الأصلي للتعامل مع عملية المصادقة. يعرض هذا النهج أساساً صفحة ويب داخل التطبيق، مما يسهل إعادة استخدام تدفقات المصادقة المستندة إلى الويب دون الحاجة إلى إعادة كتابتها للنظام الأساسي الأصلي. ومع ذلك، هناك بعض العيوب. قد لا تدعم WebViews جميع ميزات مفتاح المرور، وهناك خطر محتمل لهجمات "رجل في المنتصف" (man-in-the-middle) إذا لم يتم تنفيذها بشكل آمن. بالإضافة إلى ذلك، قد لا تكون تجربة المستخدم سلسة كما هو الحال مع عمليات التكامل الأصلية، وقد تكون هناك تحديات في الحفاظ على سلوك ثابت عبر الأجهزة وإصدارات أنظمة التشغيل المختلفة. _\*هناك أنواع متعددة من WebViews: على iOS (WKWebView أو SFSafariViewController أو SFAuthenticationSession / ASWebAuthenticationSession لتدفقات المصادقة المستندة إلى OAuth/OpenID Connect) وعلى Android (WebView، CCT-Chrome Custom Tabs). نوصي باستخدام SFSafariViewController/ ASWebAuthenticationSession و Chrome Custom Tabs في سياق مفاتيح المرور إذا كنت لا تريد تكاملاً أصلياً._ ### 3.2 التكامل الأصلي لمفتاح المرور ![التكامل الأصلي لمفتاح المرور (Kayak)](https://www.corbado.com/website-assets/650c625cac723f594137a029_android_native_passkey_kayak_0f689e761e.jpg) يتضمن **التكامل الأصلي** بناء وظيفة مفتاح المرور مباشرة في تطبيق [iOS](https://www.corbado.com/blog/how-to-enable-passkeys-ios) أو [Android](https://www.corbado.com/blog/how-to-enable-passkeys-android) باستخدام واجهات برمجة التطبيقات والمكتبات الخاصة بالنظام الأساسي. توفر هذه الطريقة تجربة مستخدم أكثر سلاسة، حيث ليست هناك حاجة للانتقال بين التطبيق الأصلي و [WebView](https://www.corbado.com/blog/native-app-passkeys). كما أنها تسمح بأداء أفضل ومظهر وشعور أكثر تناسقاً. من وجهة نظر أمنية، يمكن أن يوفر التكامل الأصلي حماية معززة ضد أنواع معينة من الهجمات، خاصة عند دمجه مع ميزات الأمان الخاصة بالنظام الأساسي. ومع ذلك، يمكن أن يكون جهد التنفيذ أعلى، حيث يحتاج المطورون إلى كتابة وصيانة رموز منفصلة لكل نظام أساسي (Android و [iOS](https://www.corbado.com/blog/how-to-enable-passkeys-ios)). بالإضافة إلى ذلك، قد يتطلب البقاء محدثاً بأحدث مواصفات مفتاح المرور / WebAuthn تحديثات تطبيق أكثر تواتراً. فيما يلي، نركز على التكامل الأصلي لمفتاح المرور. ## 4. تكوين Relying Party للتطبيقات الأصلية تمثل التطبيقات الأصلية (مثل تطبيقات [iOS](https://www.corbado.com/blog/how-to-enable-passkeys-ios) أو [Android](https://www.corbado.com/blog/how-to-enable-passkeys-android)) تحدياً مقارنة بتطبيقات الويب. على عكس تطبيقات الويب، لا يوجد عنوان URL للمتصفح لمطابقته مع Relying Party ID. ومع ذلك، لضمان نفس المستوى من الأمان، يتم توصيل النطاقات بالتطبيقات الأصلية عبر **ملفات الارتباط** (association files)، بحيث يتم إنشاء الثقة بين النطاق والتطبيق الأصلي. هذا مهم بشكل خاص إذا تم إنشاء مفتاح مرور على تطبيق ويب ويجب استخدامه لنفس Relying Party ID في تطبيق أصلي (والعكس صحيح). ### 4.1 ملفات الارتباط على iOS: apple-app-site-association يستخدم iOS ملف apple-app-site-association. يحتوي هذا الملف على استحقاقات مختلفة (entitlements)، ولكن بالنسبة لـ WebAuthn ومفاتيح المرور، فإن استحقاق webcredentials مهم. ```json { "webcredentials": { "apps": ["9RF9KY88B2.com.corbado.passkeys"] } } ``` في webcredentials.apps، تحتاج إلى تخزين بادئة معرف التطبيق الخاص بك (Application Identifier Prefix) (مثل `9RF9KY77B2`) ومعرف الحزمة الخاص بك (Bundle Identifier) (مثل `com.corbado.passkeys`). لكي تعمل تطبيقات iOS الأصلية، يجب تخزين ملف apple-app-site-association ضمن دليل `/.well-known` الخاص بـ Relying Party ID (`https:///.well-known/apple-app-site-association`). انظر إلى مثال حي [هنا](https://pro-6244024196016258271.frontendapi.cloud.corbado.io/.well-known/apple-app-site-association). ### 4.2 ملفات الارتباط على Android: assetlinks.json يستخدم [Android](https://www.corbado.com/blog/how-to-enable-passkeys-android) ملف `assetlinks.json`، والذي، مثل نظيره في iOS، يتطلب تكوينات معينة لـ WebAuthn ومفاتيح المرور. ```json [ { "relation": [ "delegate_permission/common.handle_all_urls", "delegate_permission/common.get_login_creds" ], "target": { "namespace": "android_app", "package_name": "com.corbado.passkeys.pub", "sha256_cert_fingerprints": [ "F8:90:4E:9A:99:01:71:75:25:38:D5:36:16:2D:B3:65:EB:41:51:D4:53:9A:72:BC:4B:56:C5:16:43:62:E2:C0" ] } } ] ``` تحتاج إلى تعيين قيم العلاقة `delegate_permission/common.handle_all_urls` و `delegate_permission/common.get_login_creds`. بالإضافة إلى ذلك، تحتاج إلى إضافة اسم الحزمة الخاص بك وبصمة SHA-256 لشهادة التوقيع الخاصة بك. للسماح بمشاركة مفتاح مرور بين تطبيق أصلي وتطبيق ويب، تحتاج إلى إضافة إدخالين. أحدهما لمساحة الاسم web والآخر لمساحة الاسم android_app. انظر إلى مثال حي [هنا](https://pro-6244024196016258271.frontendapi.cloud.corbado.io/.well-known/assetlinks.json). لكي تعمل تطبيقات Android، يجب تخزين ملف assetlinks.json ضمن دليل `/.well-known` الخاص بـ Relying Party ID (`https:///.well-known/assetlinks.json` - لذا فهو يشبه إلى حد كبير الموجود على iOS). تحقق من منشور المدونة هذا لرؤية نموذج تنفيذ يشارك مفاتيح المرور بين تطبيق Android / iOS أصلي وتطبيق ويب. ## 5. إنشاء الثقة بين التطبيق الأصلي وتطبيق الويب ### 5.1 iOS تبدو عملية إنشاء الثقة بين تطبيق iOS وتطبيق الويب كما يلي: 1. يجب على مطور تطبيق iOS تحديد قائمة بالنطاقات التي يريد ربطها بالتطبيق الأصلي. يتم ترميز هذه النطاقات في استحقاقات تطبيق iOS، على سبيل المثال: - webcredentials:auth.Corbado.com - webcredentials:\*.Corbado.com 2. في كل مرة يتم فيها تثبيت تطبيق iOS أو تحديثه، سيقوم iOS بتنزيل ملف apple-app-site-association لكل إدخال في قائمة استحقاقات تطبيق iOS. 3. عندما يتم إنشاء بيانات اعتماد (مثل مفتاح المرور) داخل تطبيق iOS، يتحقق تطبيق iOS مما إذا كان نطاق خوادم الطرف المعتمد مرتبطاً بتطبيق iOS من خلال التحقق من الجانبين التاليين: - هل يوجد ملف `apple-app-site-association` لنطاق خوادم الطرف المعتمد هذا موجود على الجهاز؟ - هل تطبيق iOS مدرج في ملف `apple-app-site-association` هذا؟ إذا وفقط إذا أمكن الإجابة على كلا السؤالين بنعم، يمكن إنشاء مفتاح مرور داخل تطبيق iOS. ### 5.2 Android تبدو عملية إنشاء الثقة بين تطبيق Android وتطبيق الويب كما يلي: 1. يجب على مطور تطبيق Android تحديد قائمة بالنطاقات التي يريد ربطها بتطبيق Android. يتم تخزين هذه النطاقات كأهداف مع مساحة الاسم web في ملف assetlinks.json. للإعلان عن أن تطبيقات Android وتطبيقات الويب تشترك في بيانات الاعتماد، يجب تحديد `delegate_permission/common.get_login_creds`. ابحث عن التفاصيل [هنا](https://developer.android.com/training/sign-in/passkeys#add-support-dal). 2. إذا تم إنشاء مفتاح مرور داخل تطبيق Android، يتحقق تطبيق Android مما إذا كان Relying Party ID مرتبطاً بتطبيق Android عن طريق التحقق من `assetlinks.json`: - هل يوجد ملف `assetlinks.json` لـ Relying Party ID هذا على `https://./well-known/assetlinks.json` - هل تطبيق Android محدد بشكل صحيح كهدف. 3. إذا وفقط إذا أمكن الإجابة على كلا السؤالين بنعم، يمكن إنشاء مفتاح مرور داخل تطبيق Android. يقارن الرسم البياني أدناه عمليات إنشاء الثقة هذه جنباً إلى جنب. ## 6. نظرة عامة على إعدادات Android و iOS و Flutter فيما يلي، نقدم نظرة عامة مفصلة على الإعدادات المختلفة المطلوبة لإعداد مصادقة مفتاح المرور بشكل صحيح للتطبيقات الأصلية. | الميزة | iOS | Android | | --------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | إرشادات التنفيذ الرسمية للمصادقة الأصلية بمفتاح المرور | Apple Developer | Google Developer | | يسمح بمشاركة مفاتيح المرور مع تطبيقات الويب | نعم، عبر ملف apple-app-site-association | نعم، عبر assetlinks.json | | موقع ملف الارتباط | [https://acme.com/.well-known/apple-app-site-association](https://acme.com/.well-known/apple-app-site-association) | [https://acme.com/.well-known/assetlinks.json](https://acme.com/.well-known/assetlinks.json) | | تخزين الملف مؤقتاً | نعم (منذ iOS 14)، قد تستغرق المزامنة الأولية ما يصل إلى 24 ساعة | نعم (بواسطة Play Services) | | التجاوز ممكن | نعم، مع قسم alternate mode | لا | | قابل للاختبار باستخدام | اختبار apple-app-site-association | اختبار assetlinks.json | | معرف التطبيق مع نموذج | `.`، على سبيل المثال `T84QZS65DQ.com.facebook.Messenger` | بصمة SHA256، على سبيل المثال `E3:F9:E1:E0:CF:99:D0:E5:6A:05:5B:A6: 5E:24:1B:33:99: 7F:CE:A5:24:32: 6B:0C:DD:6E:C1:32: 7E:D0:FD:C1` | | أين تجد معرف التطبيق | يمكن العثور على Team Application Identifier Prefix في حساب المطور على developer.apple.com، و Bundle Identifier هو الاسم الدقيق من داخل مشروع XCode | عند التحميل بالفعل: Google Play Console > إدارة الإصدار > توقيع التطبيق محلياً: `keytool -list -v -keystore -alias -storepass -keypass ` | | اسم القسم الذي يربط التطبيق بالويب | applinks (غير مطلوب لمفاتيح المرور) | `delegate_permission/common.handle_all_urls` (مطلوب لمفاتيح المرور) | | اسم القسم الذي يسمح بمشاركة بيانات الاعتماد بين التطبيق / الويب | webcredentials | `delegate_permission/common.get_login_creds` | | سجل جميع ملفات الارتباط | قم بتمكين النطاق المرتبط وإضافته في بيئة تطوير XCode (إعداد خاصية لإنشاء ملف الاستحقاقات) | عند استخدام Credential Manager API، لا يكون سجل assetlinks.json في البيان (manifest) مطلوباً لمفاتيح المرور (على الرغم من أنه مطلوب لكلمات المرور). عند عدم استخدام Credential Manager API، تحتاج إلى سرد أسماء المضيفين بمدخل `` في AndroidManifest.xml في النشاط المحدد (جزء من الكود المصدري لتطبيق Android). يجب أن يكون `` هو autoVerify=true. | بالنسبة لـ [Flutter](https://www.corbado.com/blog/flutter-passkeys-package)، تنطبق القاعدة الخاصة بـ Android أو iOS. الإعداد الوحيد الخاص بـ [Flutter](https://www.corbado.com/blog/flutter-passkeys-package) هو سجل ملفات الارتباط، حيث يجب عليك إضافة: - لنظام Android: [flutter_deeplinking_enabled إلى AndroidManifest.xml](https://docs.flutter.dev/cookbook/navigation/set-up-app-links) - لنظام iOS: [FlutterDeepLinkingEnabled true إلى Info.plist](https://docs.flutter.dev/cookbook/navigation/set-up-universal-links) ## 7. أمثلة على Relying Party ID صالح وغير صالح وملفات الارتباط كما جربنا بأنفسنا، يمكن أن يكون العمل مع Relying Party IDs والمستويات المختلفة من النطاقات (الفرعية) و CNAMEs مهمة صعبة للغاية، لذلك نقدم أربعة أمثلة مميزة ونشرح سبب وكيفية عملها. لاحظ أن صف جدول CNAME غير مطلوب لمصادقة مفتاح المرور وهو مجرد نتيجة لبحثنا الذي أردنا إضافته. ### 7.1 المثال 1: Relying Party هو النطاق الجذري | **Relying Party ID** | corbado.com | | --------------------------------------- | ------------------------------------------------------------------------------------------------------------------------ | | **الاستحقاقات (iOS فقط)** | webcredentials:corbado.com | | **موقع ملف apple-app-site-association** | [https://corbado.com/.well-known/apple-app-site-association](https://corbado.com/.well-known/apple-app-site-association) | | **موقع ملف assetlinks.json** | [https://corbado.com/.well-known/assetlinks.json](https://corbado.com/.well-known/assetlinks.json) | | **CNAME** | غير متاح | في هذا المثال، يمكن تنزيل ملف `apple-app-site-association` / `assetlinks.json` لـ Corbado.com دون أي مشاكل عند تثبيت / تحديث التطبيق الأصلي، لأن الملف موجود في نفس الموقع مثل Relying Party ID. **يمكن إنشاء مفتاح مرور لـ Relying Party ID.** ### 7.2 المثال 2: Relying Party هو نطاق فرعي وتم تعيين CNAME | Relying Party ID | auth.corbado.com | | --------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------- | | **الاستحقاقات (iOS فقط)** | webcredentials:auth.corbado.com | | **موقع ملف apple-app-site-association** | [https://pro-123.passkeys.eu/.well-known/apple-app-site-association](https://pro-123.passkeys.eu/.well-known/apple-app-site-association) | | **موقع ملف assetlinks.json** | [https://pro-123.passkeys.eu/.well-known/assetlinks.json](https://pro-123.passkeys.eu/.well-known/assetlinks.json) | | **CNAME** | auth.corbado.com => pro-123.passkeys.eu | في هذا المثال، يمكن تنزيل ملف `apple-app-site-association` / `assetlinks.json` لـ auth.corbado.com دون أي مشاكل عند تثبيت / تحديث التطبيق الأصلي، لأن الملف موجود في الموقع الخاص بـ Relying Party ID، حيث يشير CNAME من Relying Party ID إلى الموقع المخزن. **يمكن إنشاء مفتاح مرور لـ Relying Party ID.** ### 7.3 المثال 3: Relying Party هو النطاق الجذري وتم تعيين CNAME | Relying Party ID | corbado.com | | --------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------- | | **الاستحقاقات (iOS فقط)** | webcredentials:corbado.com; webcredentials:auth.corbado.com | | **موقع ملف apple-app-site-association** | [https://pro-123.passkeys.eu/.well-known/apple-app-site-association](https://pro-123.passkeys.eu/.well-known/apple-app-site-association) | | **موقع ملف assetlinks.json** | [https://pro-123.passkeys.eu/.well-known/assetlinks.json](https://pro-123.passkeys.eu/.well-known/assetlinks.json) | | **CNAME** | auth.corbado.com => pro-123.passkeys.eu | في هذا المثال، يمكن تنزيل ملف `apple-app-site-association` / `assetlinks.json` لـ auth.corbado.com دون أي مشاكل عند تثبيت / تحديث التطبيق الأصلي، لأن الملف موجود، بسبب CNAME، في الموقع الذي يتوقعه `auth.corbado.com`. لكن: لا يمكن تنزيل `apple-site-association-file` / `assetlinks.json` لـ corbado.com، عند تثبيت / تحديث التطبيق الأصلي، لأن الملف ليس في `https://corbado.com/.well-known/apple-app-site-association` / `https://corbado.com/.well-known/assetlinks.json`، حيث يتوقع وجوده ولا يوجد CNAME يشير إليه. **لا يمكن إنشاء مفتاح مرور لـ Relying Party ID.** ### 7.4 المثال 4: Relying Party هو نطاق فرعي وتم تعيين استحقاق بدل (Wildcard) | Relying Party ID | auth.corbado.com | | --------------------------------------- | ------------------------------------------------------------------------------------------------------------------------ | | **الاستحقاقات (iOS فقط)** | webcredentials:\*.corbado.com | | **موقع ملف apple-app-site-association** | [https://corbado.com/.well-known/apple-app-site-association](https://corbado.com/.well-known/apple-app-site-association) | | **موقع ملف assetlinks.json** | [https://corbado.com/.well-known/assetlinks.json](https://corbado.com/.well-known/assetlinks.json) | | **CNAME** | غير متاح | في هذا المثال، يمكن تنزيل ملف `apple-app-site-association` لـ corbado.com دون أي مشاكل، عند تثبيت / تحديث التطبيق الأصلي، لأن الملف موجود حيث يُتوقع وجوده ويتطابق استحقاق webcredentials (`*.corbado.com`) مع Relying Party ID (`auth.corbado.com`). لاحظ أن هذا المثال لا يعمل مع Android، حيث أن Android لا يعمل مع أشياء مثل استحقاقات البدل (wildcard). بشكل عام، لا يُنصح بهذه الطريقة لتحديد Relying Party IDs. **يمكن إنشاء مفتاح مرور لـ Relying Party ID.** ## 8. أخطاء Relying Party ID الشائعة وكيفية تجنبها ### 8.1 تغيير Relying Party ID من نطاق فرعي إلى نطاق جذري **الخطأ:** لقد بدأت في التطوير وحددت نطاقاً فرعياً (مثل `login.acme.com`) كـ Relying Party ID الخاص بك. قام المستخدمون الأوائل بإنشاء مفتاح مرور لهذا Relying Party ID. بعد ذلك، تلاحظ أنك بحاجة أيضاً إلى مفاتيح المرور هذه للمصادقة على نطاق فرعي آخر (مثل `app.acme.com`). نظراً لأن أصل المستخدم و Relying Party ID للنطاق الفرعي الجديد لا يتطابقان، لا يمكن للمستخدم تسجيل الدخول باستخدام مفتاح المرور. سيؤدي تغيير Relying Party ID في إعدادات WebAuthn الخاصة بك إلى `acme.com` إلى إبطال جميع مفاتيح المرور الحالية، لأن الأصل الجديد و Relying Party ID المخزن في مفاتيح المرور الحالية لا يتطابقان. **الحل:** تحقق مرة أخرى في البداية عند تحديد Relying Party ID الخاص بك لأن هذا يكون نهائياً تقريباً. إذا كنت غير متأكد وتريد أن تكون جاهزاً للمستقبل، مما يعني أن النطاقات الفرعية الأخرى في المستقبل قد تحتاج إلى مفتاح المرور للمصادقة، نوصي باستخدام النطاق الجذري (مثل acme.com) كـ Relying party ID إلا إذا كان مدرجاً في [قائمة اللواحق العامة](https://publicsuffix.org/learn/). ### 8.2 الاعتماد على Relying Party IDs مختلفة للتطبيق الأصلي وتطبيق الويب **الخطأ:** أنت تقوم بتطوير تطبيق أصلي وتطبيق ويب في وقت واحد. لتسريع الأمور، تستخدم خادمي WebAuthn مختلفين (مع Relying Party IDs مختلفة للتطبيق الأصلي وتطبيق الويب). عندما ينشئ المستخدمون مفاتيح المرور الأولى، يتم تخزين Relying Party ID المعني في مفتاح المرور. السماح بتسجيل الدخول عبر الأجهزة / عبر الأنظمة الأساسية بنفس مفتاح المرور، على سبيل المثال باستخدام مفتاح مرور تم إنشاؤه في تطبيق ويب ومحاولة تسجيل الدخول في تطبيق أصلي، لم يعد ممكناً. سيؤدي دمج خادمي WebAuthn إلى التخلي عن مفاتيح المرور التي تم تسجيلها باستخدام خادم WebAuthn القديم (Relying Party ID القديم) ولن يتمكن المستخدمون من تسجيل الدخول باستخدام مفاتيح المرور هذه. **الحل:** إذا كان لديك تطبيقات متعددة (مثل تطبيق ويب وتطبيق أصلي)، احتفظ دائماً بخادم WebAuthn واحد فقط وحدد Relying Party ID واحداً لجميع تطبيقاتك. يمكن إجراء الربط بين هذه التطبيقات عبر الخطوات الموضحة أعلاه. ### 8.3 ملفات الارتباط غير الصالحة أو التي لا يمكن الوصول إليها **الخطأ:** تبدأ في تطوير تطبيقك، وقمت بتكوين ملفات الارتباط ونشرها على خادمك. لسبب ما، لا تزال تتلقى رسائل خطأ ولا تجد السبب الجذري. **الحل:** قد يكون السبب المحتمل لرسالة الخطأ هو ملف ارتباط مشوه أو لا يمكن الوصول إليه. قبل نشر أي ملف ارتباط إلى خادم، نوصي بشدة بالتحقق من صحة وإمكانية الوصول (غالباً ما تكون هذه الملفات خلف [VPN قوي](https://cybernews.com/best-vpn/most-secure-vpns/) أو جدار حماية يمنع الوصول المناسب لزواحف Apple و Google) لملف ارتباط عبر الأدوات المقدمة لـ [iOS ](https://branch.io/resources/aasa-validator/) و Android. ### 8.4 ملف apple-app-site-association لم يتم تخزينه مؤقتاً بواسطة Apple CDN بعد **الخطأ:** لقد قمت بنشر ملف apple-app-site-association الخاص بك على خادمك وتريد البدء فوراً في إنشاء مفتاح مرور على جهاز الاختبار الخاص بك. لسبب ما، لا يمكنك إنشاء مفتاح المرور وتتلقى رسائل خطأ. **الحل:** السبب وراء رسائل الخطأ هذه هو أن أجهزة iOS تقوم بتنزيل ملف `apple-app-site-association` للتحقق من Relying Party. للقيام بذلك، لا ترسل أجهزة iOS طلباً مباشراً إلى خادمك بل تستخدم CDN بدلاً من ذلك. يقوم كل من الجهاز و CDN بتخزين ملف `apple-app-site-association` مؤقتاً بعد استرداده بنجاح. نظراً لوظيفة التخزين المؤقت هذه، لا تنعكس التغييرات الجديدة في ملف `apple-app-site-association` الخاص بك مباشرة في تطبيقك. يمكن أن يستغرق الأمر ما يصل إلى 24 ساعة حتى تقوم CDN بتخزين ملف `apple-app-site-association` مؤقتاً. لتجاوز هذا القيد أثناء التطوير، يمكنك إضافة `?mode=developer` إلى Relying Party ID وتعطيل التخزين المؤقت تماماً (على سبيل المثال، سيكون Relying Party ID هو `acme.com?mode=developer`). ### 8.5 عدم توافق محاكي Android وإصدار API **الخطأ:** تبدأ في تطوير تطبيق Android وتريد اختباره على محاكي Android. لسبب ما، تتلقى رسائل خطأ، على الرغم من أنك قمت بإعداد محاكي Android بشكل صحيح ويبدو أن التطبيقات الأخرى تعمل بسلاسة عليه. **الحل:** تلعب إصدارات Android ودعم Play Store وإصدارات API دوراً كبيراً عند اختبار تطبيق مفتاح مرور. بالإضافة إلى ذلك، يجب أن تكون مسجلاً الدخول إلى حساب Google. يرجى الرجوع إلى قسم استكشاف الأخطاء وإصلاحها للحصول على التفاصيل. ## 9. التوصية ### 9.1 توصية عامة توصيتنا العامة هي اختيار Relying Party ID الخاص بك بعناية بناءً على مشهد تطبيقك ومتطلباتك. أدناه، قمنا بجمع حالات الاستخدام الأكثر شيوعاً، ولكن توصيتنا العامة هي أنه يجب عليك **أن تهدف إلى اختيار النطاق الجذري كـ Relying Party ID الخاص بك** وتكوين المصادقة الخاصة بك بهذه الطريقة. مع Corbado، قمنا أيضاً بتكوين ذلك مسبقاً من أجلك (حيث يعد ذلك جزءاً من نهجنا لتقديم مصادقة سلسة بمفتاح المرور لجميع الإعدادات التقنية. تم إعداد مكونات واجهة المستخدم و SDKs الخاصة بنا لاستخدامها مع النطاق الجذري كـ Relying Party ID). | الحالة | التوصية | | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **أ) لديك نطاق جذري واحد:**

مثال: acme.com

جميع التطبيقات والمصادقة تعمل على هذا النطاق الجذري أو نطاقاته الفرعية | ✔️ اختر النطاق الجذري كـ Relying Party ID الخاص بك لأن هذا لن يسبب أي مشاكل لتطبيقات الويب أو التطبيقات الأصلية. | | **ب) لديك نطاقات جذرية متعددة:**

مثال: kayak.com، kayak.co.uk، kayak.de

أنت تخدم المستخدمين من نطاقات دولية مختلفة المستوى الأعلى. Kayak.com للولايات المتحدة و kayak.co.uk للمملكة المتحدة أو لديك نطاقات جذرية مختلفة تماماً يجب أن تسمح لنفس المستخدمين بتسجيل الدخول بنفس مفاتيح المرور. | ⚠️ في تطبيقات الويب الخاصة بك، تتطلب مشاركة مفاتيح المرور تكوين طلبات الأصل ذات الصلة (Related Origin Requests) عبر `.well-known/webauthn` للسماح لأصول محددة باستخدام RP ID مشترك (يختلف دعم المتصفحات؛ تحقق من التوافق). بدلاً من ذلك، اختر نطاق مصادقة جذري مشترك.

✔️ يمكنك ربط تطبيقاتك الأصلية بأي عدد من النطاقات الجذرية طالما كان لديك تحكم في ملفات الارتباط الجذرية.

❌ في حال كنت ترغب لاحقاً في الترحيل إلى نطاق جذري آخر لاستضافة موقعك الإلكتروني، فلن تتمكن من استخدام مفاتيح المرور التي تم إنشاؤها بالفعل، لأنك ستحتاج إلى تغيير العلامة التجارية وتغيير النطاق (Relying Party ID). | | **ج) ليس لديك نطاق جذري حتى الآن، أنت تعمل على الواجهة الخلفية فقط أو على نطاق فرعي عام. هناك بعض الحالات التي قد يحدث فيها هذا:**

1. أنت تعمل على نطاق فرعي متاح بحرية، حيث لا يكون النطاق الجذري تحت سيطرتك (النطاق الجذري مدرج في [https://publicsuffix.org/](https://publicsuffix.org/)) على سبيل المثال عناوين URL لـ CDN

2. أنت تعمل على تطبيق أصلي. | ❌ في النطاقات الفرعية العامة، لا يمكنك التحكم في ملفات الارتباط على المستوى الجذري للنطاق الجذري، لذلك لن تعمل مفاتيح المرور بشكل أصلي.

⚠️ الطريقة الوحيدة لإصلاح هذا لبعض الخدمات هي التغيير إلى خطة مدفوعة، حيث يمكنك تحديد CNAME أو الحصول على نطاق جذري مخصص لنفسك. | ### 9.2 التوصية عند استخدام Corbado فيما يلي، نقدم شجرة قرارات محددة جداً من شأنها أن تساعدك في تحديد Relying Party ID الصحيح وكيفية التعامل / استضافة ملفات الارتباط عند استخدام Corbado كحل لمفاتيح المرور الخاصة بك. القرار الأول هو ما إذا كنت في بيئة تطوير أو بيئة إنتاج. المستوى التالي من القرار الذي يتعين عليك اتخاذه يعتمد على مشهد تطبيقك: هل لديك فقط تطبيق أصلي أو تطبيق أصلي وتطبيق ويب. #### أ) التطوير بالنسبة لبيئة التطوير، نفترض أنك ترغب في البدء في التطوير والاختبار بسرعة. يمكن تغيير Relying Party ID لاحقاً إذا كنت ترغب في إطلاقه للعمل المباشر. ##### أ1) التطبيق الأصلي فقط - قم بتعيين Relying Party ID = `pro-XXX.frontendapi.cloud.corbado.io` (القيمة الافتراضية) - يستضيف Corbado ملف الارتباط نيابة عنك - لا توجد مهام DNS مطلوبة منك ##### أ2) التطبيق الأصلي وتطبيق الويب ليس من السهل اختبار كل من تطبيق الويب والتطبيق الأصلي في نفس الوقت. **الخيار 1:** إما أن تقوم بتعيين Relying Party ID = `pro-XXX.frontendapi.cloud.corbado.io` (التطبيق الأصلي يعمل) أو قم بتعيين Relying Party ID = `localhost` (تطبيق الويب يعمل). **الخيار 2:** الحل الوحيد لعمل التطبيق الأصلي وتطبيق الويب في نفس الوقت هو استخدام بروكسي عكسي محلي (إنه حل تحايلي نوعاً ما): - قم بتعيين Relying Party ID = `acme-dev.com` - قم بتعيين CNAME من `acme-dev.com` => `pro-XXX.frontendapi.cloud.corbado.io` - أضف إدخال محلي في `/etc/hosts` كـ `localhost acme-dev.com` - أضف بروكسي عكسي (nginx) مع قاعدة لـ `acme-dev.com` => `localhost:3000` (كمثال) #### ب) الإنتاج في بيئة الإنتاج، يجب عليك أن تقرر ما إذا كنت توافق على استخدام نطاق فرعي كـ Relying Party ID (مثل `auth.acme.com`) أو ما إذا كنت تريد نطاقاً جذرياً كـ Relying Party ID (مثل `acme.com`). ##### ب1) النطاق الفرعي كـ Relying Party ID ###### ب1.1) التطبيق الأصلي فقط - قم بتعيين Relying Party ID = `auth.acme.com` - يستضيف Corbado ملف الارتباط نيابة عنك - قم بتعيين CNAME من `auth.acme.com` => `pro-XXX.frontendapi.cloud.corbado.io` ###### ب1.2) التطبيق الأصلي وتطبيق الويب - قم بتعيين Relying Party ID = `auth.acme.com` - يستضيف Corbado ملف الارتباط نيابة عنك - قم بتعيين CNAME من `auth.acme.com` => `pro-XXX.frontendapi.cloud.corbado.io` (مطلوب أيضاً لعمل ملفات تعريف الارتباط إذا كنت تستخدم إدارة الجلسات في Corbado) ##### ب2) النطاق الجذري كـ Relying Party ID ###### ب2.1) التطبيق الأصلي فقط - قم بتعيين Relying Party ID = `acme.com` - استضف ملف الارتباط بنفسك على خادمك الخاص في `acme.com/.well-known/` - لا توجد مهام DNS مطلوبة منك ###### ب2.2) التطبيق الأصلي وتطبيق الويب - قم بتعيين Relying Party ID = `acme.com` - استضف ملف الارتباط بنفسك على خادمك الخاص في `acme.com/.well-known/` - إذا كنت تستخدم إدارة الجلسات في Corbado، فأنت بحاجة إلى تعيين CNAME من `auth.acme.com` \=> `pro-XXX.frontendapi.cloud.corbado.io` لجعل ملفات تعريف الارتباط تعمل (هذا الـ CNAME غير مطلوب لـ Relying Party ID ولكنه خاص بإدارة الجلسة فقط) تلخص شجرة القرارات التالية جميع مسارات التكوين. ## 10. الخلاصة يعد Relying Party ID حجر الزاوية في WebAuthn والمصادقة المستندة إلى مفتاح المرور ويوفر مقاومة قوية للتصيد الاحتيالي. إن تكوينه بشكل صحيح وفهم تعقيدات مطابقة النطاق وضمان النشر الصحيح للتطبيقات الأصلية أمر بالغ الأهمية. أوضح لك هذا المنشور كيفية إعدادها بشكل صحيح وكيفية التعامل مع الأخطاء المختلفة. بمجرد أن يكون تكوين rpID الخاص بك قوياً، ركز على تحسين تدفقات إنشاء مفتاح المرور وتدفقات تسجيل الدخول بمفتاح المرور لدفع التبني الحقيقي. لمزيد من الرؤى حول إعداد مفاتيح المرور للتطبيق الأصلي، نوصي بالقراءة حول مفاتيح المرور في [Flutter](https://www.corbado.com/blog/flutter-passkeys-package). إذا كانت لديك أسئلة إضافية أو تحتاج إلى مساعدة، فلا تتردد في [التواصل معنا](https://bit.ly/passkeys-community). ## الأسئلة الشائعة ### كيف يمنع Relying Party ID التصيد الاحتيالي في مصادقة مفاتيح المرور؟ يقارن المصدق الأصل الفعلي للمتصفح مع Relying Party ID المخزن في مفتاح المرور. إذا استضاف مهاجم موقعاً مزيفاً على نطاق مختلف، فإن عدم تطابق الأصل يتسبب في فشل المصادقة تلقائياً، حتى إذا ادعى التحدي المزور وجود RP ID شرعي. هذا الارتباط يعني أنه لا يمكن استخدام مفتاح مرور مسجل في paypal.com على نطاق مشابه مثل paybal.com. ### ماذا يحدث إذا قمت بتغيير Relying Party ID لـ WebAuthn بعد أن قام المستخدمون بالفعل بتسجيل مفاتيح المرور؟ يؤدي تغيير RP ID إلى إبطال جميع مفاتيح المرور الحالية لأن RP ID المخزن في كل بيانات اعتماد لن يتطابق مع القيمة الجديدة. الاستثناءات الوحيدة هي عندما يكون RP ID الجديد نطاقاً فرعياً من القديم أو عندما يتم تكوين طلبات الأصل ذات الصلة عبر `.well-known/webauthn`. اختر النطاق الجذري كـ RP ID منذ البداية لتجنب هذه المشكلة التي لا رجعة فيها. ### لماذا لا يعمل مفتاح مرور iOS الخاص بي فور نشر ملف apple-app-site-association؟ لا يقوم نظام iOS بجلب ملف apple-app-site-association مباشرة من خادمك. بل يستخدم شبكة توصيل المحتوى (CDN) الخاصة بشركة Apple، والتي قد تستغرق ما يصل إلى 24 ساعة لتخزين ملف تم نشره أو تحديثه حديثاً. أثناء التطوير، أضف `?mode=developer` إلى Relying Party ID لتجاوز التخزين المؤقت بالكامل. ### هل يجب أن أستخدم نطاقاً فرعياً أم نطاقاً جذرياً كـ Relying Party ID لمفاتيح المرور الخاصة بي؟ يوصى باستخدام النطاق الجذري (مثل acme.com) لأن مفاتيح المرور التي تم إنشاؤها على أي نطاق فرعي يمكنها المصادقة عبر جميع النطاقات الفرعية لذلك الجذر. يقيد RP ID الخاص بالنطاق الفرعي استخدام مفتاح المرور على هذا النطاق الفرعي وفروعه، مما قد يؤدي إلى كسر التدفقات عبر النطاقات الفرعية لاحقاً. إذا كان لديك نطاقات جذرية متعددة مثل acme.com وacme.co.uk، فقم بتكوين طلبات الأصل ذات الصلة عبر `.well-known/webauthn` للسماح بإعادة استخدام مفتاح المرور عبرها.