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

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

Eiji Kitamura

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

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

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

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

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

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

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

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

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

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

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

طريقة عمل المصادقة باستخدام مفتاح المرور

للمصادقة باستخدام مفتاح مرور، عليك استخدام WebAuthn API.

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

• الخادم الخلفي: يخزّن تفاصيل حساب المستخدم، بما في ذلك المفتاح العام.
• الواجهة الأمامية: تتواصل مع المتصفّح وتجلب البيانات اللازمة من الواجهة الخلفية.
• المتصفّح: يشغّل JavaScript ويتفاعل مع WebAuthn API.
• مقدّم مفتاح المرور: ينشئ مفتاح المرور ويخزّنه. يكون ذلك عادةً مدير كلمات مرور، مثل "مدير كلمات المرور في Google"، أو مفتاح أمان.

تتّبع عملية المصادقة باستخدام مفاتيح المرور الخطوات التالية:

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

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

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

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

لتفعيل ميزة "الملء التلقائي" لمفاتيح المرور، أضِف السمة autocomplete إلى حقل اسم المستخدم input في النموذج. أدرِج username وwebauthn كقيم مفصولة بمسافات.

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

تؤدي إضافة autofocus إلى هذا الحقل إلى تشغيل طلب الملء التلقائي عند تحميل الصفحة، ما يؤدي إلى عرض كلمات المرور ومفاتيح المرور المتاحة على الفور.

رصد الميزات

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

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

• يتوافق المتصفّح مع ميزة رصد الإمكانات باستخدام PublicKeyCredential.getClientCapabilities().

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

يوضّح المقتطف التالي كيف يمكنك التحقّق مما إذا كان المتصفّح يتيح استخدام هذه الميزات:

if (window.PublicKeyCredential && PublicKeyCredential.getClientCapabilities) {
  const capabilities = await PublicKeyCredential.getClientCapabilities();
  // Check if conditional mediation is available.  
  if (capabilities.conditionalGet === true) {
    // The browser supports conditional mediation.
  }
}

استرجاع المعلومات من الخلفية

يجب أن يوفّر الخلفية عدة خيارات للواجهة الأمامية لبدء طلب navigator.credentials.get(). يتم عادةً جلب هذه الخيارات كعنصر JSON من نقطة نهاية على خادمك.

تشمل الخصائص الرئيسية في عنصر الخيارات ما يلي:

• challenge: تمثّل هذه السمة تحديًا من إنشاء الخادم في ArrayBuffer (يتم عادةً ترميزها باستخدام Base64URL لنقلها بتنسيق JSON). هذا الإجراء ضروري لمنع هجمات إعادة الإرسال. يجب أن ينشئ الخادم عملية تحقّق جديدة لكل محاولة تسجيل دخول، وأن يبطلها بعد فترة قصيرة أو في حال تعذّر تسجيل الدخول.
• allowCredentials: صفيف من أوصاف بيانات الاعتماد. مرِّر مصفوفة فارغة. سيؤدي ذلك إلى مطالبة المتصفّح بإدراج جميع بيانات الاعتماد الخاصة بـ rpId المحدّد.

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

  • ‫"required": يجب أن يتم التحقّق من هوية المستخدم من خلال أداة المصادقة (مثل رقم التعريف الشخصي أو المقاييس الحيوية). وتتعذّر العملية إذا لم يكن من الممكن إجراء عملية التحقّق.
  • ‫"preferred": يحاول المصادق التحقّق من المستخدم، ولكن يمكن أن تنجح العملية بدون ذلك.
  • ‫"discouraged": يجب أن يتجنّب أداة المصادقة التحقّق من هوية المستخدم إذا كان ذلك ممكنًا.

• rpId: هو رقم تعريف الجهة المعتمِدة، ويكون عادةً نطاق موقعك الإلكتروني (مثل example.com). يجب أن تتطابق هذه القيمة تمامًا مع rp.id المستخدَم عند إنشاء بيانات اعتماد مفتاح المرور.

يجب أن ينشئ الخادم كائن الخيارات هذا. يجب ترميز قيم ArrayBuffer (مثل challenge) باستخدام Base64URL لنقلها بتنسيق JSON. في الواجهة الأمامية، بعد تحليل JSON، استخدِم PublicKeyCredential.parseRequestOptionsFromJSON() لتحويل العنصر (بما في ذلك فك ترميز سلاسل Base64URL) إلى التنسيق الذي تتوقّعه navigator.credentials.get().

