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

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

Get free Whitepaper

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

عوامل اتخاذ القرار الرئيسية:

• هل تعتمد على تسجيل الدخول القائم على OAuth؟ ← WebView النظام (ASWebAuthenticationSession، Chrome Custom Tabs)
• هل ترغب في إعادة استخدام مصادقة الويب في غلاف أصلي؟ ← WebView المدمج (WKWebView، WebView الخاص بـ Android مع WebKit 1.12.1+)
• هل تبني تطبيقًا أصليًا بالكامل؟ ← التنفيذ الأصلي (Apple AuthenticationServices، Google Credential Manager)

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

1. التنفيذ الأصلي: بناء تدفقات مفاتيح المرور مباشرة في تطبيقك باستخدام واجهات برمجة التطبيقات (APIs) الخاصة بالمنصة (AuthenticationServices على iOS، و Credential Manager على Android). يوفر أفضل تجربة للمستخدم مع مصادقة بيومترية سلسة، ولكنه يتطلب جهدًا تقنيًا متوسطًا إلى عاليًا في التنفيذ.

2. WebView النظام: استخدام مكون المتصفح الخاص بالمنصة (ASWebAuthenticationSession / SFSafariViewController على iOS، و Chrome Custom Tabs على Android) للتعامل مع المصادقة. ممتاز لتدفقات تسجيل الدخول القائمة على OAuth ويشارك بيانات الاعتماد مع متصفح النظام.

3. WebView المدمج: تضمين عرض ويب قابل للتخصيص (WKWebView على iOS، و WebView على Android) داخل تطبيقك لإعادة استخدام مصادقة الويب مع هيكل تطبيق أصلي. يوفر مظهرًا شبيهًا بالتطبيقات الأصلية بدون أشرطة URL وتحكم كامل في واجهة المستخدم الخاصة بعرض الويب. يتطلب إعدادًا إضافيًا بما في ذلك الأذونات والصلاحيات (iOS)، وتهيئة WebView مع AndroidX WebKit 1.12.1+ (Android) لتمكين وظائف مفاتيح المرور.

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

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

متى تختار التنفيذ الأصلي:

• بناء تطبيق أصلي جديد أو إعادة هيكلة المصادقة إلى شاشات أصلية
• الرغبة في الحصول على أفضل تجربة مستخدم ممكنة مع مصادقة فورية وصامتة
• مطالبات مفاتيح المرور التلقائية عند بدء تشغيل التطبيق: يمكن للتطبيقات الأصلية استخدام preferImmediatelyAvailableCredentials لعرض طبقة عرض مفاتيح المرور تلقائيًا عند توفر مفاتيح المرور، مما يوفر أسرع تجربة تسجيل دخول دون الحاجة إلى إدخال المعرّف
• الحاجة إلى تحكم كامل في واجهة المستخدم وتدفق المصادقة
• الاستعداد للاستثمار في التنفيذ الخاص بالمنصة (Swift لـ iOS، Kotlin لـ Android)

الميزة الرئيسية: preferImmediatelyAvailableCredentials()

يمكن للتطبيقات الأصلية الاستفادة من preferImmediatelyAvailableCredentials() لإنشاء طبقة عرض تلقائية لمفاتيح المرور تظهر فور بدء تشغيل التطبيق عند توفر مفاتيح المرور. يوفر هذا التدفق الذي لا يتطلب اسم مستخدم أسرع تجربة تسجيل دخول ممكنة - يرى المستخدمون مفاتيح المرور الخاصة بهم على الفور دون إدخال معرّف أولاً. هذه الإمكانية حصرية للتطبيقات الأصلية وغير متوفرة في متغيرات WebView.

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

نظرة عامة على المتطلبات الفنية:

يتطلب التكامل الأصلي لمفاتيح المرور ثقة تشفيرية بين تطبيقك ونطاق الويب. بدونها، سيرفض نظام التشغيل جميع عمليات WebAuthn. المتطلبات الرئيسية:

1. ملفات ربط التطبيق بالنطاق مستضافة في /.well-known/
2. معرف الطرف المعتمد (Relying Party ID) الصحيح مطابق لنطاق الويب الخاص بك
3. القدرات الخاصة بالمنصة (مفصلة في القسم 4)

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

يتضمن تنفيذ مفاتيح المرور أصليًا على iOS استخدام إطار عمل AuthenticationServices من Apple، والذي يوفر واجهة برمجة تطبيقات لعمليات WebAuthn:

المكونات الرئيسية:

• ASAuthorizationController: يدير تدفق المصادقة
• ASAuthorizationPlatformPublicKeyCredentialProvider: ينشئ طلبات مفاتيح المرور
• ثلاثة أوضاع لواجهة المستخدم للتعامل مع عمليات تسجيل الدخول باستخدام مفاتيح المرور:
  • تسجيل الدخول عبر حقل النص: حقل اسم المستخدم التقليدي مع بدء تسجيل الدخول بمفتاح المرور عند الضغط على الزر
  • طبقة عرض مشروطة لمفاتيح المرور: مربع حوار نظام التشغيل يعرض مفاتيح المرور المتاحة
  • واجهة المستخدم الشرطية (Conditional UI): اقتراحات مفاتيح المرور في شريط QuickType فوق لوحة المفاتيح

نصائح للتطوير

• التخزين المؤقت لـ AASA: تقوم Apple بتخزين ملف AASA مؤقتًا بشكل مكثف (حتى 24 ساعة)، مما قد يعقد عملية الاختبار. الحل: قم بتمكين وضع المطور (Developer Mode) على جهاز الاختبار وأضف ?mode=developer إلى عنوان URL الخاص بـ AASA لفرض جلب نسخة جديدة
• اختبار الأداء: اختبر باستخدام حسابات iCloud التي تحتوي على مئات من بيانات الاعتماد لملاحظة زمن الوصول في العالم الحقيقي. قد تظهر طبقة عرض النظام تأخيرًا طفيفًا مع وجود العديد من مفاتيح المرور المخزنة

يستخدم تنفيذ مفاتيح المرور الأصلي على Android واجهة برمجة تطبيقات Credential Manager (أو واجهة برمجة تطبيقات FIDO2 الأقدم للتوافق مع الإصدارات السابقة):

المكونات الرئيسية:

