شرح تقني لواجهة المستخدم الشرطية WebAuthn (الملء التلقائي لمفاتيح المرور)

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

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

مع الاعتماد السريع على مفاتيح المرور (وبروتوكول WebAuthn الأساسي) أصبحت المصادقة أكثر أمانًا وسهولة في الاستخدام للعديد من المستخدمين. من أبرز التطورات في مفاتيح المرور دمج واجهة المستخدم الشرطية (Conditional UI)، والتي يشار إليها غالبًا باسم "الملء التلقائي لمفاتيح المرور" (passkey autofill) أو التوسط الشرطي (Conditional Mediation) (فيما يلي سنبقى مع مصطلح واجهة المستخدم الشرطية).

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

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

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

يُبنى أساس واجهة المستخدم الشرطية على ثلاث ركائز رئيسية:

1. احترام خصوصية المستخدم: ضمان خصوصية المستخدم من خلال منع الكشف عن بيانات الاعتماد المتاحة أو عدم موافقة المستخدم على الكشف عن هذه البيانات.
2. تجربة مستخدم رائعة حتى في حالة عدم وجود مفتاح مرور: تمكين الأطراف المعتمدة من تنفيذ WebAuthn بشكل انتهازي، مما يضمن بقاء تجربة المستخدم جيدة حتى في حالة عدم توفر مفاتيح المرور.
3. انتقال سلس من كلمات المرور إلى مفاتيح المرور: الجمع بين مفاتيح المرور والمصادقة المعتمدة على كلمات المرور لتسهيل الانتقال نحو طرق المصادقة بدون كلمات مرور، والاستفادة من نماذج تجربة المستخدم (UX) المألوفة للمستخدمين.

• مصادقة مبسطة: العملية مبسطة وأكثر كفاءة، مما يزيل التعقيدات المرتبطة غالبًا بطرق المصادقة المتعددة.
• تقليل أخطاء المستخدم: من خلال تقديم الخيارات ذات الصلة فقط، يصبح المستخدمون أقل عرضة لارتكاب أخطاء أثناء عملية المصادقة.
• تعزيز رضا المستخدم: إزالة الخطوات غير الضرورية تعني أن المستخدمين يمكنهم تسجيل الدخول بشكل أسرع وبجهد أقل، مما يؤدي إلى تحسين رضاهم.
• تكامل سهل للواجهة الأمامية: واحدة من أبرز ميزات واجهة المستخدم الشرطية هي سهولة دمجها. يمكن للمطورين دمجها بسلاسة في الواجهة الأمامية ببضعة أسطر من التعليمات البرمجية (انظر أدناه).
• تسجيل دخول بدون كلمة مرور وبدون اسم مستخدم: من الفوائد الكبيرة أن واجهة المستخدم الشرطية تعزز المصادقة بدون كلمات مرور فحسب، بل وتوفر أيضًا تجربة بدون أسماء مستخدمين أو حسابات. يُعفى المستخدمون من العبء الذهني لتذكر عنوان البريد الإلكتروني المحدد أو معرّف المستخدم من وقت التسجيل. بدلاً من ذلك، يمكنهم الاعتماد على اقتراحات المتصفح، والتي تتضمن عنوان البريد الإلكتروني/معرّف المستخدم المقترن بمفتاح المرور المناسب في قائمة الملء التلقائي.
• حل معضلة البدء (Bootstrapping Dilemma): الانتقال من أنظمة أسماء المستخدمين وكلمات المرور التقليدية إلى مفاتيح المرور يمكن أن يكون شاقًا. تعالج واجهة المستخدم الشرطية تحدي الانتقال هذا. يمكن لمواقع الويب بدء استدعاء مفتاح المرور / WebAuthn جنبًا إلى جنب مع مطالبة كلمة المرور التقليدية دون القلق بشأن أخطاء مربعات الحوار المشروطة المحتملة إذا كان الجهاز يفتقر إلى بيانات الاعتماد المطلوبة.

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

اشترك

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

فيما يلي، نقدم تفصيلاً خطوة بخطوة للخطوات الفردية لتدفق واجهة المستخدم الشرطية بالكامل:

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

