Relying Party ID (rpID) لتقنية WebAuthn ومفاتيح المرور: النطاقات والتطبيقات الأصلية

ملخص Passkeys. إرشادات عملية وأنماط إطلاق ومؤشرات KPI لبرامج passkeys.

احصل على الملخص

أصبحت مصادقة مفاتيح المرور هي المعيار الجديد بسرعة حيث تقوم شركات التكنولوجيا العملاقة مثل TikTok و GitHub و WhatsApp و X (Twitter) و LinkedIn و Amazon بطرحها أو قامت بذلك بالفعل. من الواضح أن عالم التكنولوجيا يدرك أهمية المصادقة البسيطة والآمنة.

بعيداً عن تجربة المستخدم السلسة للمصادقة باستخدام Face ID أو Touch ID أو Windows Hello، توفر مفاتيح المرور أماناً لا مثيل له مقارنة بطرق المصادقة التقليدية مثل كلمات المرور. إحدى الميزات البارزة هي مقاومتها القوية للتصيد الاحتيالي.

جرّب passkeys في عرض مباشر.

جرّب passkeys

هجوم التصيد الاحتيالي هو هجوم يتم فيه خداع الضحية لتقديم بيانات الاعتماد لموقع مزيف يحاكي الموقع الأصلي. على سبيل المثال، تخيل تلقي رسالة بريد إلكتروني تبدو وكأنها من البنك الذي تتعامل معه، تطلب منك تسجيل الدخول. تنقر على الرابط، ويبدو الموقع الويب شرعياً، فتقوم بإدخال بيانات الاعتماد الخاصة بك ويمكن للمهاجم استخدامها لتسجيل الدخول إلى الموقع الأصلي. أصبحت هذه مشكلة متزايدة في العصر الرقمي، وحتى الشركات الكبرى مثل Okta (مزود مصادقة!) أو Retool وقعت ضحية لهجمات التصيد الموجه (spear-phishing)، وهو شكل خاص من التصيد حيث يتم استهداف ضحايا محددين بشكل خاص بحيل تصيد شخصية جداً، مما يؤكد الحاجة إلى تدابير أمنية قوية.

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

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

أثناء عملية التسجيل (sign-up)، يتم إنشاء مفتاح مرور جديد لخدمة عبر الإنترنت (Relying Party) عبر تطبيق ويب أو تطبيق أصلي. في هذه العملية، يتم تخزين النطاق (Relying Party ID) الذي تم إنشاء مفتاح المرور من أجله داخل مفتاح المرور.

يسمح هذا لعملية المصادقة (login) بالتحقق مما إذا كانت الخدمة عبر الإنترنت (Relying Party)، التي ينتمي إليها تطبيق الويب أو التطبيق الأصلي، تتطابق مع Relying Party ID المخزن في مفتاح المرور.

فيما يلي، سنرى بالتفصيل كيف تعمل عملية مطابقة النطاق وكيف يتم تأمين التطبيقات الأصلية بشكل خاص.

Relying Party ID هو في الأساس نطاق مخزن داخل مفتاح المرور، مما يضمن أن مفتاح المرور يعمل فقط إذا كان عنوان URL الحالي للمتصفح (أصل المستخدم الذي يتم إرساله تلقائياً في كل طلب) يتطابق معه (انظر نهج التطبيق الأصلي أدناه). إنه مكون حاسم في مواصفات WebAuthn، والتي يمكنك التعمق فيها هنا. يمكن أن يكون Relying Party ID هو النطاق الجذري (مثل corbado.com) أو نطاقاً فرعياً (auth.corbado.com). لا يمكنك تخزين النطاق الجذري كـ Relying Party ID إذا كان مدرجاً في قائمة اللواحق العامة (ابحث عن القائمة والمكتبات لاكتشاف اللواحق العامة هنا). سيؤدي تغيير 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 (العمود الثاني) يُسمح له بالوصول إلى النطاق الأصل الخاص به:

فيما يلي، ترى PublicKeyCredentialCreationOptions الذي تم تحليله:

