مفاتيح المرور في التطبيقات الأصلية: التنفيذ الأصلي مقابل التنفيذ عبر WebView

يشرح هذا المقال كيفية تنفيذ مفاتيح المرور في التطبيقات الأصلية (iOS + Android). ستتعلم أي نوع من WebView يُنصح به لمصادقة مفاتيح المرور.

Our mission is to make the Internet a safer place, and the new login standard passkeys provides a superior solution to achieve that. That's why we want to help you understand passkeys and its characteristics better.

1. خيارات تنفيذ مفاتيح المرور في التطبيقات الأصلية#

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

1.1 التنفيذ الأصلي: تجربة مستخدم رائعة#

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

Want to try passkeys yourself in a passkeys demo?

Try Passkeys

1.2 تنفيذ WebView: تجربة شبيهة بالمتصفح#

عند تطوير تطبيق أصلي، قد لا يكون المسار نحو التنفيذ الأصلي بالكامل ممكنًا دائمًا. في السيناريوهات التي لا تزال بحاجة فيها إلى دعم المصادقة المستندة إلى كلمة المرور باستخدام OAuth2، قد لا يكون التكامل الأصلي الكامل ممكنًا، مما يجعل تطبيقات WebView هي البديل الوحيد القابل للتطبيق. يعمل WebView كجسر، حيث يدمج محتوى الويب مباشرة داخل تطبيقك، مما يوفر تجربة مستخدم شبيهة بالمتصفح أثناء التنقل عبر صفحات الويب. هذا الأمر وثيق الصلة بشكل خاص إذا كنت مزودًا لـ OAuth2 بنفسك، أو كان حل المصادقة الأساسي لديك يعتمد على OAuth2، أو إذا كان حل تسجيل الدخول الخاص بك يستخدم عمليات تسجيل الدخول الاجتماعية عبر أطراف ثالثة، مثل Google أو GitHub. في هذه الحالات، يصبح استخدام WebView أمرًا لا مفر منه بسبب ضرورة التفاعل مع محتوى الويب وإدارة تدفقات مصادقة المستخدم المختلفة، خاصة عند الحاجة إلى اقتران التطبيقات الأصلية.

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

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

Ben Gould

Head of Engineering

I’ve built hundreds of integrations in my time, including quite a few with identity providers and I’ve never been so impressed with a developer experience as I have been with Corbado.

يثق أكثر من 10,000 مطور في Corbado ويجعلون الإنترنت أكثر أمانًا باستخدام مفاتيح المرور. هل لديك أسئلة؟ لقد كتبنا أكثر من 150 منشور مدونة حول مفاتيح المرور.

انضم إلى مجتمع مفاتيح المرور

2. نظرة عامة على خيارات WebView#

أثناء التنقل في متاهة المصادقة في التطبيقات الأصلية، يواجه المطورون ومديرو المنتجات قرارًا محوريًا: تنفيذ مصادقة مفاتيح المرور أصليًا أم عبر WebView. إذا تم اتخاذ القرار لصالح الأخير، فإن منصتي iOS و Android تقدمان نوعين متميزين من WebViews، لكل منهما سماته الفريدة وحالات الاستخدام المحتملة.

2.1 WebViews في iOS#

WKWebView
SFSafariViewController
SFAuthenticationSession / ASWebAuthenticationSession (مصمم خصيصًا لتدفقات المصادقة المستندة إلى OAuth / OpenID Connect)

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

Subscribe to our Passkeys Substack for the latest news.

3. WebViews في iOS#

WebViews في iOS هي إما WKWebView أو SFSafariViewController (إذا كنت تعمل مع OAuth / OIDC، فهي SFAuthenticationSession / ASWebAuthenticationSession).

لاختبار سلوك WebView المختلف في iOS، نوصي بتطبيق WebView - WKWebView and UIWebView rendering.

3.1 WKWebView#