1. التحقق من توفر واجهة المستخدم الشرطية: يستدعي العميل (المتصفح) وظيفة isConditionalMediationAvailable() لاكتشاف ما إذا كان مزيج المتصفح / الجهاز الحالي يدعم واجهة المستخدم الشرطية. تستمر العملية فقط إذا كانت الاستجابة صحيحة (true)، وإلا يتم إحباط عملية واجهة المستخدم الشرطية.
2. استدعاء نقطة نهاية واجهة المستخدم الشرطية: بعد ذلك، يستدعي العميل نقطة نهاية واجهة المستخدم الشرطية للخوادم لاسترداد PublicKeyCredentialRequestOptions.
3. تلقي PublicKeyCredentialRequestOptions: يُرجع الخادم PublicKeyCredentialRequestOptions والتي تحتوي على التحدي (challenge) ومزيد من خيارات خادم WebAuthn (مثل allowCredentials, extensions, userVerification).
4. بدء المصادقة المحلية: باستدعاء credentials.get() مع PublicKeyCredentialRequestOptions المُتلقاة وخاصية mediation مضبوطة لتكون conditional، تبدأ عملية المصادقة المحلية على الجهاز.
5. إظهار تحديد الملء التلقائي: تنبثق قائمة الملء التلقائي لمفاتيح المرور. يعتمد النمط المحدد على المتصفح والجهاز (على سبيل المثال، يطلب البعض من المستخدم وضع المؤشر في حقل الإدخال، ويعرض البعض الآخر القائمة تلقائيًا عند تحميل الصفحة، انظر أدناه).
6. مصادقة المستخدم المحلية: يختار المستخدم مفتاح المرور من قائمة الملء التلقائي الذي يريد استخدامه والمصادقة عبر مربع حوار المصادقة الخاص بجهازه (مثل Face ID, Touch ID, Windows Hello).
7. إرسال استجابة أداة المصادقة إلى الخادم: إذا نجحت مصادقة المستخدم المحلية، يتم إرسال استجابة أداة المصادقة مرة أخرى إلى الخادم.
8. تسجيل دخول المستخدم وتوجيهه: بمجرد أن يتلقى الخادم استجابة أداة المصادقة، فإنه يتحقق من التوقيع مقابل المفتاح العام لحسابات المستخدم المقابلة في قاعدة البيانات. في حالة نجاح التحقق، يُمنح المستخدم إمكانية الوصول، ويتم تسجيل دخوله وتوجيهه إلى صفحة تسجيل الدخول.

باتباع تدفق هذه العملية، تقدم واجهة المستخدم الشرطية تجربة مصادقة سلسة وسهلة الاستخدام.

لكي تعمل واجهة المستخدم الشرطية، يجب مراعاة بعض الجوانب العامة:

• مواصفات بيانات الاعتماد: صُممت واجهة المستخدم الشرطية للعمل خصيصًا وبشكل حصري مع المفاتيح المقيمة / بيانات الاعتماد القابلة للاكتشاف. السبب وراء ذلك هو أن أدوات المصادقة لا تخزن بيانات خاصة بالمستخدم (مثل الاسم، اسم العرض) للمفاتيح غير المقيمة / بيانات الاعتماد غير القابلة للاكتشاف. نتيجة لذلك، لا يمكن استخدام الأخيرة في الملء التلقائي لمفتاح المرور.
• تصفية بيانات الاعتماد: تظل ميزة allowCredentials مدعومة، مما يسهل على مواقع الويب التي تعرف بالفعل هوية المستخدم (على سبيل المثال، إذا تم إرسال اسم المستخدم في استدعاء التوسط الأولي لأنه قد يكون مخزنًا في التخزين المحلي للمتصفحات (LocalStorage)) تصفية قائمة بيانات الاعتماد المعروضة للمستخدمين أثناء الملء التلقائي.

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

انضم

لكي تعمل واجهة المستخدم الشرطية من جانب العميل، يجب استيفاء المتطلبات التالية:

• متصفح متوافق: تأكد من أن المستخدم يستخدم متصفحًا حديثًا يدعم واجهة المستخدم الشرطية (انظر هنا لأحدث تغطية المتصفحات).
• تمكين JavaScript: يجب تمكين JavaScript لتسهيل عمليات واجهة المستخدم الشرطية.
• اختبار توفر واجهة المستخدم الشرطية: يجب أن يكون لدى الطرف المعتمد (جانب الخادم) اليقين بأن واجهة المستخدم الشرطية متاحة على جانب العميل، عندما يتلقى استدعاء توسط WebAuthn لتجنب التسبب في أي أخطاء مرئية للمستخدم في السيناريوهات التي لا تكون فيها واجهة المستخدم الشرطية مدعومة. لمعالجة هذا الأمر، يُنصح باستخدام طريقة isConditionalMediationAvailable() والتحقق من التوفر الفني لواجهة المستخدم الشرطية (انظر أدناه لمزيد من التفاصيل).
• حقل إدخال HTML مطلوب: لكي تعمل واجهة المستخدم الشرطية، يجب أن يكون لديك حقل إدخال HTML في صفحة الويب الخاصة بك. إذا لم يكن لديك واحد، فيجب عليك توفير الدعم لعملية تسجيل الدخول المنتظمة لمفتاح المرور / WebAuthn التي يتم تشغيلها بتفاعل المستخدم، مثل النقر فوق الزر.
• إزالة بروتوكولات المهلة (Timeout): يجب تجاهل معلمات المهلة (على سبيل المثال، المستخدم يستغرق وقتًا طويلاً لاتخاذ قرار بشأن مفتاح مرور في قائمة الملء التلقائي) في هذا الإعداد.

