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

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

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: تسجيل الدخول بدون كلمة مرور باستخدام مفاتيح المرور