WKWebView هو خيار WebView قوي ومتعدد الاستخدامات متاح لمطوري iOS. تم تقديمه مع iOS 8، وهو يسمح للمطورين بتضمين محتوى الويب مباشرة داخل التطبيق، مما يوفر مجموعة واسعة من خيارات التخصيص والتكوين. يشتهر WKWebView بأدائه، حيث يستخدم نفس محرك عرض الويب مثل Safari، ويقدم مجموعة غنية من واجهات برمجة التطبيقات (APIs) للتفاعل مع محتوى الويب، وإدارة التنقل، وتفاعلات المستخدم، والمزيد.

3.2 SFSafariViewController#

SFSafariViewController هو WebView يسمح للمطورين بالاستفادة من إمكانيات Safari مباشرة داخل تطبيقاتهم. يوفر تجربة مستخدم سلسة من خلال استخدام إعدادات Safari الخاصة بالمستخدم، مثل كلمات المرور المحفوظة، ومفاتيح المرور، وملفات تعريف الارتباط، والمزيد، مما يضمن تصفحًا ثابتًا للويب، لأنه يعمل بالفعل كتطبيق Safari. SFSafariViewController ليس قابلاً للتخصيص مثل WKWebView ولكنه يوفر ميزات أمان محسنة وسهولة في الاستخدام، مما يجعله خيارًا مفضلاً لعرض محتوى الويب المباشر داخل التطبيقات.

	WKWebView	SFSafariViewController
تجربة المستخدم	- شعور أصلي: قد يشعر المستخدمون بأن محتوى الويب جزء أصلي من التطبيق لأن المطورين يمكنهم تخصيص الشكل والمظهر ليتناسب مع تصميم التطبيق. - الملء التلقائي: الملء التلقائي بالبيانات من Safari ممكن	- سلس: تجربة مستخدم سلسة باستخدام إعدادات Safari الخاصة بالمستخدم مما يضمن تصفحًا ثابتًا للويب بين التطبيق الأصلي والمتصفح.
تجربة المطور	- قابل للتخصيص بدرجة عالية: تخصيص وتكوين واسع النطاق متاح - مرن: العديد من واجهات برمجة التطبيقات للتفاعل مع محتوى الويب	- قابل للتخصيص بشكل متوسط: خيارات تخصيص محدودة، خاصة مقارنة بـ WKWebView، - بسيط: أسهل في التنفيذ مقارنة بـ WKWebView
الأداء	- بطيء نوعًا ما: اعتمادًا على التنفيذ ومحتوى الويب، يمكن تحسين سرعات التحميل، ولكنها قد تظل أبطأ مقارنة بـ SFSafariViewController بسبب المعالجة الإضافية للميزات والتفاعلات المخصصة.	- سريع نوعًا ما: يقدم عادةً أداءً أفضل لأنه يستفيد من محرك Safari، الذي تم تحسينه للسرعة والكفاءة، مما يوفر أوقات تحميل سريعة لصفحات الويب.
الثقة والتعرف	- عرض URL غير مطلوب: غالبًا ما لا يعرض WKWebView عنوان URL، مما يجعل من الصعب على المستخدمين التحقق من صفحة الويب. إمكانية قيام التطبيقات الضارة بتقليد هذا السلوك وتصيد بيانات الاعتماد.	- تجربة شبيهة بالمتصفح: يعرض صفحات الويب باستخدام Safari، مما يوفر تجربة "شبيهة بالمتصفح". يمكن للمستخدمين رؤية عنوان URL والوصول إلى ميزات الملء التلقائي في Safari، مما قد يغرس المزيد من الثقة بسبب الواجهة المألوفة.
العزل	- منفصل: يتم فصل ملفات تعريف الارتباط والجلسات عن Safari؛ لن يتم تسجيل دخول المستخدمين تلقائيًا إلى WKWebView.	- منفصل: يتم فصل ملفات تعريف الارتباط والجلسات عن Safari؛ لن يتم تسجيل دخول المستخدمين تلقائيًا إلى SFSafariViewController أيضًا.
الثغرات الأمنية	- آمن: آمن بطبيعته بسبب وضع الحماية (sandboxing) لتطبيقات Apple، ولكن السلوك والأمان يعتمدان على تنفيذ التطبيق. ثغرات أمنية محتملة إذا لم يتم تنفيذه بشكل صحيح.	- أكثر أمانًا: يستفيد من ميزات الأمان المضمنة في Safari، بما في ذلك التحذيرات من التصيد الاحتيالي والمواقع الضارة. يعتبر بشكل عام أكثر أمانًا لعرض محتوى الويب من WKWebView بسبب هذه الميزات وألفة المستخدم مع Safari.
أخرى	- ميزات غير متوفرة: قد لا تكون بعض ميزات المتصفح (مثل WebAuthn) متاحة بالكامل بسبب مخاوف أمنية وتشغيل WKWebView في سياق التطبيق. - حقن JavaScript: تقوم بعض التطبيقات، مثل TikTok، بحقن JavaScript للتتبع في WKWebView داخل التطبيق، أو تقييد تحكم المستخدم (مثل Facebook) - مشكلات الخصوصية: المزيد من تعليقات المجتمع بخصوص الخصوصية	- لا يوجد حقن JavaScript: لا يسمح بتنفيذ JavaScript من التطبيق، مما يعزز الأمان والخصوصية. كما أنه لا يدعم تنبيهات أو تأكيدات JavaScript، مما قد يؤثر على تجربة المستخدم في بعض صفحات الويب. - وضع القارئ: يوفر وضع القارئ نسخة نظيفة وسهلة القراءة من المقالات.