• CredentialManager: واجهة برمجة التطبيقات المركزية لجميع عمليات بيانات الاعتماد
• CreatePublicKeyCredentialRequest: لتسجيل مفتاح المرور
• GetCredentialRequest: لمصادقة مفتاح المرور
• وضعان رئيسيان لواجهة المستخدم:
  • تسجيل الدخول عبر حقل النص: حقل اسم المستخدم التقليدي مع بدء تسجيل الدخول بمفتاح المرور عند الضغط على الزر
  • طبقة عرض مشروطة لمفاتيح المرور: مربع حوار نظام التشغيل يعرض مفاتيح المرور المتاحة

ملاحظة: يفتقر Android حاليًا إلى اقتراحات لوحة المفاتيح في الواجهة الشرطية (Conditional UI) الموجودة في iOS للتطبيقات الأصلية (على الرغم من أن Conditional UI تعمل في تطبيقات الويب)

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

1. على سبيل المثال، واجه فريقنا مشكلات مثل التخزين المؤقت المكثف من Apple لملف apple-app-site-association (المستخدم لربط بيانات اعتماد التطبيق/الويب) والاختلافات الدقيقة في واجهة المستخدم في بعض مطالبات المقاييس الحيوية لمصنعي المعدات الأصلية (OEM) على Android.
2. علاوة على ذلك، ضع في اعتبارك أنه في بعض سيناريوهات الشركات، قد يتم تعطيل مزامنة مفاتيح المرور بواسطة السياسات المطبقة على الأجهزة المدارة. في بيئات الشركات حيث يتم إيقاف تشغيل مزامنة iCloud Keychain أو Google Password Manager، تصبح مفاتيح المرور مرتبطة بالجهاز ولن تنتقل - وهو سيناريو مهم يجب التخطيط له (على سبيل المثال، ضمان أن يتمكن المستخدمون من تسجيل الدخول إذا حصلوا على هاتف جديد).
3. بالإضافة إلى ذلك، يمكن أن تؤثر تطبيقات إدارة بيانات الاعتماد التابعة لجهات خارجية على التدفق. على سبيل المثال، إذا كان لدى المستخدم مدير كلمات مرور مثل 1Password معينًا كموفر بيانات اعتماد نشط، فغالبًا ما سيعترض عملية إنشاء وتخزين مفاتيح المرور، ويأخذ الأولوية على مدير بيانات الاعتماد الأصلي للمنصة.

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

توصية: بالنسبة للتطبيقات الأصلية، نوصي باستخدام Corbado SDKs (iOS Swift Passkey SDK، Android Kotlin Passkey SDK) التي تتعامل مع الحالات الخاصة العديدة التي تم اكتشافها من خلال عمليات النشر الإنتاجية، وتوفر قياسات عن بعد واختبارات إضافية.

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.

ابدأ التجربة المجانية

تستخدم WebView النظام مكون المتصفح الأصلي للمنصة للتعامل مع المصادقة داخل تطبيقك. على عكس التطبيقات الأصلية بالكامل، تعرض WebView النظام محتوى الويب باستخدام متصفح النظام الفعلي (Safari على iOS، و Chrome على Android)، مع الحفاظ على ملفات تعريف الارتباط المشتركة، وبيانات الاعتماد المحفوظة، ومؤشرات الأمان المألوفة للمتصفح.

متى تختار WebView النظام:

• يستخدم تطبيقك تسجيل الدخول القائم على OAuth: WebView النظام هو النهج الموصى به لتدفقات OAuth2/OIDC، مما يوفر مصادقة آمنة
• وجود مصادقة قائمة على الويب ترغب في إعادة استخدامها في تطبيقات الهاتف المحمول
• الحاجة إلى دعم طرق مصادقة متعددة (كلمات المرور، تسجيل الدخول الاجتماعي، مفاتيح المرور) دون إعادة البناء أصليًا
• الرغبة في الحفاظ على قاعدة كود مصادقة واحدة عبر الويب والجوال

المزايا الرئيسية:

• توافق مع OAuth: مصمم خصيصًا لتدفقات مصادقة OAuth/OIDC
• مؤشرات الأمان: يرى المستخدمون عنوان URL الفعلي وشهادات SSL، مما يبني الثقة
• جهد تنفيذ منخفض: يتطلب الحد الأدنى من الكود الأصلي
• تجربة مستخدم متسقة: واجهة متصفح مألوفة يثق بها المستخدمون بالفعل

مكونات المنصة:

• iOS: ASWebAuthenticationSession (موصى به لتدفقات المصادقة) أو SFSafariViewController (للتصفح العام)
• Android: Chrome Custom Tabs (CCT)

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

يوفر iOS مكونين رئيسيين لـ WebView النظام للمصادقة:

ASWebAuthenticationSession (موصى به للمصادقة):

• مصمم خصيصًا لتدفقات OAuth/OIDC وتسجيل الدخول الآمن
• يطالب المستخدم تلقائيًا بأن التطبيق يريد المصادقة
• يشارك ملفات تعريف الارتباط وبيانات الاعتماد مع Safari
• يدعم مفاتيح المرور عبر iCloud Keychain

SFSafariViewController (للتصفح العام):

• تجربة Safari كاملة داخل التطبيق
• يعرض شريط URL ومؤشرات الأمان
• لا يشارك ملفات تعريف ارتباط Safari على iOS 11+؛ استخدم ASWebAuthenticationSession عند الحاجة إلى مشاركة جلسة Safari
• أقل قابلية للتخصيص ولكنه أكثر جدارة بالثقة للمستخدمين

إذا كان تطبيقك يستخدم تسجيل الدخول القائم على OAuth، فإن ASWebAuthenticationSession هو الخيار الموصى به لأنه مصمم خصيصًا لسيناريوهات المصادقة ويوفر أفضل توازن بين الأمان وتجربة المستخدم.

توفر Chrome Custom Tabs (CCT) تجربة مصادقة مدعومة بـ Chrome داخل تطبيقك:

الميزات الرئيسية:

• تشارك ملفات تعريف الارتباط وبيانات الاعتماد مع متصفح Chrome
• تعرض عنوان URL ومؤشرات الأمان
• يمكن تخصيص لون شريط الأدوات والعلامة التجارية
• التسخين المسبق لأوقات تحميل أسرع

تكامل OAuth: Chrome Custom Tabs هي المكافئ في Android لـ ASWebAuthenticationSession في iOS، حيث توفر دعمًا ممتازًا لـ OAuth مع الحفاظ على الوصول إلى مفاتيح المرور المخزنة.

Want to try passkeys yourself in a passkeys demo?

Try Passkeys

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

متى تختار WebView المدمج:

