مفاتيح المرور و iframes: كيف ننشئ مفتاح مرور ونسجل الدخول به؟

مفتاح الرموز
✅ = مدعوم ❌ = غير مدعوم

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

إحدى الحالات التي نُسأل عنها باستمرار هي كيفية عمل مفاتيح المرور في iframes، حيث تُستخدم iframes على نطاق واسع في تطوير الويب الحديث لتضمين محتوى من مصادر مختلفة بسلاسة. في سياق مفاتيح المرور و WebAuthn، تأتي iframes مع مجموعة من التحديات الخاصة بها، خاصة فيما يتعلق بالأمان وتفاعلات المستخدم.

Integrate passkeys as Payment Provider via 3rd party SDK.

Read article

يقدم هذا المقال دليلًا شاملًا حول استخدام مفاتيح المرور و WebAuthn في iframes. سوف نقوم بما يلي:

• استكشاف القدرات الحالية
• مناقشة دعم iframe عبر المصادر
• تسليط الضوء على فوائد تكامل iframe
• تقديم دليل تنفيذ خطوة بخطوة

بنهاية هذا المقال، سيكون لديك فهم واضح لكيفية الاستفادة من مفاتيح المرور داخل iframes.

iframes، أو الإطارات المضمنة، هي عناصر HTML تسمح للمطورين بتضمين مستند HTML آخر داخل المستند الحالي. تُستخدم هذه الإمكانية على نطاق واسع لدمج محتوى من مصادر خارجية، مثل مقاطع الفيديو والخرائط وصفحات الويب الأخرى، في موقع ويب.

دعونا نلقي نظرة على الأنواع المختلفة من iframes.

Subscribe to our Passkeys Substack for the latest news.

Subscribe

iframe الأساسي هو النوع الأكثر استخدامًا. يقوم ببساطة بتضمين محتوى من عنوان URL آخر داخل الصفحة الحالية.

<iframe src="https://example.com"></iframe>

غالبًا ما يُستخدم هذا iframe الأساسي لتضمين محتوى ثابت، مثل مقال، داخل صفحة ويب.

تم تصميم iframes المتجاوبة لتعديل حجمها بناءً على حجم الشاشة أو الحاوية التي توضع فيها. هذا يضمن أن المحتوى المضمن يبدو جيدًا على جميع الأجهزة، بما في ذلك أجهزة الكمبيوتر المكتبية والأجهزة اللوحية والهواتف المحمولة.

<iframe src="https://example.com" style="width: 100%; height: 500px;"></iframe>

يمكن أيضًا استخدام استعلامات وسائط CSS لجعل iframe يتكيف ديناميكيًا بناءً على حجم منفذ العرض.

Get a free passkey assessment in 15 minutes.

Book free consultation

iframe الآمن أو المعزول يقيد الإجراءات التي يمكن تنفيذها داخل iframe. هذا مفيد لتضمين محتوى من مصادر غير موثوقة أو لتعزيز الأمان.

<iframe src="https://example.com" sandbox></iframe>

يمكن أن تتضمن سمة sandbox قيودًا مختلفة، مثل:

<iframe src="https://example.com" sandbox="allow-scripts allow-same-origin"></iframe>

تسمح سمة sandbox بتشغيل البرامج النصية ولكنها تقيد الإجراءات التي قد تكون خطيرة، مثل إرسال النماذج أو استخدام المكونات الإضافية.

Become part of our Passkeys Community for updates & support.

Join

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

عبر المصادر يعني أن المحتوى الذي يتم تحميله هو من أصل مختلف، حيث يتم تعريف الأصل من خلال مزيج من المخطط (البروتوكول)، والمضيف (النطاق)، ورقم المنفذ. على سبيل المثال، يُعتبر https://example.com و http://example.com أصلين مختلفين لأنهما يستخدمان مخططات مختلفة (HTTP مقابل HTTPS).

وبالمثل، تُعامل النطاقات الفرعية كأصول منفصلة عن نطاقاتها الرئيسية. على سبيل المثال، https://example.com و https://sub.example.com هما عبر المصادر، على الرغم من أنهما يشتركان في نفس النطاق الأساسي. يضمن هذا الفصل عدم تمكن البرامج النصية والبيانات من نطاق فرعي واحد من التفاعل مباشرة مع تلك الموجودة في نطاق آخر دون إذن صريح، مما يعزز الأمان.