لكي تعمل واجهة المستخدم الشرطية، يجب استيفاء بعض المتطلبات من جانب الخادم أيضًا:

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

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

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

جرّب مجاناً

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

<!DOCTYPE html>
<html lang="en">
    <head>
        <meta charset="UTF-8" />
        <meta name="viewport" content="width=device-width, initial-scale=1.0" />
        <title>Conditional UI</title>
    </head>
    <body>
        <input type="text" id="username" autocomplete="username webauthn" />
 
        <script>
            async function passkeyLogin() {
                try {
                    // retrieve the request options (incl. the challenge) from the WebAuthn server
                    let options = await WebAuthnClient.getPublicKeyRequestOptions();
 
                    const credential = await navigator.credentials.get({
                        publicKey: options.publicKeyCredentialRequestOptions,
                        mediation: "conditional",
                    });
 
                    const userData = await WebAuthnClient.sendSignedChallenge(credential);
                    window.location.href = "/logged-in";
                } catch (error) {
                    console.log(error);
                }
            }
 
            passkeyLogin();
        </script>
    </body>
</html>

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

// source: https://developer.mozilla.org/en-US/docs/Web/API/PublicKeyCredential/isConditionalMediationAvailable#examples
 
// Availability of `window.PublicKeyCredential` means WebAuthn is usable.
if (window.PublicKeyCredential && PublicKeyCredential.isConditionalMediationAvailable) {
    // Check if conditional mediation is available.
    const isCMA = await PublicKeyCredential.isConditionalMediationAvailable();
    if (isCMA) {
        // Call WebAuthn authentication start endpoint
 
        let options = await WebAuthnClient.getPublicKeyRequestOptions();
 
        const credential = await navigator.credentials.get({
            publicKey: options.publicKeyCredentialRequestOptions,
            mediation: "conditional",
        });
        /*
        ...
        */
    }
}

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

• autocomplete="username webauthn": إلى جانب عرض مفاتيح المرور، يقترح هذا أيضًا ملء اسم المستخدم تلقائيًا.
• autocomplete="current-password webauthn": إلى جانب عرض مفاتيح المرور، يدفع هذا أيضًا إلى ملء كلمة المرور تلقائيًا.

<label for="name">Username:</label>
<input type="text" name="name" autocomplete="username webauthn" />
<label for="password">Password:</label>
<input type="password" name="password" autocomplete="current-password webauthn" />

لمزيد من التفاصيل، نوصي بقراءة هذه التدوينة التي تقدم المزيد من التفاصيل حول رموز الملء التلقائي / الإكمال التلقائي لمفاتيح المرور وكلمات المرور.

لاسترداد مفاتيح المرور المتاحة بعد تلقي كائن PublicKeyCredentialRequestOptions، يجب استدعاء وظيفة navigator.credentials.get() (التي تخدم كلاً من مفاتيح المرور وكلمات المرور). يجب أن يحتوي كائن PublicKeyCredentialRequestOptions على معامل mediation المضبوط على conditional لتنشيط واجهة المستخدم الشرطية على العميل. للحالات التي ترغب فيها في الحصول على مطالبة مشروطة لمفتاح المرور بدلاً من ذلك، راجع التوسط الفوري.

const credential = await navigator.credentials.get({
    publicKey: options.publicKeyCredentialRequestOptions,
    mediation: "conditional",
});

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

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

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