• تجربة شبيهة بالتطبيقات الأصلية: يقوم تطبيقك بالفعل بتضمين المصادقة داخل عرض ويب مخصص للحفاظ على مظهر وإحساس أصلي، وتريد الحفاظ على تجربة المستخدم المتسقة هذه
• الحاجة إلى التحكم في الجلسة/ملفات تعريف الارتباط: يتطلب تطبيقك معالجة مباشرة لرموز المصادقة وحالة الجلسة بعد اكتمال مصادقة OAuth
• تدفق مصادقة حالي حيث تُرجع مصادقة WebView النظام رمز مصادقة ولكن لا توجد جلسة في السياقات المدمجة
• يجب الحفاظ على حالة المصادقة عبر شاشات ويب مدمجة متعددة
• مصادقة الطرف الأول فقط: يتعامل تطبيقك مع المصادقة مباشرة، لتطبيقات مفاتيح مرور الطرف الثالث انظر هنا
• AndroidX WebKit 1.12.1+ مع الكشف عن الميزات وقت التشغيل
• قبول قيود الواجهة الشرطية (Conditional UI) لتسجيل الدخول (غير مدعومة في WebView المدمج)، وهو أمر غير ذي صلة بإعدادات الإدارة

سياق مهم:

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

المتطلبات الفنية:

تتطلب WebView المدمجة إعدادًا إضافيًا مقارنة بـ WebView النظام:

1. iOS: صلاحيات النطاقات المرتبطة (Associated Domains)، تكوين ملف AASA
2. Android: AndroidX WebKit 1.12.1+ مع تكوين WebView WebAuthn (يتطلب الكشف عن الميزات)
3. كلاهما: ملفات الربط well-known مهيأة بشكل صحيح و Digital Asset Links

مكونات المنصة:

• iOS: WKWebView
• Android: android.webkit.WebView

المقايضات:

• تعقيد متوسط: يتطلب تكوين WebView (Android WebKit 1.12.1+) وإعداد الصلاحيات (iOS)
• تبني أقل لمفاتيح المرور: قد يواجه المستخدمون احتكاكًا أكبر مقارنة بالتنفيذ الأصلي
• الواجهة الشرطية (Conditional UI) غير مدعومة: الملء التلقائي لمفاتيح المرور في حقول الإدخال لا يعمل في WebView المدمج على Android
• دعم محدود للمنصة: قد لا تعمل بعض الميزات بشكل متسق (مثل الإنشاء التلقائي لمفاتيح المرور)

عند تنفيذ مفاتيح المرور عبر WebView، من الضروري فهم التمييز بين WebView النظام و WebView المدمج. كل من الأساليب الثلاثة الموضحة أعلاه (التنفيذ الأصلي، WebView النظام، و WebView المدمج) تخدم حالات استخدام مختلفة.

على iOS، لديك خيارات متعددة لعرض محتوى الويب داخل التطبيق:

• WKWebView هو مكون WebView قابل للتخصيص وهو جزء من إطار عمل WebKit (تم تقديمه في iOS 8). يمنحك الكثير من التحكم في مظهر وسلوك محتوى الويب.
• SFSafariViewController هو وحدة تحكم عرض تقدمها Apple تعمل كمتصفح Safari خفيف الوزن داخل تطبيقك. يستخدم محرك Safari. في iOS 11+، لديه مخزن ملفات تعريف ارتباط منفصل ولا يشارك ملفات تعريف ارتباط Safari. استخدم ASWebAuthenticationSession عند الحاجة إلى مشاركة جلسة Safari.
• SFAuthenticationSession / ASWebAuthenticationSession هي جلسات مصادقة ويب متخصصة (متوفرة منذ iOS 11/12) مخصصة خصيصًا لتدفقات OAuth/OpenID أو تدفقات تسجيل الدخول الآمنة الأخرى. تستفيد هذه أيضًا من Safari تحت الغطاء، ولكنها تركز على تدفقات المصادقة وتتعامل تلقائيًا مع أشياء مثل ملفات تعريف الارتباط المشتركة وتسجيل الدخول الموحد (SSO).

على Android، الخيارات الرئيسية هي:

• Android WebView هو أداة WebView القياسية (android.webkit.WebView)، وهي في الأساس متصفح صغير يمكن تضمينه في أنشطتك. إنه قابل للتخصيص بشكل كبير ولكنه يعمل في عملية تطبيقك.
• Chrome Custom Tabs (CCT) هي ميزة تفتح علامة تبويب مدعومة بـ Chrome داخل سياق تطبيقك. تظهر Custom Tabs كجزء من تطبيقك ولكنها مدعومة بمتصفح Chrome (إذا كان مثبتًا) مع ميزات مثل التحميل المسبق، وملفات تعريف الارتباط المشتركة، وشريط URL المألوف لثقة المستخدم.

في الأقسام التالية، سنتعمق قليلاً في أنواع WebView هذه لنظامي iOS و Android، ونناقش أيها قد يكون الأنسب لتدفقات مصادقة مفاتيح المرور.

Subscribe to our Passkeys Substack for the latest news.

Subscribe

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

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

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

يوفر SFSafariViewController تجربة Safari داخل التطبيق. عندما تفتح عنوان URL باستخدام SFSafariViewController، يكون الأمر أشبه بفتحه في متصفح Safari الحقيقي، باستثناء أن المستخدم يبقى داخل واجهة المستخدم الخاصة بتطبيقك. الميزة بالنسبة لمفاتيح المرور كبيرة: لأنه في الأساس Safari، يمكن الوصول إلى iCloud Keychain للمستخدم ومفاتيح المرور المحفوظة. لاحظ أن ملفات تعريف الارتباط لا تتم مشاركتها على iOS 11+. هذا يعني أنه إذا كان لدى المستخدم بالفعل مفتاح مرور لموقعك، يمكن لـ Safari العثور عليه وحتى عرض واجهة المستخدم الشرطية (Conditional UI) للملء التلقائي لتسهيل تسجيل الدخول. SFSafariViewController أقل قابلية للتخصيص (لا يمكنك تغيير شريط أدواته كثيرًا)، ولكنه يتعامل تلقائيًا مع الكثير من ميزات الأمان والخصوصية. يتم عرض شريط URL، مكتمل برمز القفل لـ HTTPS، مما يمنح المستخدمين الثقة بأنهم على النطاق الصحيح. بشكل عام، يعتبر SFSafariViewController أكثر أمانًا من WKWebView الخام وأبسط في التنفيذ (تقدمه Apple كعنصر جاهز). المقايضة الرئيسية هي أنك تضحي ببعض التحكم في المظهر والإحساس. بالنسبة لتدفق المصادقة، يكون ذلك مقبولًا عادةً. الأولوية هنا هي الأمان وسهولة تسجيل الدخول، وهو ما يتفوق فيه SFSafariViewController باستخدام سياق Safari.

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