Igor Gjorgjioski

Head of Digital Channels & Platform Enablement, VicRoads

Corbado proved to be a trusted partner. Their hands-on, 24/7 support and on-site assistance enabled a seamless integration into VicRoads' complex systems, offering passkeys to 5 million users.

تثق الشركات في Corbado لحماية مستخدميها وجعل عمليات تسجيل الدخول أكثر سلاسة باستخدام مفاتيح المرور. احصل على استشارة مجانية حول مفاتيح المرور الآن.

احصل على استشارة مجانية

فيما يلي أمثلة لتوضيح مفاهيم عبر المصادر ونفس المصدر:

مثال عبر المصادر:

تضمين محتوى من https://payment.example.com في صفحة ويب مستضافة على https://www.mystore.com. هذه عبر المصادر لأنها تحتوي على نطاقات مختلفة.

مثال نفس المصدر:

تضمين محتوى من https://www.example.com/shop في صفحة ويب مستضافة على https://www.example.com/blog. هذه من نفس المصدر لأنها تشترك في نفس المخطط والمضيف والمنفذ.

تختلف iframes عبر المصادر عن iframes الأساسية في أن المصدر من نطاق آخر، بينما يكون مصدر iframe من نفس الموقع من نفس النطاق الذي تم تضمينه فيه.

<iframe src="https://anotherdomain.com"></iframe>

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

تاريخيًا، تم تعطيل واجهة برمجة تطبيقات مصادقة الويب (Web Authentication API) افتراضيًا في iframes عبر المصادر، ويرجع ذلك أساسًا إلى مخاوف أمنية. كان هذا القيد يعني أنه يتعين على المطورين إعادة توجيه المستخدمين أو استخدام نوافذ منبثقة للمصادقة، مما يؤدي إلى تجربة مستخدم أقل سلاسة.

في مفاتيح المرور / WebAuthn، هناك عمليتان أساسيتان (تُعرفان أيضًا بالاحتفالات):

1. تسجيل / إنشاء مفتاح مرور
2. المصادقة / تسجيل الدخول باستخدام مفتاح مرور

لم تكن العمليتان مدعومتين بشكل متساوٍ في iframes عبر المصادر ولا تزالان كذلك:

في البداية، أصبح تسجيل الدخول عبر iframes عبر المصادر ممكنًا ولكن الإنشاء عبر المصادر لم يكن ممكنًا بعد لأنه لم يكن هناك أي شخص لديه حالة استخدام لذلك.

أدت التطورات الأخيرة (على سبيل المثال في Chrome 123) إلى تقديم دعم لإنشاء مفاتيح مرور iframe عبر المصادر في ظل ظروف محددة. ومع ذلك، اعتبارًا من مايو 2024، لا تدعم جميع المتصفحات بشكل كامل إنشاء مفاتيح المرور عبر iframes عبر المصادر، على الرغم من أن تسجيل الدخول ممكن مع معظم المتصفحات.

علاوة على ذلك، تم بالفعل دمج دعم iframe عبر المصادر (لعمليات التسجيل والمصادقة) في مواصفات WebAuthn Level 3 الجارية. لا تزال بعض المتصفحات بحاجة إلى مواكبة المواصفات (مثل Safari). لسوء الحظ، لم تعلن Apple بعد ما إذا كانت ستسمح بتسجيل مفاتيح المرور عبر المصادر داخل Safari ومتى سيحدث ذلك. هذا من شأنه أن يرفع أهم قيد تقني لاستخدام مفاتيح المرور في iframes عبر المصادر.

في الأجزاء التالية من المقال، نفترض استخدام iframes عبر المصادر.

Want to find out how many people use passkeys?

View Adoption Data

تقدم الجداول التالية نظرة عامة على دعم المتصفح/المعيار لـ مصادقة iframe وتسجيل الدخول عبر iframe باستخدام مفاتيح المرور في سياقات iframe عبر المصادر:

اعتبارًا من مايو 2024، لم يكن إنشاء مفتاح مرور في iframe عبر المصادر ممكنًا بعد في جميع المتصفحات. يقدم الجدول التالي نظرة عامة على دعم المتصفح / المعيار لتسجيل / إنشاء مفاتيح المرور في iframes عبر المصادر:

إذا كنت مهتمًا بمزيد من المعلومات حول هذا التطور والدعم، نوصي بإلقاء نظرة على مشكلة GitHub هذه وطلب السحب هذا.

