تسجيل الدخول باستخدام مفتاح مرور من خلال الملء التلقائي للنموذج

أنشِئ تجربة تسجيل دخول تستفيد من مفاتيح المرور في الوقت نفسه من أجل تلبية احتياجات مستخدمي كلمات المرور الحاليين.

Eiji Kitamura

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

لماذا نستخدم ميزة الملء التلقائي للنماذج لتسجيل الدخول باستخدام مفتاح مرور؟

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

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

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

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

واجهة مستخدم شرطية

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

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

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

طريقة العمل

للمصادقة باستخدام مفتاح مرور، يمكنك استخدام واجهة برمجة تطبيقات WebAuthn.

المكونات الأربعة في تدفق مصادقة مفتاح المرور هي: المستخدم:

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

1. عندما يصل المستخدم إلى الواجهة الأمامية، يطلب من الخلفية إجراء تحدٍ للمصادقة باستخدام مفتاح مرور، ثم يطلب من navigator.credentials.get() بدء المصادقة باستخدام مفتاح مرور. ويؤدي ذلك إلى إرجاع Promise.
2. عندما يضع المستخدم المؤشر في حقل تسجيل الدخول، يعرض المتصفّح مربّع حوار ميزة الملء التلقائي لكلمة المرور، بما في ذلك مفاتيح المرور. سيظهر مربّع حوار للمصادقة إذا اختار المستخدم مفتاح مرور.
3. بعد إثبات المستخدم لهويته باستخدام قفل شاشة الجهاز، يتم التعامل بشكل نهائي مع الوعد وإعادة بيانات اعتماد المفتاح العام إلى الواجهة الأمامية.
4. ترسل الواجهة الأمامية بيانات اعتماد المفتاح العام إلى الواجهة الخلفية. تعمل الخلفية على التحقق من التوقيع مقابل المفتاح العام للحساب المطابق في قاعدة البيانات. في حال نجح الأمر، يكون المستخدم مسجّلاً الدخول.

المصادقة باستخدام مفتاح مرور من خلال ميزة الملء التلقائي للنموذج

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

إضافة تعليقات توضيحية إلى حقل إدخال النموذج

أضِف سمة autocomplete إلى الحقل input لاسم المستخدم إذا لزم الأمر. أضِف username وwebauthn كرموز مميّزة للسماح لها باقتراح مفاتيح مرور.

<input type="text" name="username" autocomplete="username webauthn" ...>

رصد الميزات

قبل استدعاء طلب بيانات WebAuthn API المشروط، تأكَّد مما يلي:

• يتوافق المتصفّح مع WebAuthn مع PublicKeyCredential.

• يتوافق المتصفّح مع واجهة المستخدم الشرطية WebAuthn مع PublicKeyCredenital.isConditionalMediationAvailable().

// 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  
  }  
}  

جلب تحد من خادم الجهة المحظورة

جلب اختبار التحقق من خادم الجهة المحظورة المطلوب الاتصال بـ navigator.credentials.get():

• challenge: تحدٍّ من إنشاء الخادم في ArrayBuffer. هذا الإجراء مطلوب لمنع هجمات إعادة التشغيل. احرص على إنشاء تحدٍ جديد في كل محاولة تسجيل دخول وتجاهله بعد مدة معينة أو بعد إخفاق محاولة تسجيل الدخول في التحقق. اعتبره رمزًا مميزًا ضمن CSRF.
• allowCredentials: مصفوفة من بيانات الاعتماد المقبولة لهذه المصادقة مرِّر مصفوفة فارغة للسماح للمستخدم باختيار مفتاح مرور متاح من القائمة التي يعرضها المتصفّح.

• userVerification: تشير إلى ما إذا كانت عملية إثبات هوية المستخدم باستخدام قفل شاشة الجهاز هي "required" أو "preferred" أو "discouraged". والقيمة التلقائية هي "preferred"، مما يعني أنّ برنامج المصادقة قد يتخطّى عملية التحقق من المستخدم. اضبط السمة على "preferred" أو احذف السمة.

طلب WebAuthn API باستخدام علامة conditional لمصادقة المستخدم

يمكنك الاتصال بالرقم navigator.credentials.get() لبدء انتظار مصادقة المستخدم.

// To abort a WebAuthn call, instantiate an `AbortController`.
const abortController = new AbortController();

const publicKeyCredentialRequestOptions = {
  // Server generated challenge
  challenge: ****,
  // The same RP ID as used during registration
  rpId: 'example.com',
};