{
    "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 وهي عبارة عن موقع ويب مزيف يحاول سرقة بيانات اعتماد PayPal الخاصة بك لتسجيل الدخول باسمك وإرسال الأموال إلى حساب المهاجم. تتم استضافة هذا الموقع المزيف لـ PayPal على النطاق 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:<SHA256_fingerprint>. على iOS، أصل WebAuthn هو أصل الويب الخاص بـ RP (مثل https://paypal.com). في كلتا الحالتين، يتم التحقق من الثقة بين تطبيقك الأصلي والخادم عبر ملف الارتباط المقابل (انظر أدناه). للحصول على معلومات مفصلة حول كيفية عمل التحقق من الأصل للتطبيقات الأصلية، راجع دليلنا المخصص حول التحقق من أصل WebAuthn للتطبيقات الأصلية.

انضم إلى مجتمع Passkeys للحصول على التحديثات والدعم.

انضم

لتنفيذ مفاتيح المرور في تطبيق أصلي، يمكن للمطور أن يقرر بين إضافتها عبر WebView أو بشكل أصلي. دعونا نفحص فوائد وعيوب كلا النهجين فيما يلي.

يعني استخدام 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 في سياق مفاتيح المرور إذا كنت لا تريد تكاملاً أصلياً.

اطلع على عدد الأشخاص الذين يستخدمون passkeys فعلياً.

عرض بيانات الاعتماد

يتضمن التكامل الأصلي بناء وظيفة مفتاح المرور مباشرة في تطبيق iOS أو Android باستخدام واجهات برمجة التطبيقات والمكتبات الخاصة بالنظام الأساسي. توفر هذه الطريقة تجربة مستخدم أكثر سلاسة، حيث ليست هناك حاجة للانتقال بين التطبيق الأصلي و WebView. كما أنها تسمح بأداء أفضل ومظهر وشعور أكثر تناسقاً. من وجهة نظر أمنية، يمكن أن يوفر التكامل الأصلي حماية معززة ضد أنواع معينة من الهجمات، خاصة عند دمجه مع ميزات الأمان الخاصة بالنظام الأساسي. ومع ذلك، يمكن أن يكون جهد التنفيذ أعلى، حيث يحتاج المطورون إلى كتابة وصيانة رموز منفصلة لكل نظام أساسي (Android و iOS). بالإضافة إلى ذلك، قد يتطلب البقاء محدثاً بأحدث مواصفات مفتاح المرور / WebAuthn تحديثات تطبيق أكثر تواتراً.

فيما يلي، نركز على التكامل الأصلي لمفتاح المرور.

اطلع على عدد الأشخاص الذين يستخدمون passkeys فعلياً.

عرض بيانات الاعتماد

تمثل التطبيقات الأصلية (مثل تطبيقات iOS أو Android) تحدياً مقارنة بتطبيقات الويب. على عكس تطبيقات الويب، لا يوجد عنوان URL للمتصفح لمطابقته مع Relying Party ID. ومع ذلك، لضمان نفس المستوى من الأمان، يتم توصيل النطاقات بالتطبيقات الأصلية عبر ملفات الارتباط (association files)، بحيث يتم إنشاء الثقة بين النطاق والتطبيق الأصلي.

هذا مهم بشكل خاص إذا تم إنشاء مفتاح مرور على تطبيق ويب ويجب استخدامه لنفس Relying Party ID في تطبيق أصلي (والعكس صحيح).

يستخدم iOS ملف apple-app-site-association. يحتوي هذا الملف على استحقاقات مختلفة (entitlements)، ولكن بالنسبة لـ WebAuthn ومفاتيح المرور، فإن استحقاق webcredentials مهم.

{
    "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://<Relying Party ID>/.well-known/apple-app-site-association).

انظر إلى مثال حي هنا.

يستخدم Android ملف assetlinks.json، والذي، مثل نظيره في iOS، يتطلب تكوينات معينة لـ WebAuthn ومفاتيح المرور.

[
    {
        "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.

انظر إلى مثال حي هنا.

لكي تعمل تطبيقات Android، يجب تخزين ملف assetlinks.json ضمن دليل /.well-known الخاص بـ Relying Party ID (https://<Relying Party ID>/.well-known/assetlinks.json - لذا فهو يشبه إلى حد كبير الموجود على iOS).

تحقق من منشور المدونة هذا لرؤية نموذج تنفيذ يشارك مفاتيح المرور بين تطبيق Android / iOS أصلي وتطبيق ويب.

اختبر تدفقات passkey في Passkeys Debugger.

جرّب مجاناً

تبدو عملية إنشاء الثقة بين تطبيق 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.

Igor Gjorgjioski

Head of Digital Channels & Platform Enablement, VicRoads

We hit 80% mobile passkey activation across 5M+ users without replacing our IDP.

See how VicRoads scaled passkeys to 5M+ users — alongside their existing IDP.

Read the case study

تبدو عملية إنشاء الثقة بين تطبيق Android وتطبيق الويب كما يلي:

1. يجب على مطور تطبيق Android تحديد قائمة بالنطاقات التي يريد ربطها بتطبيق Android. يتم تخزين هذه النطاقات كأهداف مع مساحة الاسم web في ملف assetlinks.json. للإعلان عن أن تطبيقات Android وتطبيقات الويب تشترك في بيانات الاعتماد، يجب تحديد delegate_permission/common.get_login_creds. ابحث عن التفاصيل هنا.

2. إذا تم إنشاء مفتاح مرور داخل تطبيق Android، يتحقق تطبيق Android مما إذا كان Relying Party ID مرتبطاً بتطبيق Android عن طريق التحقق من assetlinks.json:

• هل يوجد ملف assetlinks.json لـ Relying Party ID هذا على https://<Relying Party ID>./well-known/assetlinks.json
• هل تطبيق Android محدد بشكل صحيح كهدف.

3. إذا وفقط إذا أمكن الإجابة على كلا السؤالين بنعم، يمكن إنشاء مفتاح مرور داخل تطبيق Android.

يقارن الرسم البياني أدناه عمليات إنشاء الثقة هذه جنباً إلى جنب.

اشترك في Passkeys Substack للحصول على آخر الأخبار.

اشترك

فيما يلي، نقدم نظرة عامة مفصلة على الإعدادات المختلفة المطلوبة لإعداد مصادقة مفتاح المرور بشكل صحيح للتطبيقات الأصلية.

بالنسبة لـ Flutter، تنطبق القاعدة الخاصة بـ Android أو iOS. الإعداد الوحيد الخاص بـ Flutter هو سجل ملفات الارتباط، حيث يجب عليك إضافة:

• لنظام Android: flutter_deeplinking_enabled إلى AndroidManifest.xml
• لنظام iOS: FlutterDeepLinkingEnabled true إلى Info.plist

كما جربنا بأنفسنا، يمكن أن يكون العمل مع Relying Party IDs والمستويات المختلفة من النطاقات (الفرعية) و CNAMEs مهمة صعبة للغاية، لذلك نقدم أربعة أمثلة مميزة ونشرح سبب وكيفية عملها.

لاحظ أن صف جدول CNAME غير مطلوب لمصادقة مفتاح المرور وهو مجرد نتيجة لبحثنا الذي أردنا إضافته.

في هذا المثال، يمكن تنزيل ملف apple-app-site-association / assetlinks.json لـ Corbado.com دون أي مشاكل عند تثبيت / تحديث التطبيق الأصلي، لأن الملف موجود في نفس الموقع مثل Relying Party ID.

يمكن إنشاء مفتاح مرور لـ Relying Party ID.

في هذا المثال، يمكن تنزيل ملف apple-app-site-association / assetlinks.json لـ auth.corbado.com دون أي مشاكل عند تثبيت / تحديث التطبيق الأصلي، لأن الملف موجود في الموقع الخاص بـ Relying Party ID، حيث يشير CNAME من Relying Party ID إلى الموقع المخزن.

يمكن إنشاء مفتاح مرور لـ Relying Party ID.

في هذا المثال، يمكن تنزيل ملف 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.

في هذا المثال، يمكن تنزيل ملف apple-app-site-association لـ corbado.com دون أي مشاكل، عند تثبيت / تحديث التطبيق الأصلي، لأن الملف موجود حيث يُتوقع وجوده ويتطابق استحقاق webcredentials (*.corbado.com) مع Relying Party ID (auth.corbado.com). لاحظ أن هذا المثال لا يعمل مع Android، حيث أن Android لا يعمل مع أشياء مثل استحقاقات البدل (wildcard). بشكل عام، لا يُنصح بهذه الطريقة لتحديد Relying Party IDs.

يمكن إنشاء مفتاح مرور لـ Relying Party ID.

انضم إلى مجتمع Passkeys للحصول على التحديثات والدعم.

انضم

الخطأ:

لقد بدأت في التطوير وحددت نطاقاً فرعياً (مثل 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 إلا إذا كان مدرجاً في قائمة اللواحق العامة.

الخطأ:

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

الحل:

إذا كان لديك تطبيقات متعددة (مثل تطبيق ويب وتطبيق أصلي)، احتفظ دائماً بخادم WebAuthn واحد فقط وحدد Relying Party ID واحداً لجميع تطبيقاتك. يمكن إجراء الربط بين هذه التطبيقات عبر الخطوات الموضحة أعلاه.

الخطأ:

تبدأ في تطوير تطبيقك، وقمت بتكوين ملفات الارتباط ونشرها على خادمك. لسبب ما، لا تزال تتلقى رسائل خطأ ولا تجد السبب الجذري.

الحل:

قد يكون السبب المحتمل لرسالة الخطأ هو ملف ارتباط مشوه أو لا يمكن الوصول إليه. قبل نشر أي ملف ارتباط إلى خادم، نوصي بشدة بالتحقق من صحة وإمكانية الوصول (غالباً ما تكون هذه الملفات خلف VPN قوي أو جدار حماية يمنع الوصول المناسب لزواحف Apple و Google) لملف ارتباط عبر الأدوات المقدمة لـ iOS و Android.

الخطأ:

لقد قمت بنشر ملف 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).

الخطأ:

تبدأ في تطوير تطبيق Android وتريد اختباره على محاكي Android. لسبب ما، تتلقى رسائل خطأ، على الرغم من أنك قمت بإعداد محاكي Android بشكل صحيح ويبدو أن التطبيقات الأخرى تعمل بسلاسة عليه.

الحل:

تلعب إصدارات Android ودعم Play Store وإصدارات API دوراً كبيراً عند اختبار تطبيق مفتاح مرور. بالإضافة إلى ذلك، يجب أن تكون مسجلاً الدخول إلى حساب Google. يرجى الرجوع إلى قسم استكشاف الأخطاء وإصلاحها للحصول على التفاصيل.

توصيتنا العامة هي اختيار Relying Party ID الخاص بك بعناية بناءً على مشهد تطبيقك ومتطلباتك. أدناه، قمنا بجمع حالات الاستخدام الأكثر شيوعاً، ولكن توصيتنا العامة هي أنه يجب عليك أن تهدف إلى اختيار النطاق الجذري كـ Relying Party ID الخاص بك وتكوين المصادقة الخاصة بك بهذه الطريقة. مع Corbado، قمنا أيضاً بتكوين ذلك مسبقاً من أجلك (حيث يعد ذلك جزءاً من نهجنا لتقديم مصادقة سلسة بمفتاح المرور لجميع الإعدادات التقنية. تم إعداد مكونات واجهة المستخدم و SDKs الخاصة بنا لاستخدامها مع النطاق الجذري كـ Relying Party ID).

فيما يلي، نقدم شجرة قرارات محددة جداً من شأنها أن تساعدك في تحديد Relying Party ID الصحيح وكيفية التعامل / استضافة ملفات الارتباط عند استخدام Corbado كحل لمفاتيح المرور الخاصة بك.

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

بالنسبة لبيئة التطوير، نفترض أنك ترغب في البدء في التطوير والاختبار بسرعة. يمكن تغيير Relying Party ID لاحقاً إذا كنت ترغب في إطلاقه للعمل المباشر.

• قم بتعيين Relying Party ID = pro-XXX.frontendapi.cloud.corbado.io (القيمة الافتراضية)
• يستضيف Corbado ملف الارتباط نيابة عنك
• لا توجد مهام DNS مطلوبة منك

ليس من السهل اختبار كل من تطبيق الويب والتطبيق الأصلي في نفس الوقت.

الخيار 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).

• قم بتعيين Relying Party ID = auth.acme.com
• يستضيف Corbado ملف الارتباط نيابة عنك
• قم بتعيين CNAME من auth.acme.com => pro-XXX.frontendapi.cloud.corbado.io

• قم بتعيين Relying Party ID = auth.acme.com
• يستضيف Corbado ملف الارتباط نيابة عنك
• قم بتعيين CNAME من auth.acme.com => pro-XXX.frontendapi.cloud.corbado.io (مطلوب أيضاً لعمل ملفات تعريف الارتباط إذا كنت تستخدم إدارة الجلسات في Corbado)

• قم بتعيين Relying Party ID = acme.com
• استضف ملف الارتباط بنفسك على خادمك الخاص في acme.com/.well-known/<association file>
• لا توجد مهام DNS مطلوبة منك

• قم بتعيين Relying Party ID = acme.com
• استضف ملف الارتباط بنفسك على خادمك الخاص في acme.com/.well-known/<association file>
• إذا كنت تستخدم إدارة الجلسات في Corbado، فأنت بحاجة إلى تعيين CNAME من auth.acme.com => pro-XXX.frontendapi.cloud.corbado.io لجعل ملفات تعريف الارتباط تعمل (هذا الـ CNAME غير مطلوب لـ Relying Party ID ولكنه خاص بإدارة الجلسة فقط)

تلخص شجرة القرارات التالية جميع مسارات التكوين.

يعد Relying Party ID حجر الزاوية في WebAuthn والمصادقة المستندة إلى مفتاح المرور ويوفر مقاومة قوية للتصيد الاحتيالي. إن تكوينه بشكل صحيح وفهم تعقيدات مطابقة النطاق وضمان النشر الصحيح للتطبيقات الأصلية أمر بالغ الأهمية. أوضح لك هذا المنشور كيفية إعدادها بشكل صحيح وكيفية التعامل مع الأخطاء المختلفة. بمجرد أن يكون تكوين rpID الخاص بك قوياً، ركز على تحسين تدفقات إنشاء مفتاح المرور وتدفقات تسجيل الدخول بمفتاح المرور لدفع التبني الحقيقي. لمزيد من الرؤى حول إعداد مفاتيح المرور للتطبيق الأصلي، نوصي بالقراءة حول مفاتيح المرور في Flutter.

إذا كانت لديك أسئلة إضافية أو تحتاج إلى مساعدة، فلا تتردد في التواصل معنا.

حول Corbado

Corbado هي Passkey Intelligence Platform لفِرَق CIAM التي تُدير المصادقة الاستهلاكية على نطاق واسع. نُمكّنك من رؤية ما لا تستطيع سجلات IDP وأدوات التحليل العامة إظهاره: أي الأجهزة وإصدارات أنظمة التشغيل والمتصفحات ومديري بيانات الاعتماد تدعم passkeys، ولماذا لا تتحوّل عمليات التسجيل إلى عمليات دخول، وأين يفشل تدفق WebAuthn، ومتى يُعطّل تحديث نظام التشغيل أو المتصفح تسجيل الدخول بصمت — كل ذلك دون استبدال Okta أو Auth0 أو Ping أو Cognito أو IDP الداخلي لديك. منتجان: Corbado Observe يُضيف observability للـ passkeys وأي طريقة دخول أخرى. Corbado Connect يُقدّم managed passkeys مع تحليلات مدمجة (إلى جانب IDP الخاص بك). تُشغّل VicRoads passkeys لأكثر من 5 ملايين مستخدم مع Corbado (تفعيل passkey بنسبة +80%). تحدث مع خبير Passkey →

يقارن المصدق الأصل الفعلي للمتصفح مع Relying Party ID المخزن في مفتاح المرور. إذا استضاف مهاجم موقعاً مزيفاً على نطاق مختلف، فإن عدم تطابق الأصل يتسبب في فشل المصادقة تلقائياً، حتى إذا ادعى التحدي المزور وجود RP ID شرعي. هذا الارتباط يعني أنه لا يمكن استخدام مفتاح مرور مسجل في paypal.com على نطاق مشابه مثل paybal.com.

يؤدي تغيير RP ID إلى إبطال جميع مفاتيح المرور الحالية لأن RP ID المخزن في كل بيانات اعتماد لن يتطابق مع القيمة الجديدة. الاستثناءات الوحيدة هي عندما يكون RP ID الجديد نطاقاً فرعياً من القديم أو عندما يتم تكوين طلبات الأصل ذات الصلة عبر .well-known/webauthn. اختر النطاق الجذري كـ RP ID منذ البداية لتجنب هذه المشكلة التي لا رجعة فيها.

لا يقوم نظام iOS بجلب ملف apple-app-site-association مباشرة من خادمك. بل يستخدم شبكة توصيل المحتوى (CDN) الخاصة بشركة Apple، والتي قد تستغرق ما يصل إلى 24 ساعة لتخزين ملف تم نشره أو تحديثه حديثاً. أثناء التطوير، أضف ?mode=developer إلى Relying Party ID لتجاوز التخزين المؤقت بالكامل.

يوصى باستخدام النطاق الجذري (مثل acme.com) لأن مفاتيح المرور التي تم إنشاؤها على أي نطاق فرعي يمكنها المصادقة عبر جميع النطاقات الفرعية لذلك الجذر. يقيد RP ID الخاص بالنطاق الفرعي استخدام مفتاح المرور على هذا النطاق الفرعي وفروعه، مما قد يؤدي إلى كسر التدفقات عبر النطاقات الفرعية لاحقاً. إذا كان لديك نطاقات جذرية متعددة مثل acme.com وacme.co.uk، فقم بتكوين طلبات الأصل ذات الصلة عبر .well-known/webauthn للسماح بإعادة استخدام مفتاح المرور عبرها.