الفائدة هي تجربة تسجيل دخول موحد (SSO) سلسة - إذا كان المستخدم قد سجل الدخول بالفعل إلى الموفر في Safari، فيمكن لهذه الجلسة استخدام ملف تعريف الارتباط هذا لتجنب تسجيل دخول آخر. بالنسبة لمفاتيح المرور، هذا مهم لأنه يعني أن أي بيانات اعتماد لمفتاح المرور مخزنة في Safari/iCloud Keychain يمكن استخدامها هنا أيضًا. الإرشادات الرسمية من Apple هي استخدام ASWebAuthenticationSession لأي شيء يشبه تدفق تسجيل الدخول. الإيجابيات هي الخصوصية المعززة (لا يرى تطبيقك أبدًا بيانات الاعتماد أو ملفات تعريف الارتباط، Safari يتعامل معها) ودعم تسجيل الدخول الموحد المدمج. السلبية هي أنها تقتصر على تدفقات المصادقة (لن تستخدمها فقط لعرض محتوى ويب عشوائي في تطبيقك). باختصار، إذا اخترت نهج WebView على iOS، فإن ASWebAuthenticationSession هو عادة الخيار الأفضل لتنفيذ مفاتيح المرور لأنه آمن، ويشارك الحالة مع Safari، ومصمم خصيصًا للمصادقة.

Want to find out how many people use passkeys?

View Adoption Data

على Android، يكون قرار WebView بين WebView الكلاسيكي و Chrome Custom Tabs:

لاختبار سلوك WebView المختلف في Android، نوصي بتطبيق WebView vs Chrome Custom Tabs.

Android WebView (android.webkit.WebView) هو مكون يتيح لك تضمين صفحات الويب في تخطيط نشاطك. إنه مشابه لـ WKWebView من حيث أنه يمنحك التحكم الكامل: يمكنك اعتراض التنقل، وحقن JavaScript، وتخصيص واجهة المستخدم، وما إلى ذلك. كما أنه يعمل ضمن عملية تطبيقك. استخدام WebView لمفاتيح المرور يعني أن تطبيقك يقوم بتحميل صفحة تسجيل الدخول على الويب الخاصة بك، ويمكن لتلك الصفحة بدء عملية WebAuthn لمفتاح المرور. يدعم Android WebView الحديث WebAuthn (بشرط أن يكون تنفيذ WebView للجهاز محدثًا عبر Android System WebView أو مكون Chrome). اعتبار رئيسي واحد: افتراضيًا، لا يشارك Android WebView ملفات تعريف الارتباط أو بيانات الاعتماد المخزنة مع متصفح Chrome الخاص بالمستخدم. لذا فإن أي مفتاح مرور تم إنشاؤه أو استخدامه في WebView قد لا يكون معروفًا لـ Chrome، والعكس صحيح. يمكن أن يكون هذا العزل جيدًا للأمان (لا يمكن لتطبيقك قراءة ملفات تعريف الارتباط الخاصة بالمتصفح)، ولكنه قد يجبر المستخدمين على تسجيل الدخول مرة أخرى إذا كانوا قد صادقوا بالفعل في Chrome. مشكلة أخرى هي الثقة. لا يعرض WebView العادي عنوان URL أو رمز قفل SSL، لذا يتعين على المستخدمين الوثوق بتطبيقك تمامًا حتى لا يتصيدهم. حتى أن Google حظرت استخدام WebView لعمليات تسجيل الدخول إلى Google OAuth بسبب مخاطر التصيد الاحتيالي المحتملة. من حيث الأداء، فإن WebViews جيدة، ولكنها يمكن أن تكون أبطأ أو أكثر استهلاكًا للذاكرة من استخدام المتصفح الافتراضي للمستخدم، خاصة عند تحميل الصفحات الثقيلة.

Chrome Custom Tabs (CCT) هي نهج هجين. تسمح لتطبيقك بفتح صفحة معروضة بواسطة Chrome تبدو وكأنها جزء من تطبيقك. يمكنك تخصيص لون شريط الأدوات، وإضافة شعار التطبيق، وما إلى ذلك، ولكن يتم عرض المحتوى بواسطة Chrome في عملية منفصلة. بالنسبة لمفاتيح المرور، تتمتع CCTs بالعديد من الفوائد: فهي تشارك ملفات تعريف الارتباط وبيانات الاعتماد الخاصة بالمستخدم مع Chrome، مما يعني أنه إذا كان لدى المستخدم مفتاح مرور محفوظ عبر Chrome (Google Password Manager)، فيمكن لـ Custom Tab الوصول إليه. سيرى المستخدم أيضًا عنوان URL الفعلي ومؤشرات الأمان، مما يبني الثقة. غالبًا ما يكون الأداء أفضل - يمكن "تسخين" Chrome في الخلفية لتحميل أسرع. والأهم من ذلك، أن الأمان قوي: نظرًا لأنه في الأساس تطبيق Chrome، فإن أشياء مثل Google Safe Browsing تحمي الجلسة، ولا يمكن لتطبيقك حقن نصوص برمجية عشوائية في الصفحة (مما يمنع هجمات معينة).

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

(ملاحظة جانبية: هناك العديد من أوجه التشابه بين WKWebView مقابل SFSafariViewController في Apple و WebView مقابل CCT في Android. يشارك كل من Safari VC و Chrome Tabs حالة المتصفح ويوفران أمانًا أفضل، بينما يمنح WKWebView/Android WebView مزيدًا من التحكم ولكنه يعزل محتوى الويب. بالنسبة لمفاتيح المرور، عادة ما تكون مشاركة الحالة (ملفات تعريف الارتباط، مخازن بيانات الاعتماد) مرغوبة حتى يمكن الوصول إلى مفتاح المرور وإنشائه بسلاسة.)

بغض النظر عن نهج التنفيذ الذي تختاره، يجب تلبية متطلبات فنية معينة لتمكين وظائف مفاتيح المرور. يقدم هذا القسم إرشادات شاملة حول تكوين ملفات الربط المعروفة (well-known association files)، وصلاحيات iOS، وتكوين Android WebView.

ملاحظة حول الأجهزة المدارة: يتغير سلوك مفاتيح المرور بشكل كبير على الأجهزة المدارة حيث تتحكم سياسات إدارة الأجهزة المحمولة (MDM) في تخزين بيانات الاعتماد.