3.3 SFAuthenticationSession / ASWebAuthenticationSession#

SFAuthenticationSession و ASWebAuthenticationSession هما WebViews مصممان خصيصًا لتدفقات المصادقة المستندة إلى OAuth / OpenID Connect. يوفران مساحة آمنة ومعزولة لمصادقة المستخدم، مما يحمي بيانات اعتماد المستخدم ويضمن عدم مشاركة المعلومات الخاصة عن غير قصد مع التطبيق. تشارك هذه الجلسات ملفات تعريف الارتباط وبيانات موقع الويب مع Safari، مما يوفر تجربة مستخدم متسقة وسلسة، خاصة أثناء عمليات المصادقة.

الإيجابيات:

مصادقة مخصصة: مصممة خصيصًا لتدفقات المصادقة المستندة إلى OAuth / OpenID Connect، مما يضمن عملية مصادقة مبسطة.
حماية الخصوصية: تضمن خصوصية بيانات المستخدم من خلال عدم مشاركة ملفات تعريف الارتباط أو بيانات موقع الويب مع التطبيق.
دعم SSO: تدعم تسجيل الدخول الموحد (SSO)، مما يوفر تجربة مستخدم مريحة.

السلبيات:

حالة استخدام محدودة: تركز بشكل أساسي على مصادقة OAuth / OpenID Connect، والتي قد لا تكون مناسبة لجميع حالات الاستخدام.

عندما تكون المهمة الأساسية هي مصادقة المستخدم، خاصة عند تنفيذ SSO أو التفاعل مع مزودي OAuth، يجب عليك استخدام SFAuthenticationSession / ASWebAuthenticationSession بدلاً من SFSafariViewController.

Want to find out how many people use passkeys?

View Adoption Data

4. WebViews في Android#

WebViews في Android هي إما WebView أو Chrome Custom Tabs (CCT). لاختبار سلوك WebView المختلف في Android، نوصي بتطبيق WebView vs Chrome Custom Tabs.

4.1 Android WebView#

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

4.2 Chrome Custom Tabs (CCT)#

تقدم Chrome Custom Tabs (CCT) طريقة سلسة وآمنة وفعالة لدمج محتوى الويب مباشرة في تطبيقك. من خلال الاستفادة من إمكانيات Chrome وميزات الأمان، يوفر CCT تجربة مستخدم متسقة وعالية الأداء.

CCT هو مكون من متصفح Chrome، مصمم للتكامل مع إطار عمل Android، مما يسمح للتطبيقات بفتح محتوى الويب في عملية خفيفة الوزن ومخصصة. والجدير بالذكر أنه يفتح بشكل أسرع من المتصفح التقليدي، وعندما يتم تحميله مسبقًا عبر استدعاء الإحماء الخاص به، فإنه من المحتمل أن يتفوق على WebView. بينما يقوم بتنفيذ JavaScript، فإنه يعمل في عمليته الخاصة، مما يحمي التطبيقات من تشغيل التعليمات البرمجية الضارة. علاوة على ذلك، توفر واجهة مستخدم CCT شريط إجراءات، يعرض عنوان URL وأيقونة قفل التحقق من SSL للصفحات الآمنة، وبالتالي يطمئن المستخدمين على أصالة وأمان الصفحة التي يتم تحميلها.