هناك حالتا استخدام رئيسيتان لدعم مفاتيح المرور في iframes عبر المصادر.

يعد تمكين مفاتيح المرور في iframes عبر المصادر أمرًا بالغ الأهمية لسيناريوهات الهوية الموحدة حيث تشارك نطاقات متعددة ولكن يجب استخدام نفس حسابات المستخدمين.

لنأخذ السيناريو التالي. أنت شركة متعددة الجنسيات مثل KAYAK ولديك نطاقات مختلفة لمناطق مختلفة:

• www.kayak.com
• www.kayak.us
• www.kayak.de

ومع ذلك، لديك نظام إدارة هوية مركزي واحد يمكّن المستخدمين من تسجيل الدخول بنفس الحساب وبيانات الاعتماد على جميع هذه النطاقات. سيشكل معيار WebAuthn تحديًا لهذه السيناريوهات، حيث يمكن ربط مفاتيح المرور بنطاق واحد فقط (Relying Party ID)، على سبيل المثال www.kayak.com.

للتغلب على هذا التحدي، يمكنك استخدام iframe من المصدر www.kayak.com على جميع نطاقاتك الأخرى. لذا، تقوم بتضمين iframe مع أصل www.kayak.com على www.kayak.us وعلى www.kayak.de (iframe عبر المصادر). وإلا، فإن استخدام مفاتيح المرور المرتبطة بـ "www.kayak.com" على هذه النطاقات الأخرى لن يكون ممكنًا بسبب مقاومة التصيد الاحتيالي لمفاتيح المرور.

على صعيد آخر: يمكن أيضًا استخدام ميزة WebAuthn الجديدة Related Origin Requests (RoR) كبديل. تسمح هذه الميزة لـ "الأصول ذات الصلة" بالوصول إلى مفاتيح المرور بدون iframes، ولكن لا يوجد دعم على جميع المتصفحات حتى الآن.

أيضًا لتدفقات الدفع السلسة، يلعب استخدام مفاتيح المرور في iframes عبر المصادر دورًا مهمًا. ضع في اعتبارك السيناريو التالي: يريد عميل شراء حذاء جديد على موقع تاجر (على سبيل المثال www.amazon.com). يسمح موقع هذا التاجر للعميل بالدفع عبر الحساب المصرفي (على سبيل المثال في www.revolut.com) وبالتالي يتطلب من المستخدم تسجيل الدخول إلى موقع البنك (هذه عملية مبسطة). يقوم المستخدم بتسجيل الدخول إلى موقع البنك باستخدام مفتاح مرور مرتبط بـ Relying Party ID الخاص بالبنك، على سبيل المثال "revolut.com".

Integrate passkeys as Payment Provider via 3rd party SDK.

Read article

لتجنب إعادة توجيه المستخدم من موقع التاجر (www.amazon.com) إلى موقع البنك (www.revolut.com) في عملية الدفع والسماح للمستخدم بتسجيل الدخول هناك إلى حساب البنك، يمكن استخدام iframe عبر المصادر. هنا، يبقى المستخدم على www.amazon.com ويستخدم مفتاح المرور في iframe عبر المصادر للمصادقة التي أنشأها لـ www.revolut.com.

وبالتالي، فإن دمج مفاتيح المرور عبر iframes عبر المصادر في تدفقات الدفع يضمن معاملات آمنة ومبسطة عبر المستهلكين والتجار والبنوك:

في سياق الدفع ومفاتيح المرور، نوصي أيضًا بإلقاء نظرة على مقالنا حول تأكيد الدفع الآمن (SPC) والربط الديناميكي باستخدام مفاتيح المرور. تأكد أيضًا من إلقاء نظرة على القيود المفروضة على سياق الطرف الثالث في التطبيقات الأصلية أدناه.

بالإضافة إلى ذلك، للحصول على عرض أكثر تعمقًا لتدفقات الدفع عبر المصادر باستخدام مفاتيح المرور، راجع مقالنا مفاتيح مرور مزودي الدفع: كيفية بناء SDK لطرف ثالث.

بشكل عام، يوفر دمج مفاتيح المرور داخل iframes العديد من الفوائد، بشكل أساسي من خلال تحسين تجربة المستخدم والأمان. إليك تفصيل لهذه المزايا:

تجربة مستخدم محسنة