تتطلب تدفقات WebView الأصلية والمدمجة ملفات ربط لإنشاء ثقة تشفيرية بين تطبيقك ونطاق الويب. لا يتطلب WebView النظام (ASWebAuthenticationSession) و Chrome Custom Tabs ربط التطبيق بالموقع.

ينشئ ملف AASA الاتصال بين تطبيق iOS الخاص بك ونطاق الويب الخاص بك، مما يمكّن مفاتيح المرور من العمل عبر كلا المنصتين.

موقع الملف: https://yourdomain.com/.well-known/apple-app-site-association

متطلبات التكوين:

• استضفه في /.well-known/apple-app-site-association على نطاقك
• قدمه عبر HTTPS مع شهادة SSL صالحة
• Content-Type: application/json
• لا توجد عمليات إعادة توجيه على مسار .well-known
• قم بتضمين معرف فريق (Team ID) ومعرف حزمة (Bundle ID) تطبيقك

مثال على ملف AASA:

{
    "webcredentials": {
        "apps": ["TEAMID123.com.example.app"]
    }
}

التخزين المؤقت واختبار AASA:

تقوم Apple بتخزين ملفات AASA مؤقتًا بشكل مكثف (حتى 24-48 ساعة) باستخدام CDN، مما قد يعقد التطوير والاختبار. لتجاوز التخزين المؤقت أثناء التطوير:

1. قم بتمكين وضع المطور (Developer Mode) على جهاز الاختبار الخاص بك
2. أضف ?mode=developer إلى نطاقك المرتبط في Xcode
3. هذا يجبر iOS على جلب أحدث ملف AASA مباشرة من الخادم الخاص بك

⚠️ مهم: لا تستخدم ?mode=developer في إصدارات الإنتاج. هذا المعلمة مخصصة للتطوير فقط - استخدامها في الإنتاج سيمنع iOS من اكتشاف ملف AASA الخاص بك بشكل صحيح، مما يؤدي إلى تعطيل وظائف مفاتيح المرور.

التحقق: استخدم مدقق AASA من Apple للتحقق من التكوين الخاص بك.

يستخدم Android روابط الأصول الرقمية (Digital Asset Links) للتحقق من العلاقة بين تطبيقك وموقع الويب الخاص بك.

موقع الملف: https://yourdomain.com/.well-known/assetlinks.json

متطلبات التكوين:

• استضفه في /.well-known/assetlinks.json على نطاقك
• قدمه عبر HTTPS مع شهادة صالحة
• Content-Type: application/json
• قم بتضمين بصمة SHA256 لتطبيقك (من شهادة التوقيع)

مثال على ملف assetlinks.json:

[
    {
        "relation": [
            "delegate_permission/common.handle_all_urls",
            "delegate_permission/common.get_login_creds"
        ],
        "target": {
            "namespace": "android_app",
            "package_name": "com.example.app",
            "sha256_cert_fingerprints": [
                "AA:BB:CC:DD:EE:FF:00:11:22:33:44:55:66:77:88:99:AA:BB:CC:DD:EE:FF:00:11:22:33:44:55:66:77:88:99"
            ]
        }
    }
]

التحقق: استخدم مولد روابط الأصول الرقمية من Google لإنشاء التكوين الخاص بك والتحقق منه.

تتطلب تطبيقات iOS صلاحيات (entitlements) مناسبة للوصول إلى وظائف مفاتيح المرور. تختلف المتطلبات قليلاً بناءً على نهج التنفيذ الخاص بك.

يحدد ملف الصلاحيات (غالبًا ما يسمى Runner.entitlements في تطبيقات Flutter أو YourApp.entitlements في مشاريع iOS الأصلية) الأذونات والقدرات الخاصة التي يمنحها نظام Apple. بالنسبة لمفاتيح المرور، يقوم هذا الملف بتكوين النطاقات المرتبطة (Associated Domains).

موقع الملف: عادةً في مشروع Xcode الخاص بك في ios/Runner/Runner.entitlements

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

الإعداد في Xcode:

1. افتح مشروعك في Xcode
2. حدد هدف تطبيقك
3. انتقل إلى علامة التبويب "Signing & Capabilities"
4. انقر فوق "+ Capability" وأضف "Associated Domains"
5. أضف نطاقك مع البادئة webcredentials:

مثال على التكوين:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>com.apple.developer.associated-domains</key>
    <array>
        <string>webcredentials:yourdomain.com</string>
        <string>webcredentials:subdomain.yourdomain.com</string>
    </array>
</dict>
</plist>

نطاقات متعددة: إذا كان تطبيقك يحتاج إلى العمل مع نطاقات متعددة، فقد تحتاج إلى طلبات الأصل المرتبطة (Related Origin Requests - ROR).

اكتسبت Android Embedded WebViews دعم WebAuthn الأصلي مع AndroidX WebKit 1.12، مما يلغي الحاجة إلى كود جسر JavaScript مخصص. لا يتطلب WebView النظام (Chrome Custom Tabs) أي تكوين - تعمل بيانات الاعتماد تلقائيًا.

المتطلبات:

• AndroidX WebKit 1.12.1 أو أحدث (موصى به 1.14.0+)
• تكوين روابط الأصول الرقمية
• حزمة APK لـ WebView مع دعم WebAuthn (تحقق عبر اكتشاف الميزات)
• ملاحظة: مكتبة AndroidX Credentials غير مطلوبة لـ WebView WebAuthn، فقط للتطبيقات الأصلية بالكامل

التنفيذ:

import androidx.webkit.WebSettingsCompat
import androidx.webkit.WebViewFeature
 
// Check if Web Authentication is supported
if (WebViewFeature.isFeatureSupported(WebViewFeature.WEB_AUTHENTICATION)) {
    // Enable Web Authentication
    WebSettingsCompat.setWebAuthenticationSupport(
        webView.settings,
        WebSettingsCompat.WEB_AUTHENTICATION_SUPPORT_FOR_APP
    )
 
    // Enable JavaScript
    webView.settings.javaScriptEnabled = true
}

نقاط رئيسية:

• لا حاجة لجسر JavaScript: يعمل WebAuthn أصليًا في WebView
• يتطلب اكتشاف الميزات: تحقق دائمًا من WebViewFeature.WEB_AUTHENTICATION في وقت التشغيل
• الواجهة الشرطية (Conditional UI) غير مدعومة: mediation:"conditional" (الملء التلقائي لمفتاح المرور في حقول الإدخال) لا يعمل في WebView المدمج
• استراتيجية احتياطية: إذا لم تكن الميزة متاحة، فاستخدم Chrome Custom Tabs بدلاً من ذلك