يوضّح مقتطف الرمز التالي كيفية استرداد المعلومات اللازمة للمصادقة باستخدام مفتاح مرور وفك تشفيرها.

// Fetch an encoded PubicKeyCredentialRequestOptions from the server.
const _options = await fetch('/webauthn/signinRequest');

// Deserialize and decode the PublicKeyCredentialRequestOptions.
const decoded_options = JSON.parse(_options);
const options = PublicKeyCredential.parseRequestOptionsFromJSON(decoded_options);
...

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

بعد إعداد العنصر publicKeyCredentialRequestOptions (المشار إليه باسم options في نموذج الرمز البرمجي أدناه)، استدعِ الدالة navigator.credentials.get() لبدء عملية المصادقة باستخدام مفتاح المرور الشرطي.

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

// Invoke WebAuthn to authenticate with a passkey.
const credential = await navigator.credentials.get({
  publicKey: options,
  signal: abortController.signal,
  // Specify 'conditional' to activate conditional UI
  mediation: 'conditional'
});

المَعلمات الرئيسية لهذا الطلب:

• publicKey: يجب أن يكون هذا العنصر publicKeyCredentialRequestOptions (المسمّى options في المثال) الذي تم استرجاعه من الخادم ومعالجته في الخطوة السابقة.
• signal: يتيح لك تمرير إشارة AbortController (مثل abortController.signal) إلغاء طلب get() آليًا. يكون هذا الإجراء مفيدًا عندما تريد استدعاء مكالمة WebAuthn أخرى.
• ‫mediation: 'conditional': هذه هي العلامة الأساسية التي تجعل طلب WebAuthn مشروطًا. يطلب هذا السمة من المتصفّح انتظار تفاعل المستخدم مع طلب الملء التلقائي بدلاً من عرض مربّع حوار مشروط على الفور.

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

AIf the user selects a passkey and successfully verifies their identity (for instance, using their device screen lock), the navigator.credentials.get() promise resolves. سيؤدي ذلك إلى عرض عنصر PublicKeyCredential في الواجهة الأمامية.

يمكن رفض الوعد لعدة أسباب. يجب معالجة هذه الأخطاء في الرمز البرمجي من خلال التحقّق من السمة name الخاصة بالكائن Error:

• ‫NotAllowedError: ألغى المستخدم العملية أو لم يتم اختيار مفتاح مرور.
• ‫AbortError: تم إيقاف العملية، ربما بسبب استخدام الرمز AbortController.
• استثناءات أخرى: حدث خطأ غير متوقّع. يعرض المتصفّح عادةً مربّع حوار خطأ للمستخدم.

يحتوي العنصر PublicKeyCredential على عدّة سمات. تشمل الخصائص الرئيسية ذات الصلة بالمصادقة ما يلي:

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

لإرسال عنصر PublicKeyCredential هذا إلى الخلفية، عليك أولاً استدعاء طريقة .toJSON(). تنشئ هذه الطريقة نسخة من بيانات الاعتماد يمكن تحويلها إلى تنسيق JSON، وتتعامل بشكل صحيح مع تحويل خصائص ArrayBuffer (مثل rawId وclientDataJSON وauthenticatorData وsignature وuserHandle) إلى سلاسل مشفّرة بتنسيق Base64URL. بعد ذلك، استخدِم JSON.stringify() لتحويل هذا العنصر إلى سلسلة وإرساله في نص طلبك إلى الخادم.

...
// Encode and serialize the PublicKeyCredential.
const _result = credential.toJSON();
const result = JSON.stringify(_result);

// Encode and send the credential to the server for verification.  
const response = await fetch('/webauthn/signinResponse', {
  method: 'post',
  credentials: 'same-origin',
  body: result
});

تأكيد التوقيع

عندما يتلقّى خادم الخلفية بيانات اعتماد المفتاح العام، يجب أن يتأكّد من صحتها. يشمل ذلك ما يلي:

1. تحليل بيانات الاعتماد
2. البحث عن المفتاح العام المخزَّن المرتبط بـ id لبيانات الاعتماد
3. التحقّق من signature المستلَم باستخدام المفتاح العام المخزَّن
4. التحقّق من صحة البيانات الأخرى، مثل التحدي والمصدر

ننصح باستخدام مكتبة FIDO/WebAuthn من جهة الخادم للتعامل مع عمليات التشفير هذه بأمان. يمكنك العثور على مكتبات مفتوحة المصدر في مستودع awesome-webauthn على GitHub.

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