1. لا نوافذ منبثقة أو عمليات إعادة توجيه: يمكن للمستخدمين المصادقة مباشرة داخل المحتوى المضمن دون عمليات إعادة توجيه أو نوافذ منبثقة، مما يؤدي إلى تجربة أكثر سلاسة وأقل إزعاجًا.
2. تجربة مستخدم متسقة عبر المواقع: يضمن تضمين تدفقات المصادقة داخل iframes تجربة مستخدم متسقة عبر أقسام مختلفة من موقع الويب أو عبر مواقع ويب مختلفة تستخدم نفس خدمة المصادقة.

أمان محسن

1. معاملات آمنة: بالنسبة لسيناريوهات مثل المدفوعات، تعزز مفاتيح المرور في iframes أمان المعاملات من خلال ضمان حدوث المصادقة داخل سياق آمن ومضمن.
2. استخدام حساب المستخدم على مواقع ويب مختلفة: في إعدادات الهوية الموحدة، تسمح مفاتيح المرور في iframes عبر المصادر بالتحقق من الهوية بشكل آمن وفعال عبر نطاقات متعددة.

يتضمن تنفيذ مفاتيح المرور في iframes بعض الخطوات الرئيسية لضمان الأمان والوظائف. نقدم دليلًا مفصلاً للمطورين. يرجى الاطلاع أيضًا على مثال التنفيذ على https://cross-origin-iframe.vercel.app/.

يساعد ترويسة HTTP Permissions-Policy على السماح أو رفض استخدام ميزات متصفح معينة في مستند أو داخل عنصر iframe. لتمكين تسجيل الدخول باستخدام مفاتيح المرور في iframe، يجب عليك تعيين publickey-credentials-get و publickey-credentials-create سياسات الأذونات. تسمح السياسات للمحتوى المضمن باستدعاء طريقة WebAuthn API اللازمة للمصادقة (navigator.credentials.get({publicKey})) وإنشاء مفتاح مرور (navigator.credentials.create({publicKey})).

<iframe src="https://passkeys.eu" allow="publickey-credentials-get; publickey-credentials-create"></iframe>

كانت ترويسة HTTP Permissions Policy تسمى سابقًا Feature Policy. تحت Feature Policy، يمكنك منح ميزة لـ iframe عبر المصادر إما عن طريق إضافة المصدر إلى قائمة أصول الترويسة أو تضمين سمة allow في علامة iframe. مع Permissions Policy، تتطلب إضافة إطار عبر المصادر إلى قائمة الأصول أن تتضمن علامة iframe لهذا الأصل سمة allow. إذا كان الرد يفتقر إلى ترويسة Permissions Policy، فإن قائمة الأصول تكون افتراضيًا * (جميع الأصول). يمنح تضمين سمة allow في iframe الوصول إلى الميزة.

لضمان حظر iframes عبر المصادر غير المحددة في قائمة الأصول من الوصول إلى الميزة، حتى لو كانت سمة allow موجودة، يمكن للمطورين تعيين ترويسة Permissions Policy بشكل صريح في الرد.

في Chrome 88+، لا يزال من الممكن استخدام Feature Policy ولكنه يعمل كاسم مستعار لـ Permissions Policy. بخلاف الاختلافات في بناء الجملة، يظل المنطق كما هو. عند استخدام ترويسات Permissions Policy و Feature Policy في وقت واحد، يكون لترويسة Permissions Policy الأسبقية وستتجاوز القيمة التي حددتها ترويسة Feature Policy. يرجى الاطلاع أيضًا على هذا المقال من فريق Chrome لمزيد من تفاصيل التنفيذ.

تأكد من أن ترويسات استجابة HTTP من عنوان URL المصدر لـ iframe تتضمن ´Permissions-Policy´ ذات الصلة. هذا أمر بالغ الأهمية لدعم عبر المصادر.

Permissions-Policy: publickey-credentials-get=*, publickey-credentials-create=*

لمزيد من التحكم الدقيق، يمكنك تحديد أصول معينة مسموح لها بتضمين محتوى iframe.

Permissions-Policy: publickey-credentials-get=("https://passkeys.eu"), publickey-credentials-create=("https://passkeys.eu")

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