بشكل عام، يمكن القول أن iOS WKWebView و Android WebView، بالإضافة إلى SFSafariViewController و Chrome Custom Tabs (CCT) متشابهة.

الميزة	WebView	Chrome Custom Tab
تجربة المستخدم	- المرونة: يوفر مجموعة غنية من واجهات برمجة التطبيقات للتفاعل مع محتوى الويب وإدارة تفاعلات المستخدم، بما في ذلك التعامل مع مربعات حوار JavaScript وطلبات الأذونات. - الاتساق: قد تكون إدارة تجربة مستخدم متسقة، خاصة مع محتوى الويب المتنوع، أمرًا صعبًا.	- ميزات المتصفح: يشارك ميزات مثل توفير البيانات (Data Saver) والملء التلقائي المتزامن (AutoComplete) عبر الأجهزة. - زر الرجوع: يسمح للمستخدمين بالعودة بسهولة إلى التطبيق باستخدام زر رجوع مدمج. - الاعتمادية: يعتمد على تطبيق Chrome، الذي قد لا يكون متاحًا أو محدثًا على جميع أجهزة المستخدمين - إعادة التوجيه إلى المتصفح: قد تعيد بعض الوظائف توجيه المستخدمين إلى تطبيق Chrome، مما قد يعطل تجربة المستخدم. - علامات التبويب المخصصة الجزئية: يمكن استخدام جزء فقط من الشاشة لعلامة التبويب المخصصة في Chrome بينما يعرض الباقي التطبيق الأصلي - الورقة الجانبية: في الوضع الأفقي وعلى الأجهزة ذات الشاشات الكبيرة، يتم عرض علامة التبويب المخصصة في Chrome على جانب واحد فقط من الشاشة، بينما يعرض باقي الشاشة التطبيق الأصلي
تجربة المطور	- قابل للتخصيص بدرجة عالية: يوفر خيارات/احتياجات تخصيص واسعة النطاق. - التفاعلية: يوفر العديد من واجهات برمجة التطبيقات للتفاعل مع محتوى الويب وإدارة تفاعلات المستخدم.	- قابل للتخصيص: يسمح بتخصيص لون شريط الأدوات، وزر الإجراء، وشريط الأدوات السفلي، وعناصر القائمة المخصصة، ورسوم الدخول/الخروج. - الاستدعاء (Callback): يسلم استدعاءً إلى التطبيق عند حدوث تنقل خارجي. - ميزات الأمان: يوفر ميزات جاهزة للاستخدام، مما يلغي الحاجة إلى إدارة الطلبات أو منح الأذونات أو مخازن ملفات تعريف الارتباط.
الأداء	- أداء متوسط: قد لا يقدم نفس مستوى الأداء الذي تقدمه Chrome Custom Tabs (CCT)	- الإحماء المسبق: يتضمن إحماء المتصفح مسبقًا في الخلفية والتحميل التخميني لعناوين URL لتحسين وقت تحميل الصفحة. - الأولوية: يمنع طرد التطبيقات التي تطلق علامة تبويب مخصصة أثناء استخدامها عن طريق رفع أهميتها إلى مستوى "المقدمة".
الثقة والتعرف	- URL و SSL غير مرئيين: لا تكون معلومات URL و SSL مرئية بطبيعتها في WebView. ما لم يقم مطور التطبيق بتنفيذ هذه الميزات، فلن يعرف المستخدمون ما إذا كانوا على موقع الويب الصحيح أم موقع تصيد احتيالي.	- URL و SSL مرئيان: يستخدم متصفح Chrome الفعلي لعرض الصفحات. يمكن للمستخدمين رؤية عنوان URL وشهادة SSL (مما يشير إلى ما إذا كان الاتصال آمنًا). يمكن أن يوفر هذا للمستخدمين الثقة بأنهم ليسوا على موقع تصيد احتيالي.
العزل	- يعمل ضمن عملية التطبيق: إذا كان التطبيق يحتوي على ثغرة أمنية تسمح بتنفيذ تعليمات برمجية ضارة، فهناك خطر من أن يتم اختراق WebView. ومع ذلك، يتلقى WebView أيضًا تحديثات، ولكن سلوكه وأمانه يمكن أن يعتمدا بشكل أكبر على التطبيق الذي يستخدمه. - لا توجد مشاركة لملفات تعريف الارتباط / الجلسات: لا يشارك ملفات تعريف الارتباط أو الجلسات مع المتصفح الرئيسي للجهاز، مما يوفر عزلًا ولكن قد يتطلب من المستخدمين تسجيل الدخول مرة أخرى.	- يعمل ضمن عملية Chrome: كجزء من Chrome، تعمل علامات التبويب المخصصة في نفس العملية ولديها نفس تحديثات الأمان والميزات مثل Chrome. - مشاركة مخزن ملفات تعريف الارتباط ونموذج الأذونات: يضمن عدم اضطرار المستخدمين إلى إعادة تسجيل الدخول إلى المواقع أو إعادة منح الأذونات. - إعدادات وتفضيلات Chrome: يستخدم إعدادات وتفضيلات Chrome.
الثغرات الأمنية	- استدعاءات لسرقة بيانات الاعتماد: تشمل الثغرات المحتملة أن JavaScript مطلوب أحيانًا مما يفتح الباب أمام تطبيقات أخرى لتشغيل تعليمات برمجية ضارة، مثل تسجيل استدعاءات تحاول اعتراض أسماء المستخدمين وكلمات المرور. - التصيد الاحتيالي: بالإضافة إلى ذلك، يمكن لتطبيق ضار فتح صفحة ويب أخرى تحاكي تدفق الرابط في محاولة تصيد احتيالي.	- التصفح الآمن من Google: يستخدم التصفح الآمن من Google لحماية كل من المستخدم والجهاز من المواقع الخطرة. - زخرفة المتصفح الآمنة: تضمن أن يرى المستخدم دائمًا عنوان URL الدقيق الذي يتفاعل معه ويمكنه عرض معلومات شهادة موقع الويب، مما يقلل من خطر التصيد الاحتيالي. علاوة على ذلك، لا تسمح علامات التبويب المخصصة بحقن JavaScript.
أخرى	- حظرت Google استخدام WebViews لتسجيل دخول المستخدمين إلى حسابات Google