ملاحظات الإصدار:

• استخدم WebKit 1.12.1 أو أحدث (كان لدى 1.12.0 مشكلة في التوفر وقت التشغيل)
• يعتمد دعم الميزة على إصدار APK الخاص بـ WebView للمستخدم - لن تعرض حزم APK الأقدم على الجهاز الميزة

قبل AndroidX WebKit 1.12.0، لم يكن دعم WebAuthn الأصلي موجودًا في WebView المدمج. كان على الفرق إما:

1. استخدام Chrome Custom Tabs أو Auth Tab (موصى به)
2. بناء جسر JavaScript مخصص

إذا كنت بحاجة إلى دعم إصدارات Android الأقدم أو الأجهزة التي لا تحتوي على حزم APK محدثة لـ WebView، فراجع دليل تكامل WebView مع Credential Manager الخاص بـ Android للحصول على نهج كود الجسر. ومع ذلك، نوصي بشدة باستخدام نهج WebKit 1.12.1+ الأصلي للتطبيقات الحديثة.

توصية: استخدم دعم WebAuthn الأصلي مع AndroidX WebKit 1.12.1+. إذا لم يكن متاحًا في وقت التشغيل، فارجع إلى Chrome Custom Tabs التي توفر دعمًا ممتازًا لمفاتيح المرور مع بيانات اعتماد مشتركة.

عند تنفيذ مفاتيح المرور في التطبيقات الأصلية، تحتاج إلى إنشاء ثقة بين تطبيقك ونطاق(ات) الويب. يغطي هذا القسم كيفية التعامل مع النطاقات الفردية، والنطاقات المتعددة المرتبطة (ROR)، وكيفية التحقق من تكوين ملفات الربط well-known بشكل صحيح.

للتطبيقات التي تستخدم نطاقًا واحدًا (مثل kayak.com)، تحتاج إلى:

• ملف AASA واحد لنظام iOS على https://kayak.com/.well-known/apple-app-site-association
• ملف assetlinks.json واحد لنظام Android على https://kayak.com/.well-known/assetlinks.json
• صلاحية النطاقات المرتبطة مهيأة بـ webcredentials:kayak.com

الأصول المرتبطة (ROR) هي ميزة WebAuthn تسمح لمجموعة واحدة من مفاتيح المرور بالعمل عبر نطاقات متعددة ذات صلة (على سبيل المثال، kayak.com، kayak.de، kayak.co.uk). تستخدم ROR نقطة النهاية /.well-known/webauthn على كل موقع لتحديد الأصول المرتبطة، وليس ملفات AASA أو assetlinks.

نقاط رئيسية:

• تكوين ROR: يستضيف كل نطاق /.well-known/webauthn مع قائمة الأصول المرتبطة
• ملفات ربط التطبيق (AASA/assetlinks): تستخدم فقط لربط التطبيقات بمواقعها المقابلة
• WebView المدمج في iOS 18+: يدعم ROR عند تكوينه بشكل صحيح
• صلاحيات النطاقات المرتبطة: قم بتضمين جميع النطاقات التي يحتاج تطبيقك إلى المصادقة معها

مثال على التكوين:

إذا كان تطبيقك يعمل مع kayak.com و kayak.de، فيجب على كلا النطاقين:

• استضافة ملفات AASA الخاصة بكل منهما بنفس معرف الفريق ومعرف الحزمة
• أن يكونا مدرجين في صلاحيات النطاقات المرتبطة لتطبيقك
• أن يكون لديهما ملفات well-known مهيأة بشكل صحيح ويمكن الوصول إليها

قبل الإطلاق، تحقق من أن ملفات well-known الخاصة بك مهيأة بشكل صحيح ويمكن الوصول إليها. توفر Apple و Google عناوين URL اختبارية قائمة على CDN للتحقق من توفر الملفات:

استخدام عناوين URL الاختبارية هذه:

• انقر على الروابط للتحقق مما إذا كان بإمكان Apple/Google استرداد ملفات well-known الخاصة بك
• معلمة ?nocache=1 من Apple تفرض استردادًا جديدًا، متجاوزة ذاكرة التخزين المؤقت لـ CDN
• إذا لم تكن الملفات قابلة للوصول عبر عناوين URL هذه، فلن تعمل وظيفة مفتاح المرور في تطبيقك
• استبدل kayak.com أو kayak.de بنطاقك(اتك) الخاص في أنماط URL أعلاه

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

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

ابدأ بهذه الأسئلة الرئيسية:

1. هل يستخدم تطبيقك تسجيل الدخول القائم على OAuth (OAuth2، OIDC، موفرو تسجيل الدخول الاجتماعي)؟

   • نعم ← WebView النظام (القسم 1.2)
     • iOS: استخدم ASWebAuthenticationSession
     • Android: استخدم Chrome Custom Tabs
     • دعم ممتاز لـ OAuth مع بيانات اعتماد مشتركة

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

   • نعم ← WebView المدمج (القسم 1.3) مع التكوين
   • iOS: WKWebView + صلاحيات النطاقات المرتبطة
   • Android: WebView + تكوين AndroidX WebKit 1.12.1+
   • يوفر مظهرًا شبيهًا بالأصلي مع إعادة استخدام مكونات الويب
   • ملاحظة: الواجهة الشرطية (Conditional UI) غير مدعومة في WebView المدمج
   • لا ← فكر في WebView النظام أو التنفيذ الأصلي

3. هل تبني تطبيقًا أصليًا جديدًا أو لديك شاشات تسجيل دخول أصلية؟

   • نعم ← التنفيذ الأصلي (القسم 1.1)
     • أفضل تجربة للمستخدم
     • مصادقة فورية وصامتة
     • يتطلب تطويرًا خاصًا بالمنصة

4. هل لديك مصادقة ويب حالية ترغب في إعادة استخدامها؟

   • نعم ← WebView النظام لتنفيذ سريع
   • لا ← التنفيذ الأصلي للحصول على تجربة مستخدم مثلى

إليك كيفية أداء كل نهج عبر الأبعاد الرئيسية:

شرح الأبعاد:

• إنشاء مفاتيح المرور: مدى سهولة إنشاء المستخدمين لمفاتيح المرور من خلال هذا النهج
• استخدام مفاتيح المرور: تجربة المصادقة عند استخدام مفاتيح المرور الحالية
• إدارة مفاتيح المرور: كيف يمكن للمستخدمين عرض أو تعديل أو حذف مفاتيح المرور
• التعقيد التقني: جهد التطوير والصيانة المستمرة
• دعم OAuth: مدى جودة تعامل النهج مع تدفقات مصادقة OAuth2/OIDC
• وقت الإعداد: الجدول الزمني للتنفيذ النموذجي