document.getElementById('loginPasskeyButton').addEventListener('click',
    async () => {
        try {
            const [publicKeyCredentialRequestOptions](/glossary/publickeycredentialrequestoptions) = { /* Configuration options */ };
 
            const credential = await navigator.credentials.get({publicKey: publicKeyCredentialRequestOptions});
            // Handle the created credential
        } catch (err) {
            console.error('Error authenticating via passkey:', err);
        }
    });

في هذا السياق، راجع أيضًا مقالنا حول متطلبات إيماءة المستخدم في Safari.

فيما يلي، تجد مقتطف رمز كامل لملف index.html مستضاف على https://cross-origin-iframe.vercel.com يستخدم iframe عبر المصادر لمفاتيح المرور عبر https://passkeys.eu.

<!doctype html>
<html lang="en">
    <head>
        <meta charset="UTF-8" />
        <meta name="viewport" content="width=device-width, initial-scale=1.0" />
        <meta
            http-equiv="Permissions-Policy"
            content="publickey-credentials-get=*; publickey-credentials-create=*"
        />
        <meta
            http-equiv="Content-Security-Policy"
            content="default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline'; font-src 'self'; img-src 'self'; frame-src https://passkeys.eu;"
        />
 
        <title>Cross-Origin iframe with Passkeys Demo</title>
        <style>
            body {
                font-family: Arial, sans-serif;
                padding: 20px;
                display: flex;
                flex-direction: column;
                justify-content: center;
                align-items: center;
                height: 100vh;
                margin: 0;
            }
 
            h1 {
                width: 100%;
                text-align: center;
            }
 
            .iframe-container {
                width: 80%;
                max-width: 800px;
                height: 80%;
                max-height: 600px;
                border: 1px solid #ccc;
                box-shadow: 0 0 10px rgba(0, 0, 0, 0.1);
                margin-top: 20px;
            }
 
            iframe {
                width: 100%;
                height: 100%;
                border: none;
            }
 
            @media (max-width: 768px) {
                h1 {
                    width: 95%;
                }
 
                .iframe-container {
                    width: 95%;
                }
            }
        </style>
    </head>
    <body>
        <h1>Cross-Origin iframe with Passkeys Demo</h1>
 
        <div class="iframe-container">
            <iframe
                src="https://passkeys.eu"
                allow="publickey-credentials-create; publickey-credentials-get"
            ></iframe>
        </div>
    </body>
</html>

يمكن أن يأتي تنفيذ مفاتيح المرور في iframes مع مجموعة من التحديات التي يحتاج المطورون إلى معالجتها لضمان تجربة مستخدم سلسة وآمنة. إليك نظرة مفصلة على التحديات الشائعة وكيفية التغلب عليها.

المشكلة: يمكن أن يمنع تكوين سياسات الأذونات بشكل غير صحيح iframe من الوصول إلى واجهات برمجة تطبيقات WebAuthn.

“NotAllowedError - The 'publickey-credentials-create' feature is not enabled in this document. Permissions Policy may be used to delegate Web Authentication capabilities to cross-origin child frames.”

إذا لم تقم بإضافة سياسات الأذونات بشكل صحيح، فسيقوم المتصفح بإظهار الخطأ التالي:

الحل:

• تحقق مرة أخرى من تعيين سمة Allow وترويسات HTTP: تأكد من تعيين سمة allow وترويسات HTTP بشكل صحيح. تحقق مرة أخرى من تضمين أذونات publickey-credentials-get و publickey-credentials-create في كل من عنصر iframe وترويسات استجابة HTTP للخادم.
• ترويسات Meta بدلاً من ترويسات خادم الويب: استخدم ترويسات <meta/> لتعريف سياسات الأذونات بدلاً من تعيين الترويسات في خادم الويب الخاص بك.
• فاصلة منقوطة بدلاً من الفاصلة في Permissions-Policy: في وقت سابق، كانت Permissions-Policy تسمى Feature-Policy. تم فصل العناصر الفردية لـ Feature-Policy بفاصلة بدلاً من فاصلة منقوطة (وهو المعيار لـ Permissions-Policy). لا تزال Permissions-Policy الخاصة بـ iframe تتبع بناء جملة Feature-Policy وبالتالي تستخدم الفواصل. لا تزال سمات sandbox / allow مفصولة بفاصلة منقوطة (انظر مقتطف الرمز أعلاه).