5. توصية لتنفيذ مفاتيح المرور في التطبيقات الأصلية#

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

المجموعة أ:

العملاء الذين يبدأون في بناء تطبيقهم الأصلي من الصفر ويمكنهم استخدام مصادقتنا بدون كلمة مرور مباشرة (لا توجد كلمات مرور قديمة).

المجموعة ب:

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

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

حدد مجموعتك

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

توصية للمجموعة أ: التنفيذ الأصلي

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

توصية للمجموعة ب: أولاً WebView، ثم التنفيذ الأصلي

إذا لم تتمكن من تنفيذ مفاتيح المرور أصليًا اليوم لأي سبب من الأسباب (المجموعة ب)، يمكنك البدء بتنفيذ WebView ثم الانتقال في المستقبل إلى تنفيذ أصلي لمفاتيح المرور (يعمل هذا عبر إنشاء ملفات الاقتران، مثل apple-app-site-association لتطبيقات iOS و assetlinks.json لتطبيقات Android). قد تشمل أسباب الذهاب مع تنفيذ WebView ما يلي:

أنت تقدم بالفعل مصادقة قائمة على OAuth2 وترغب في الاستمرار في تقديمها للمستخدمين (OAuth2 لا يعمل أصليًا، انظر المعيار هنا)
تريد تقديم مصادقة مفاتيح المرور في نفس النافذة / الشاشة، حيث تقدم طرق المصادقة الأخرى (مثل كلمات المرور، وتسجيلات الدخول الاجتماعية، و OAuth2)