يتم تنشيط عملية تسجيل الدخول بواجهة المستخدم الشرطية بمجرد وصول المستخدم إلى الصفحة. يجب أن تكون المهمة الأولية هي إنشاء كائن AbortController بنطاق عام. سيعمل هذا كإشارة لعميلك لإنهاء طلب الملء التلقائي، لا سيما إذا قرر المستخدم القيام بعملية تسجيل الدخول المنتظمة لمفتاح المرور. طمئن أنّه يمكن استدعاء AbortController بواسطة وظائف أخرى ويتم إعادة تعيينه إذا لزم إعادة تشغيل عملية واجهة المستخدم الشرطية. استخدم خاصية الإشارة (signal) ضمن استدعاء navigator.credentials.get()، مع دمج إشارة AbortController كقيمة لها. يرسل هذا إشارة إلى وظيفة مفتاح المرور / WebAuthn بوجوب إيقاف الطلب إذا تم إجهاض الإشارة. تذكر إعداد AbortController جديد في كل مرة تقوم فيها بتشغيل واجهة المستخدم الشرطية. سيؤدي استخدام AbortController تم إحباطه بالفعل إلى إلغاء فوري لوظيفة مفتاح المرور / WebAuthn. تتوافق الخطوات المتبقية مع عملية تسجيل الدخول العادية لمفتاح المرور. فيما يلي، ترى مثالاً برمجيًا للخطوات المذكورة:

<!DOCTYPE html>
<html lang="en">
    <head>
        <meta charset="UTF-8" />
        <meta name="viewport" content="width=device-width, initial-scale=1.0" />
        <title>Conditional UI</title>
    </head>
    <body>
        <input type="text" id="username" autocomplete="username webauthn" />
 
        <script>
            async function passkeyLogin() {
                try {
                    // retrieve the request options (incl. the challenge) from the WebAuthn server
                    let options = await WebAuthnClient.getPublicKeyRequestOptions();
 
                    const credential = await navigator.credentials.get({
                        publicKey: options.publicKeyCredentialRequestOptions,
                        mediation: "conditional",
                    });
 
                    const userData = await WebAuthnClient.sendSignedChallenge(credential);
                    window.location.href = "/logged-in";
                } catch (error) {
                    console.log(error);
                }
            }
 
            passkeyLogin();
        </script>
    </body>
</html>

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

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

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

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

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

النوع أ: تراكب / نافذة منبثقة تغطي الشاشة بالكامل تقريبًا

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

النوع ب: الملء التلقائي في لوحة المفاتيح

يعرض النوع الثاني (ب) مفتاح مرور مناسبًا في قسم الملء التلقائي في لوحة المفاتيح (حيث يتم أيضًا اقتراح كلمات المرور للملء التلقائي). سيؤدي النقر فوق القيمة المقترحة إلى إجراء مصادقة Face ID ويسمح لك بتسجيل الدخول. في إصدار تطبيق iOS الحالي من لوحة مطوري Corbado، قمنا بتنفيذه بهذه الطريقة (انظر رسالة تسجيل الدخول باستخدام مفتاح المرور لـ <معرّف الطرف المعتمد> مع اسم مستخدم WebAuthn). للظهور، يحتاج المستخدم إلى النقر في حقل الإدخال:

قد تواجه ميزة الملء التلقائي لمفتاح المرور هذه في قسم لوحة المفاتيح مشكلات عندما يتم تثبيت نظام iOS حديثًا حيث يبدو أن هناك نوعًا من التخزين المؤقت يحدث في الخلفية والذي يبحث عن جميع مفاتيح المرور المتاحة لهذا الطرف المعتمد.

يؤدي النقر فوق رمز المفتاح على يمين مفتاح المرور المقترح إلى الموقع المعروف لاختيار كلمات المرور / مفاتيح المرور في iOS:

يرجى ملاحظة أننا لم نعثر على وثائق رسمية، وتستند رؤيتنا إلى تجاربنا وفرضياتنا بدلاً من إثبات ملموس للتنفيذ الصحيح.

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

يؤدي فتح الصفحة التي يتم فيها تنفيذ واجهة المستخدم الشرطية إلى عرض الشاشة التالية، حيث ستجد طرقًا مختلفة لتسجيل الدخول:

يؤدي النقر فوق المزيد من عمليات تسجيل الدخول المحفوظة إلى توفير المزيد من الخيارات لاختيار تسجيل الدخول (بما في ذلك المصادقة عبر الأجهزة واختيار نظام أساسي مختلف لمزامنة مفاتيح المرور، مثل Samsung Pass أو 1Password):

لتوضيح كيف تبدو واجهة المستخدم الشرطية للمستخدم النهائي، أضفنا عدة لقطات شاشة لقائمة الملء التلقائي لواجهة المستخدم الشرطية باستخدام https://passkeys.eu.

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

جرّب passkeys