نصيحة: لاختبار أن ترويسات Permission-Policy الخاصة بك تم تعيينها بشكل صحيح، نوصي بفتح أدوات المطور في متصفحك، والوصول إلى Application (هنا: في أدوات مطور Chrome)، والانتقال إلى Frames والبحث عن أصل iframe (هنا: passkeys.eu/). إذا تم تعيين Permissions-Policy بشكل صحيح، فيجب إدراج publickey-credential-create و publickey-credential-get ضمن الميزات المسموح بها:

المشكلة: لا يعمل إنشاء مفتاح المرور أو تسجيل الدخول بمفتاح المرور عبر iframe عبر المصادر، وترى الخطأ التالي في وحدة تحكم المتصفح.

"NotAllowedError - The origin of the document is not the same as its ancestors."

يظهر هذا الخطأ عند استخدام متصفح Safari ومحاولة إنشاء مفتاح مرور من داخل iframe، حيث لا يدعم Safari إنشاء مفتاح مرور عبر iframe عبر المصادر (انظر أعلاه).

الحل: هنا، لا يمكنك فعل أي شيء حقًا لأن Safari لا يدعم بعد إنشاء مفتاح مرور من داخل iframe عبر المصادر (حتى الآن).

Blocked a frame with origin "https://passkeys.eu" from accessing a frame with origin "https://cross-origin-iframe.vercel.app". Protocols, domains, and ports must match.

هذا الخطأ غير مرتبط مباشرة بمفاتيح المرور ولكنه يتعلق أكثر بـ iframes عبر المصادر في Safari بشكل عام. كجزء من مبادرة Safari / WebKit لحظر ملفات تعريف الارتباط التابعة لجهات خارجية أو الوصول إلى LocalStorage في سياق طرف ثالث، قد تتعطل أجزاء من منطق JavaScript.

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

المشكلة: تنشأ مشكلات توافق متصفح iframe عندما يكون لدى المتصفحات المختلفة مستويات متفاوتة من الدعم لـ WebAuthn وأذونات iframe وسمات الأمان، مما يؤدي إلى سلوك غير متسق.

الحل: للتخفيف من مشكلات توافق متصفح iframe هذه، اختبر التنفيذ عبر متصفحات متعددة لضمان التوافق وتحديد أي مشكلات خاصة بالمتصفح.

الخطوات:

1. قم بإجراء اختبار عبر المتصفحات باستخدام أدوات مثل BrowserStack أو Sauce Labs.
2. عالج أي اختلافات عن طريق تنفيذ إصلاحات أو حلول بديلة خاصة بالمتصفح.

المشكلة: عند استخدام iframes التي تتطلب مفاتيح مرور داخل التطبيقات الأصلية، يجب التمييز بشكل حاسم بين سياقات الطرف الأول و الطرف الثالث:

• سياق الطرف الأول: ترتبط مفاتيح المرور بنفس النطاق الذي تدير به الشركة التطبيق. على سبيل المثال، تطبيق تجارة إلكترونية يعتمد على نطاقه الخاص لـ مصادقة المستخدم.
• سياق الطرف الثالث: يتعامل نطاق مختلف (على سبيل المثال، مزود دفع أو مزود هوية) مع تدفق إنشاء مفتاح المرور أو تسجيل الدخول.

في WebView المضمن (EWV) مثل WKWebView على iOS أو Android WebView - يتمتع التطبيق المستدعي بتحكم واسع في جلسة الويب (على سبيل المثال، اعتراض الطلبات). يدعم هذا الإعداد عادةً مفاتيح المرور فقط إذا كان نطاق مفتاح المرور (معرف Relying Party) يطابق نطاق التطبيق (الطرف الأول). ومع ذلك، في سيناريو طرف ثالث - مثل تدفق عبر المصادر لمزود الدفع - لا يمكن لـ WebView المضمن عمومًا الوصول إلى بيانات اعتماد مفتاح المرور اللازمة لأن تطبيق التاجر وخدمة مزود الدفع هما أصلان مختلفان. لن تتطابق "الروابط" المطلوبة لمفاتيح المرور (بين النطاق وبيانات الاعتماد والأصل) في السياق المضمن.