الموصى به: WebView النظام

إذا كان تطبيقك يصادق عبر OAuth2، OIDC أو موفري تسجيل الدخول الاجتماعي (Google، GitHub، Microsoft، إلخ)، فإن WebView النظام هو الخيار الأمثل:

• iOS: ASWebAuthenticationSession مصمم خصيصًا لتدفقات OAuth
• Android: توفر Chrome Custom Tabs تكاملًا سلسًا لـ OAuth
• الفوائد: الحد الأدنى من الكود الأصلي، مشاركة بيانات الاعتماد تلقائيًا
• التنفيذ: أضف WebAuthn إلى صفحة مصادقة الويب الخاصة بك، ثم قم بتحميلها عبر WebView النظام

مثال: تستخدم تطبيقات السفر مثل kayak.com و kayak.de OAuth للمصادقة. يسمح لهم WebView النظام بالحفاظ على بنيتهم التحتية الحالية لـ OAuth مع إضافة دعم مفاتيح المرور من خلال صفحات مصادقة الويب الخاصة بهم.

الموصى به: نهج هجين

استخدم WebView النظام للمصادقة الأولية عبر OAuth، ثم WebView المدمج لجلسات ما بعد المصادقة:

1. المصادقة الأولية: يتعامل WebView النظام مع تسجيل الدخول عبر OAuth + مفتاح المرور
2. إدارة الجلسة: انتقل إلى WebView المدمج لمحتوى الويب المصادق عليه حيث تحتاج إلى التحكم في ملفات تعريف الارتباط/الجلسة
3. الإعداد الفني: قم بتكوين متطلبات WebView النظام والمدمج - بالنسبة لـ Android، تأكد من تضمين AndroidX WebKit 1.12.1+ (انظر القسم 5)

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

الموصى به: التنفيذ الأصلي

هل تبني من الصفر أو لديك شاشات أصلية؟ اذهب إلى التنفيذ الأصلي بالكامل:

• iOS: استخدم إطار عمل AuthenticationServices
• Android: استخدم واجهة برمجة تطبيقات Credential Manager
• الفوائد: أفضل تجربة مستخدم، مصادقة فورية، تحكم كامل
• ميزة فريدة: استخدم preferImmediatelyAvailableCredentials لعرض طبقة عرض مفتاح المرور التلقائية عند بدء تشغيل التطبيق - حصري للتطبيقات الأصلية ويوفر أعلى معدلات التحويل
• توصية SDK: استخدم Corbado SDKs (iOS، Android) لتسريع التطوير مع معالجة الحالات الخاصة التي تم اختبارها في الإنتاج

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

الموصى به: ترحيل مرحلي

• المرحلة 1: مفاتيح مرور WebView النظام - أضف دعم مفاتيح المرور إلى تسجيل الدخول على الويب الحالي، وقم بالتحميل عبر WebView النظام (ASWebAuthenticationSession/Chrome Custom Tabs). فوز سريع بأقل قدر من الكود الأصلي.
• المرحلة 2: اعتراض أصلي - أضف فحص مفتاح مرور أصلي قبل عرض WebView. مثال: يحاول kayak.com مصادقة مفتاح المرور الأصلي أولاً، ويعود إلى WebView إذا لزم الأمر. يوفر تسجيل دخول بيومتري سريع مع الحفاظ على التوافق مع الإصدارات السابقة.
• المرحلة 3: أصلي بالكامل - انتقل تدريجيًا إلى المصادقة الأصلية لمستخدمي مفاتيح المرور، مع الاحتفاظ بـ WebView للطرق القديمة.

يسمح هذا النهج المرحلي بإجراء تحسينات تدريجية دون تعطيل المستخدمين الحاليين.

راجع القسم 5 للحصول على إرشادات تكوين مفصلة.

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

فئات الاختبار الأساسية:

• الرحلات الأساسية: التسجيل، المصادقة، التدفقات عبر الأجهزة، حذف مفتاح المرور
• تغطية المنصة: iOS (أصلي)، Android (أصلي)، متصفحات الويب عبر إصدارات أنظمة التشغيل
• ربط النطاق: تحقق من إمكانية الوصول إلى ملفات AASA (iOS) وروابط الأصول الرقمية (Android)
• تدفقات الإلغاء: اختبار إلغاء المستخدم في مطالبات نظام التشغيل وشاشات القياسات الحيوية
• معالجة الأخطاء: فشل الواجهة الخلفية، مهلات الشبكة، عدم تطابق بيانات الاعتماد
• الحالات الخاصة: قفل الشاشة معطل، iCloud/Google Password Manager معطل
• تدفقات OAuth: إكمال تكامل OAuth + مفتاح المرور من البداية إلى النهاية
• الأجهزة المدارة: بيئات خاضعة لرقابة MDM
• مديرو الطرف الثالث: توافق 1Password، Bitwarden، Dashlane
• المصادقة عبر الأجهزة: تدفقات رمز QR واختبار النقل الهجين
• خاص بـ WebView المدمج: إذا كنت تستخدم WebView المدمج، تحقق من تكوين WebKit 1.12.1+ على Android
• مراقبة الإنتاج: لوحة معلومات لمعدلات النجاح والفشل وزمن الوصول

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

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

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

مثال: بعد تسجيل الدخول عبر OAuth باستخدام WebView النظام، أظهر مطالبة أصلية: "هل ترغب في تمكين تسجيل دخول أسرع باستخدام Face ID؟" إذا تم القبول، قم بإنشاء مفتاح مرور من خلال صفحة الويب المحملة في WebView النظام.

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

للتطبيقات القائمة على OAuth: يعد WebView النظام (ASWebAuthenticationSession، Chrome Custom Tabs) هو نقطة البداية الموصى بها. إنه يوفر دعمًا ممتازًا لـ OAuth، وأقل جهد في التنفيذ، ومشاركة تلقائية لبيانات الاعتماد.

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