دعونا نلقي نظرة على بعض السيناريوهات الشائعة في تطبيقات الحياة الواقعية.

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

على Chrome على macOS، يؤدي النقر في حقل الإدخال إلى إظهار قائمة منسدلة فارغة للملء التلقائي:

على Safari على macOS، لا تظهر أي قائمة منسدلة - مجرد رمز دقيق في حقل الإدخال:

على Android أو iOS، تظهر واجهة الملء التلقائي فقط إذا نقر المستخدم في الحقل وعثر نظام التشغيل على بيانات اعتماد مطابقة.

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

إذا كان لدى المستخدم عدة موفرين لمفاتيح المرور مثبتة (مثل iCloud Keychain، Google Password Manager، 1Password)، فإن المتصفح أو نظام التشغيل يعود عادةً إلى مدير بيانات الاعتماد الأساسي للمستخدم.

للحصول على قائمة بموفري مفاتيح المرور / مديري بيانات الاعتماد المختلفين الذين يدعمون مفاتيح المرور، نوصي بإلقاء نظرة على رابط GitHub التالي.

في Android، يعرض Credential Manager موفرين مختلفين مثل Samsung Pass أو 1Password.

1. عند النقر فوق حقل إدخال معرّف المستخدم، تظهر هذه القائمة حيث يمكن للمستخدم تحديد مفتاح مرور.

2. إذا نقر المستخدم على "المزيد من مفاتيح المرور" في الشاشة السابقة، يظهر تحديد مسبق لموفري مفاتيح مرور / مديري بيانات اعتماد آخرين ومفاتيح مرور:

3. إذا نقر المستخدم على "المزيد من عمليات تسجيل الدخول المحفوظة" في الشاشة السابقة، تظهر قائمة كاملة بالمفاتيح المتاحة حيث يمكن للمستخدم تحديد مفتاح مرور منها.

على iOS، يفتح رمز المفتاح القائمة الكاملة لمفاتيح المرور من مصادر مختلفة.

1. في البداية، على iOS 18+، تأتي واجهة المستخدم الشرطية العادية مع موفر مفاتيح المرور الافتراضي.

2. عند النقر فوق رمز لوحة المفاتيح، تظهر قائمة التحديد التالية.

3. بعد اختيار مدير بيانات الاعتماد / موفر مفتاح المرور، يمكن للمستخدم تحديد مفتاح المرور المراد استخدامه.

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

حول Corbado

Corbado هي Authentication 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 →

استدعِ PublicKeyCredential.isConditionalMediationAvailable() وتابع فقط إذا أرجعت القيمة true. يمنع هذا التحقق الأخطاء المرئية للمستخدم على مجموعات المتصفح والأجهزة غير المدعومة. يجب تقييم هذه الطريقة عند كل تحميل للصفحة قبل استدعاء navigator.credentials.get() مع mediation: "conditional".

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

يختلف السلوك حسب النظام الأساسي. يعرض Chrome على macOS قائمة منسدلة فارغة للملء التلقائي، ويعرض Safari على macOS رمزًا دقيقًا فقط في حقل الإدخال، أما في Android أو iOS تظهر واجهة الملء التلقائي فقط إذا وجد نظام التشغيل بيانات اعتماد مطابقة بعد نقر المستخدم على الحقل. هذا الاختلاف مقصود وجزء من نموذج الخصوصية الخاص بـ WebAuthn: لا يمكن لمواقع الويب اكتشاف ما إذا كان مفتاح المرور موجودًا إلا إذا اختار المستخدم واحدًا بشكل نشط.

قم بإنشاء AbortController بنطاق عام وتمرير الإشارة الخاصة به إلى navigator.credentials.get(). استدعِ .abort() على وحدة التحكم عندما يبدأ المستخدم تدفق تسجيل الدخول المشروط. قم دائمًا بإنشاء AbortController جديد في كل مرة تتم فيها إعادة تشغيل واجهة المستخدم الشرطية، لأن إعادة استخدام وحدة تحكم تم إلغاؤها بالفعل يؤدي إلى الإلغاء الفوري لطلب WebAuthn.

تعمل واجهة المستخدم الشرطية في كل من تطبيقات iOS و Android الأصلية. يدعم iOS متغيرين: نافذة منبثقة تتراكب على ملء الشاشة واقتراح ملء تلقائي للوحة المفاتيح. يستخدم Android واجهة برمجة تطبيقات Credential Manager، والتي يمكنها عرض مفاتيح المرور من موفرين متعددين مثل Samsung Pass أو 1Password.