const credential = await navigator.credentials.get({
  publicKey: publicKeyCredentialRequestOptions,
  signal: abortController.signal,
  // Specify 'conditional' to activate conditional UI
  mediation: 'conditional'
});

• rpId: رقم تعريف الجهة المحظورة هو نطاق ويمكن للموقع الإلكتروني تحديد نطاقه أو لاحقة يمكن تسجيلها. يجب أن تتطابق هذه القيمة مع معرّف rp.id المستخدَم عند إنشاء مفتاح المرور.

لا تنسَ تحديد mediation: 'conditional' لجعل الطلب مشروطًا.

إرسال بيانات اعتماد المفتاح العام الذي تم إرجاعه إلى خادم الجهة المحظورة

بعد أن يختار المستخدم حسابًا ويوافق على استخدام قفل شاشة الجهاز، يتم حلّ الوعد بإرجاع كائن PublicKeyCredential إلى الواجهة الأمامية للجهة المحظورة.

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

• NotAllowedError: ألغى المستخدم العملية.
• استثناءات أخرى: حدث خطأ غير متوقع. يعرض المتصفح مربع حوار خطأ للمستخدم.

يحتوي كائن بيانات اعتماد المفتاح العام على السمات التالية:

• id: رقم التعريف المشفر base64url لبيانات اعتماد مفتاح المرور الذي تمت مصادقته.
• rawId: إصدار ArrayBuffer من رقم تعريف بيانات الاعتماد.
• response.clientDataJSON: مصفوفة مصفوفة لبيانات العميل. يحتوي هذا الحقل على معلومات مثل التحدي والمصدر الذي سيحتاج خادم الجهة المحظورة إلى التحقق منه.
• response.authenticatorData: مصفوفة ArrayBuffer لبيانات أداة المصادقة. يتضمّن هذا الحقل معلومات مثل "رقم تعريف الجهة المحظورة"
• response.signature: مصفوفة المصفوفة للتوقيع هذه القيمة هي جوهر بيانات الاعتماد ويجب إثبات ملكيتها على الخادم.
• response.userHandle: مصفوفة ArrayBuffer التي تحتوي على رقم تعريف المستخدم الذي تم ضبطه في وقت الإنشاء. يمكن استخدام هذه القيمة، بدلاً من معرف بيانات الاعتماد، إذا كان الخادم يحتاج إلى اختيار قيم المعرفات التي يستخدمها، أو إذا أرادت الخلفية تجنب إنشاء فهرس بمعرفات بيانات الاعتماد.
• authenticatorAttachment: يعرض platform عندما تأتي بيانات الاعتماد هذه من جهاز محلي. بخلاف ذلك cross-platform، لا سيما عندما استخدم المستخدم هاتفًا لتسجيل الدخول. إذا احتاج المستخدم إلى استخدام هاتف لتسجيل الدخول، يمكنك أن تطلب منه إنشاء مفتاح مرور على الجهاز المحلي.
• type: يتم ضبط هذا الحقل دائمًا على "public-key".

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

التحقّق من التوقيع

عندما تتلقى بيانات اعتماد المفتاح العام على الخادم، يمكنك تمريرها إلى مكتبة FIDO لمعالجة الكائن.

ابحث عن رقم تعريف بيانات الاعتماد المطابق باستخدام السمة id (إذا أردت تحديد حساب المستخدم، استخدِم السمة userHandle، وهي السمة user.id التي حدّدتها عند إنشاء بيانات الاعتماد). تحقَّق مما إذا كان يمكن التحقق من signature لبيانات الاعتماد باستخدام المفتاح العام المخزَّن. للقيام بذلك، نوصي باستخدام مكتبة من جانب الخادم أو حل بدلاً من كتابة التعليمات البرمجية الخاصة بك. يمكنك العثور على مكتبات مفتوحة المصدر في مستودع webauth GitHub الرائع.

بعد إثبات صحة بيانات الاعتماد باستخدام مفتاح عام مطابق، سجِّل دخول المستخدم.

يمكنك اتّباع تعليمات أكثر تفصيلاً في مصادقة مفتاح المرور من جهة الخادم

المراجع

• مصادقة مفتاح المرور من جهة الخادم
• إنشاء مفتاح مرور لتسجيل الدخول بدون استخدام كلمات مرور
• مفاتيح المرور
• مستند Apple: مصادقة مستخدم من خلال خدمة ويب
• مستند Google: تسجيل الدخول بدون كلمة مرور باستخدام مفاتيح المرور