لمتطلبات إطار WebView المدمج: يستخدم WebView المدمج بشكل شائع في سيناريوهين واقعيين. أولاً، غالبًا ما تستخدم التطبيقات القائمة على OAuth WebView النظام لتدفق تسجيل الدخول الأولي، ثم تنتقل إلى WebView المدمج لعرض خيارات إدارة مفاتيح المرور في شاشات الإعدادات حيث يلزم التحكم في الجلسة - على الرغم من أن بعض التطبيقات تبسط هذا عن طريق الاحتفاظ بـ WebView النظام لكلا التدفقين. ثانيًا، التطبيقات التي قامت بالفعل بتضمين تدفق المصادقة الخاص بها في إطارات WebView قبل اعتماد مفاتيح المرور تواصل هذا النمط من أجل الاتساق. يتطلب WebView المدمج مع دعم WebAuthn الأصلي (AndroidX WebKit 1.12.1+) تكوينًا وإعدادًا (أذونات، صلاحيات، إعدادات WebView) ولكنه لم يعد بحاجة إلى كود جسر JavaScript مخصص. لاحظ أن الواجهة الشرطية (Conditional UI) غير مدعومة في WebView المدمج. اختر هذا النهج عند الحفاظ على أنماط المصادقة المدمجة الحالية أو عندما تحتاج إلى التحكم في الجلسة/ملفات تعريف الارتباط لشاشات ما بعد المصادقة.

في النهاية، تمثل مفاتيح المرور في التطبيقات الأصلية قفزة هائلة إلى الأمام في كل من راحة المستخدم وأمانه. سواء تم تنفيذها عبر Native أو System WebView أو Embedded WebView، فإنها تقضي على مخاطر التصيد الاحتيالي وأعباء إدارة كلمات المرور لمستخدميك. تُظهر التطبيقات الواقعية مثل تكامل مفاتيح المرور في تطبيق VicRoads الأصلي أن الأساليب الأصلية أولاً تحقق أعلى نسبة تبني ورضا للمستخدم عند تنفيذها بشكل صحيح مع ميزات مثل طبقات مفاتيح المرور التلقائية. باتباع أفضل الممارسات للمصادقة سهلة الاستخدام واختيار نهج التنفيذ الذي يتناسب مع بنية تطبيقك - الأصلي أولاً للتطبيقات الجديدة، أو WebView النظام لتدفقات OAuth، أو WebView المدمج للأنماط المدمجة الحالية - يمكنك تقديم عمليات تسجيل دخول بدون كلمة مرور وبيومترية تحقق حقًا رؤية مفاتيح المرور: مصادقة بسيطة وآمنة وممتعة للجميع.

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

• يتم تقديم الملفات عبر HTTPS مع شهادة صالحة
• نوع MIME الصحيح: application/json
• لا توجد عمليات إعادة توجيه على مسار .well-known
• iOS: يتطابق معرف الفريق ومعرف الحزمة تمامًا في ملف AASA
• Android: تتطابق بصمة SHA256 مع شهادة التوقيع الخاصة بك في assetlinks.json
• يتطابق معرف الطرف المعتمد (Relying Party ID) مع نطاقك (بدون بروتوكول، بدون منفذ)
• لا توجد شرطات مائلة في نهاية معرف RP
• أصل WebAuthn: https://your-domain.com (وليس app://)

• iOS: تم تمكين قدرة النطاقات المرتبطة في Xcode مع webcredentials:yourdomain.com
• Android: تم الإعلان عن روابط الأصول الرقمية في AndroidManifest.xml
• قام المستخدم بتمكين قفل الشاشة (بيومتري أو PIN)
• اختبر باستخدام مدقق AASA من Apple وأداة روابط الأصول الرقمية من Google
• تحقق من أن ملف Runner.entitlements يحتوي على النطاقات المرتبطة الصحيحة

• iOS: استخدام ASWebAuthenticationSession (موصى به) أو SFSafariViewController
• Android: استخدام Chrome Custom Tabs (وليس WebView العادي)
• iOS: تحقق من تكوين النطاقات المرتبطة إذا لزم الأمر
• اختبر أن ملفات تعريف الارتباط/بيانات الاعتماد تتم مشاركتها مع متصفح النظام
• تحقق من أن صفحة مصادقة الويب لديها تنفيذ WebAuthn مناسب

• iOS: تم تكوينه بالصلاحيات المناسبة
• iOS: تشمل النطاقات المرتبطة جميع النطاقات ذات الصلة
• iOS: ملف AASA يمكن الوصول إليه ومنسق بشكل صحيح
• iOS: اختبر باستخدام ?mode=developer أثناء التطوير (قم بإزالته للإنتاج)
• Android: تم تضمين AndroidX WebKit 1.12.1+ (أو أحدث) في المشروع
• Android: فحص الميزة وقت التشغيل لـ WebViewFeature.WEB_AUTHENTICATION
• Android: تم استدعاء setWebAuthenticationSupport() مع WEB_AUTHENTICATION_SUPPORT_FOR_APP
• Android: تم تمكين JavaScript في إعدادات WebView
• Android: يدعم إصدار APK الخاص بـ WebView للمستخدم ميزة WebAuthn (استخدم اكتشاف الميزات، وليس إصدار نظام التشغيل)
• لم يتم استخدام الواجهة الشرطية (Conditional UI) (غير مدعومة في WebView المدمج)
• العودة إلى Chrome Custom Tabs إذا كانت ميزة WebAuthn غير متاحة

• تحقق مما إذا كان لدى المستخدم موفر بيانات اعتماد غير افتراضي نشط (1Password، Bitwarden، إلخ)
• تحقق من أن الموفر يدعم مفاتيح المرور (ليس كل مديري كلمات المرور يفعلون ذلك)
• اختبر باستخدام مدير بيانات الاعتماد الأصلي للمنصة (iCloud Keychain، Google Password Manager)

"NotAllowedError: The request is not allowed by the user agent or the platform in the current context"

• يعني عادة: صلاحيات مفقودة (iOS) أو ميزة WebView غير متاحة/ممكنة (Android Embedded WebView)
• تحقق من: تكوين النطاقات المرتبطة، إمكانية الوصول إلى ملف AASA، إصدار WebKit، اكتشاف الميزات، استدعاء setWebAuthenticationSupport()

لا يظهر موجه مفتاح المرور

• قد يعني: عدم تحميل AASA/assetlinks.json، نوع WebView خاطئ، ملف AASA مخزن مؤقتًا
• جرب: التحقق من ملفات الربط، استخدم ?mode=developer على iOS للاختبار، تحقق من نوع WebView

Corbado Native SDKs:

• iOS SDK (Swift)
• Android SDK (Kotlin)
• Flutter Package

وثائق المنصة:

• Apple: Supporting Passkeys
• Google: Credential Manager

أدوات التحقق:

• Apple AASA Validator
• Google Digital Asset Links Generator