إشارة في حال عدم العثور على بيانات الاعتماد المطابقة في الخلفية

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

يمكنك استخدام طريقة PublicKeyCredential.signalUnknownCredential()، وهي جزء من Webauthn Signal API، لإبلاغ مقدّم خدمة مفاتيح المرور بأنّه تمت إزالة بيانات الاعتماد المحدّدة أو أنّها غير متوفّرة. يمكنك استدعاء هذه الطريقة الثابتة من جهة العميل إذا كان الخادم يشير (على سبيل المثال، باستخدام رمز حالة HTTP معيّن مثل 404) إلى أنّ معرّف بيانات الاعتماد المقدَّم غير معروف. قدِّم رقم تعريف الجهة المحظورة ورقم تعريف بيانات الاعتماد غير المعروفة إلى هذه الطريقة. على موفّر مفتاح المرور إزالة مفتاح المرور إذا كان يتيح ذلك.

// Detect authentication failure due to lack of the credential
if (response.status === 404) {
  // Feature detection
  if (PublicKeyCredential.signalUnknownCredential) {
    await PublicKeyCredential.signalUnknownCredential({
      rpId: "example.com",
      credentialId: "vI0qOggiE3OT01ZRWBYz5l4MEgU0c7PmAA" // base64url encoded credential ID
    });
  } else {
    // Encourage the user to delete the passkey from the password manager nevertheless.
    ...
  }
}

بعد المصادقة

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

إذا سجّل المستخدم الدخول بدون مفتاح مرور

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

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

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

إذا سجّل المستخدم الدخول باستخدام مفتاح مرور

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

تشجيع إنشاء مفتاح مرور جديد بعد المصادقة التي تعمل من خلال جهاز آخر

إذا سجّل المستخدم الدخول باستخدام مفتاح مرور من خلال آلية تعمل من خلال جهاز آخر (مثل مسح رمز الاستجابة السريعة باستخدام الهاتف)، قد لا يتم تخزين مفتاح المرور الذي استخدمه محليًا على الجهاز الذي يسجّل الدخول إليه. يمكن أن يحدث هذا في الحالات التالية:

• لديهم مفتاح مرور ولكن على مزوّد مفاتيح مرور لا يتوافق مع نظام التشغيل أو المتصفّح المستخدَمَين في تسجيل الدخول.
• فقدوا إمكانية الوصول إلى مقدّم خدمة مفاتيح المرور على الجهاز الذي يتم تسجيل الدخول عليه، ولكن لا يزال مفتاح المرور متاحًا على جهاز آخر.

في هذه الحالة، ننصحك بأن تطلب من المستخدم إنشاء مفتاح مرور جديد على الجهاز الحالي. يمكن أن يوفّر هذا الإجراء على المستخدمين تكرار عملية تسجيل الدخول على أجهزة متعددة في المستقبل. لتحديد ما إذا كان المستخدم قد سجّل الدخول باستخدام مفتاح مرور يعمل من خلال جهاز آخر، تحقَّق من السمة authenticatorAttachment الخاصة ببيانات الاعتماد. إذا كانت القيمة "cross-platform"، يشير ذلك إلى مصادقة تعمل من خلال جهاز آخر. إذا كان الأمر كذلك، اشرح مزايا إنشاء مفتاح مرور جديد وقدِّم له إرشادات حول عملية الإنشاء.

مزامنة تفاصيل مفتاح المرور مع مقدّم الخدمة باستخدام الإشارات

لضمان الاتساق وتقديم تجربة أفضل للمستخدم، يمكن لـ "الجهة المعتمِدة" استخدام WebAuthn Signals API لإرسال إشعارات بشأن بيانات الاعتماد ومعلومات المستخدم إلى مقدّم مفاتيح المرور.

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

وبالمثل، يمكنك إرسال إشارة إذا عدّل المستخدم اسم المستخدم أو الاسم المعروض في خدمتك، للمساعدة في إبقاء معلومات المستخدم المعروضة من قِبل مقدّم مفتاح المرور (على سبيل المثال، في مربّعات حوار اختيار الحساب) محدّثة.

لمزيد من المعلومات حول الممارسات الجيدة للحفاظ على اتساق مفاتيح المرور، يُرجى الاطّلاع على الحفاظ على اتساق مفاتيح المرور مع بيانات الاعتماد على خادمك باستخدام Signal API.

عدم طلب عامل مصادقة ثانٍ

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

قائمة التحقق

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

الموارد

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