هذه هي الطريقة التي نفذت بها Google أو GitHub مصادقة مفاتيح المرور في تطبيقاتهما الأصلية حاليًا. يرجى الاطلاع على التوصية أدناه لإعداد WebViews بشكل صحيح لمصادقة مفاتيح المرور. ومع ذلك، نوصي بالنظر في تنفيذ أصلي لمفاتيح المرور مثلما فعلت KAYAK والبدء مباشرة بالخطوة 2.

إذا كنت تنتمي إلى المجموعة ب ولا يمكنك تنفيذ مفاتيح المرور أصليًا، فإن توصيتنا تميل نحو استخدام SFAuthenticationSession / ASWebAuthenticationSession لنظام iOS و Chrome Custom Tabs لنظام Android (وإلا فلن تعمل مفاتيح المرور على أي حال).

Want to experiment with passkey flows? Try our Passkeys Debugger.

Try for Free

فيما يلي، نذكر أسباب هذه التوصية:

5.1 مشاركة ملفات تعريف الارتباط والبيانات مع المتصفح#

تشارك SFAuthenticationSession / ASWebAuthenticationSession ملفات تعريف الارتباط وبيانات موقع الويب مع Safari، مما يوفر تجربة مستخدم سلسة أثناء عمليات المصادقة. ينطبق الشيء نفسه على Chrome Custom Tabs على Android.

يستفيد المستخدمون من كلمات المرور المحفوظة وبيانات الملء التلقائي والمعلومات الأخرى المخزنة في المتصفح، مما يجعل عملية المصادقة أكثر سلاسة وسرعة.

5.2 أمان معزز#

توفر SFAuthenticationSession / ASWebAuthenticationSession على iOS و Chrome Custom Tabs على Android مساحة آمنة ومعزولة لمصادقة المستخدم، مما يضمن حماية بيانات اعتماد المستخدم الحساسة وعدم مشاركتها عن غير قصد مع التطبيق أو مواقع الويب الأخرى.

تلتزم ببروتوكولات الأمان الصارمة لشركة Apple و Google، مما يضمن التعامل مع بيانات المستخدم بشكل آمن والحفاظ على الخصوصية.

علاوة على ذلك، يستفيد هذا الخيار التصميمي من تحديثات وتحسينات الأمان المستمرة لـ Safari و Chrome، مما يضمن التزامه بأحدث معايير وبروتوكولات الأمان.

5.3 تجربة المستخدم#

توفر SFAuthenticationSession / ASWebAuthenticationSession على iOS و Chrome Custom Tabs على Android واجهة مستخدم متسقة ومألوفة، حيث اعتاد المستخدمون على تجربة مستخدم المتصفح. إلى جانب ذلك، يتم تطبيق إعدادات وتفضيلات مستخدم Safari و Chrome.

يوفر انتقالًا سلسًا بين محتوى التطبيق ومحتوى الويب، مما يضمن عدم انزعاج المستخدمين من التحول بين الواجهات.

5.4 الأداء#

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

غالبًا ما يكون أداء CCT متفوقًا على خيارات Android WebView (نفس الشيء مع SFAuthenticationSession / ASWebAuthenticationSession على iOS)، مما يضمن التعامل مع محتوى الويب وتدفقات المصادقة بسرعة وسلاسة.

انظر أيضًا هذه المقارنة من Google لتشعر بفروق الأداء بين Chrome Custom Tabs و Android WebView ومتصفح Chrome القياسي.

5.5 مخصص لتدفقات المصادقة#

تم تصميم SFAuthenticationSession / ASWebAuthenticationSession خصيصًا للتعامل مع تدفقات المصادقة المستندة إلى OAuth / OpenID Connect، مما يضمن عملية مبسطة وآمنة لبروتوكولات المصادقة المستخدمة على نطاق واسع. إنها أيضًا الطريقة الموصى بها لمصادقة WebAuthn / مفاتيح المرور.

على Android، لا توجد فئة مخصصة لتدفقات المصادقة ولكن يمكن تنفيذ سلوك مشابه باستخدام Chrome Custom Tabs و Android App Links.

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

6. الخلاصة#

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