يدفع هذا القيد العديد من التطبيقات إلى تبني نهج WebView النظام (على سبيل المثال، ASWebAuthenticationSession على iOS أو Custom Tabs على Android). تعزل WebViews النظام موقع الطرف الثالث (على سبيل المثال، مزود الدفع) في بيئة آمنة تشبه المتصفح تسمح بشكل صحيح بمفاتيح المرور عبر المصادر - إذا كان المتصفح نفسه يدعمها. ومع ذلك، تذكر أن قيود iframe الحالية في Safari تنطبق أيضًا على ASWebAuthenticationSession، لذلك إذا لم يسمح Safari بعمليات مفاتيح مرور معينة في iframes تابعة لجهات خارجية، فسيظل الأمر كذلك في WebView النظام. لا يوجد حاليًا إصلاح "أصلي"؛ أفضل ممارسة لـ التدفقات المعقدة - مثل عمليات الدفع التي تتضمن مزودي دفع خارجيين - هي فتح WebView نظام بدلاً من WebView مضمن.

الحل: بالنسبة لمزودي الدفع (والأطراف الثالثة الأخرى التي تعتمد على مفاتيح المرور عبر النطاقات)، خطط بعناية للتكامل لضمان نقل المستخدم من WebView مضمن إلى WebView نظام. على الرغم من أنها تجربة أقل سلاسة من التدفق المضمن تمامًا، إلا أنها غالبًا ما تكون الطريقة الوحيدة لضمان عمل وظيفة مفتاح المرور مع خدمات الجهات الخارجية.

Integrate passkeys as Payment Provider via 3rd party SDK.

Read article

لمزيد من التفاصيل حول التعامل مع مفاتيح مرور الجهات الخارجية داخل التطبيقات الأصلية و WebViews، تحقق من مفاتيح مرور مزودي الدفع: SDK دفع مفاتيح مرور الجهات الخارجية.

بينما تنطبق الموضوعات التي تمت مناقشتها أعلاه على سيناريوهات مختلفة، إلا أنها مهمة بشكل خاص لمزودي الدفع، حيث يجب أن تتضمن التدفقات متعددة النطاقات (على سبيل المثال، موقع التاجر وبوابة الدفع) مصادقة المستخدم داخل iframes عبر المصادر. في هذه الإعدادات:

• يريد المستخدمون عملية دفع سلسة داخل الصفحة دون نوافذ منبثقة لإعادة التوجيه.
• يجب على مزودي الدفع التعامل مع تسجيل مفتاح المرور أو تسجيل الدخول على نطاقهم الخاص (على سبيل المثال، pay.provider.com)، حتى لو كانوا مضمنين في موقع التاجر.
• غالبًا ما تمنع قيود Safari وقيود WebView المضمن إنشاء مفاتيح مرور تابعة لجهات خارجية في iframes.

لمواجهة هذه التحديات وبناء تجربة آمنة وسلسة تشبه Apple Pay، غالبًا ما يتبنى مزودو الدفع نهجًا هجينًا - يجمع بين التكامل القائم على iframe مع حل بديل لإعادة التوجيه لـ Safari (أو المتصفحات القديمة). في بعض الحالات، تصبح تدفقات متصفح النظام (على سبيل المثال، ASWebAuthenticationSession على iOS) إلزامية إذا لم يسمح WebView المضمن بمفاتيح المرور على الإطلاق.

للحصول على نظرة عميقة في هذه السيناريوهات الخاصة بالدفع - بما في ذلك مقارنات iframe مقابل إعادة التوجيه، واعتبارات التطبيقات الأصلية وأفضل الممارسات لـ تبني مفاتيح المرور العالي، راجع مقالنا المخصص:

60-page Enterprise Passkey Whitepaper:
Learn how leaders get +80% passkey adoption. Trusted by Rakuten, Klarna & Oracle

Get free Whitepaper

على وجه الخصوص:

• الاستراتيجية أ: تضمين iframe عبر المصادر تشرح كيفية التعامل مع إنشاء مفتاح المرور وتسجيل الدخول المضمن، مع الإشارة إلى إعدادات Permissions-Policy المقدمة هنا.
• الاستراتيجية ب: النهج القائم على إعادة التوجيه تعرض تكاملاً أبسط يتجاوز معظم مخاطر عبر المصادر، وإن كان ذلك على حساب مغادرة نطاق التاجر.
• WebView النظام ضروري للتطبيقات الأصلية، حيث أن WebViews المضمنة غالبًا ما تعطل تدفقات مفاتيح مرور الجهات الخارجية.

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

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

توضح التطبيقات الواقعية، مثل تكامل Shopify لمفاتيح المرور داخل مكون تسجيل الدخول الخاص بهم، الفوائد العملية والمرونة لهذا النهج.