المفتاح المقيم في WebAuthn: بيانات الاعتماد القابلة للاكتشاف كـ Passkeys

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

يعمل بروتوكول WebAuthn مع ثلاثة كيانات رئيسية:

• الطرف المعتمد (Relying Party أو RP): وهي خدمة الويب الخاصة بك التي ترغب في مصادقة المستخدم. تقوم بإرسال تحديات إلى العميل، وتتحقق من الاستجابات، وتدير المفتاح العام لمفتاح المرور.
• أدوات المصادقة (Authenticators): وهي الأجهزة التي يمكنها إثبات حيازة بيانات الاعتماد. تشمل الأمثلة الهواتف الذكية، وأجهزة الكمبيوتر المحمولة، أو مفاتيح الأمان (مثل YubiKeys). يمكن أن تكون أدوات المصادقة خاصة بمنصة معينة (مثل Windows Hello أو Touch ID / Face ID من Apple) أو متعددة المنصات (مثل مفاتيح الأمان، على سبيل المثال YubiKeys).
• العملاء (Clients): عادةً ما تكون هذه متصفحات الويب أو التطبيقات الأصلية التي تعمل كوسيط بين الطرف المعتمد وأداة المصادقة. فهي تسهل الاتصال، وتضمن تدفق البيانات بشكل صحيح وآمن.

Want to try passkeys yourself in a passkeys demo?

Try Passkeys

فيما يلي، نصف تدفق البيانات عالي المستوى أثناء عملية المصادقة (سواء تسجيل الدخول أو الاشتراك).

1. بدء العميل: تبدأ العملية من جانب العميل، عادةً عندما يحاول المستخدم تسجيل الدخول أو الاشتراك. على سبيل المثال، قد ينقر على زر "تسجيل الدخول باستخدام WebAuthn" ويرسل العميل طلبًا للحصول على تحدٍ إلى الطرف المعتمد.
2. طلب الطرف المعتمد: يرسل الطرف المعتمد بعد ذلك تحديًا إلى العميل. هذا التحدي هو قيمة يتم إنشاؤها عشوائيًا تضمن أصالة الاستجابة اللاحقة.
3. من العميل إلى أداة المصادقة: أثناء الاشتراك، يطلب العميل من أداة المصادقة إنشاء مفتاح مرور جديد عن طريق إنشاء زوج المفاتيح العام والخاص المقابل. أثناء تسجيل الدخول، يطلب العميل من أداة المصادقة توقيع التحدي. يتم ذلك باستخدام المفتاح الخاص الموجود على أداة المصادقة، والذي يتوافق مع مفتاح عام مسجل مسبقًا ومخزن لدى الطرف المعتمد.
4. استجابة أداة المصادقة: أثناء الاشتراك، ترسل أداة المصادقة المفتاح العام مرة أخرى إلى العميل. أثناء تسجيل الدخول، تقوم أداة المصادقة بتوقيع التحدي وإرسال هذا التأكيد الموقّع مرة أخرى إلى العميل.
5. من العميل إلى الطرف المعتمد: يقوم العميل بإعادة توجيه هذا المفتاح العام الجديد / التأكيد الموقّع إلى الطرف المعتمد.
6. تحقق الطرف المعتمد: يقوم الطرف المعتمد بتخزين المفتاح العام / التحقق من التأكيد الموقّع باستخدام المفتاح العام المخزن. إذا كان صالحًا، تنجح عملية المصادقة.

Ben Gould

Head of Engineering

I’ve built hundreds of integrations in my time, including quite a few with identity providers and I’ve never been so impressed with a developer experience as I have been with Corbado.

10,000+ devs trust Corbado & make the Internet safer with passkeys. Got questions? We’ve written 150+ blog posts on passkeys.

Join Passkeys Community

يصف تدفق العملية عالي المستوى المذكور أعلاه عمليات الاشتراك وتسجيل الدخول باستخدام WebAuthn. تم بناء مفاتيح المرور فوق WebAuthn. في الأصل، استُخدم مصطلح "Passkeys" كمصطلح أسهل في التذكر وغير تقني لوصف نفس الشيء بدلاً من WebAuthn. علاوة على ذلك، توفر مفاتيح المرور ميزات أكثر مقارنة بـ WebAuthn القياسي، مثل إمكانية مزامنة مفاتيح المرور عبر الحسابات السحابية أو مديري كلمات المرور.

لفهم الأقسام التالية بشكل أفضل، نعرّف بعض المصطلحات المهمة في بروتوكول WebAuthn للوصول إلى فهم مشترك.

• معرّف بيانات الاعتماد (Credential ID): إن معرّف بيانات الاعتماد هو معرّف فريد يتم تعيينه لبيانات اعتماد مفتاح عام محددة تم إنشاؤها بواسطة أداة المصادقة. يسمح للأطراف المعتمدة (RPs) بتحديد واختيار PublicKeyCredential الصحيح لعمليات المصادقة.
• PublicKeyCredential: هذه هي بنية البيانات الأساسية التي يتم إرجاعها من واجهة برمجة تطبيقات WebAuthn الخاصة بالمتصفح أو التطبيقات الأصلية. وهي تشمل كلاً من بيانات التصديق (Attestation) أثناء الاشتراك وبيانات التأكيد (Assertion) أثناء تسجيل الدخول. بشكل أساسي، تحتوي على البيانات التي يحتاجها الطرف المعتمد للتحقق من العملية.
• التصديق (Attestation): يعمل التصديق في سياق WebAuthn كدليل على مصدر أداة المصادقة وسلامتها. أثناء الاشتراك، هي طريقة تقول بها أداة المصادقة: "لقد سجلت بيانات اعتماد المستخدم بشكل آمن، وهذا بيان يمكنك استخدامه للتحقق من ذلك". يمكن للطرف المعتمد بعد ذلك التحقق من أن التوقيع يأتي من أداة مصادقة معينة مسموح بها (مثل Yubikey). لا تستجيب جميع أدوات المصادقة الخاصة بمفاتيح المرور بمثل هذا التصديق، فبعضها لا يرسل بيانات مفيدة (انظر هنا قائمة أدوات المصادقة الخاصة بمفاتيح المرور). يمكن العثور على المزيد من AAGUIDs (معرّفات التصديق الفريدة لأداة المصادقة) التي تحدد المزيد من أدوات المصادقة (بشكل أساسي مفاتيح الأمان، مثل YubiKeys) في خدمة البيانات الوصفية لتحالف FIDO.
• التأكيد (Assertion): بعد عملية الاشتراك، عندما يحاول المستخدم تسجيل الدخول، تُنتج أداة المصادقة تأكيدًا. التأكيد هو بشكل أساسي PublicKeyCredential + التحدي الموقّع. يثبت هذا التأكيد أن المستخدم يمتلك المفتاح الخاص المرتبط بالمفتاح العام المسجل دون الكشف عن المفتاح الخاص الفعلي. إنها طريقة أداة المصادقة لقول: "هذا هو المستخدم الحقيقي، ويمكنني أن أضمن له".

Subscribe to our Passkeys Substack for the latest news.

Subscribe

المفاتيح المقيمة (RKs) والمفاتيح غير المقيمة (NRKs) هما نوعان من المفاتيح المشفرة المستخدمة في بروتوكول WebAuthn، ويختلفان بشكل أساسي في موقع تخزينهما وآلية استرجاعهما.

التعريف:

يتم تخزين المفاتيح المقيمة مباشرة على أداة المصادقة نفسها. يمكن أن يكون هذا مفتاح أمان (مثل YubiKey)، أو منطقة آمنة على المنصة (مثل Secure Enclave في iPhone)، أو وحدة منصة موثوقة (TPM) على جهاز كمبيوتر محمول. تعمل واجهة المستخدم الشرطية (الملء التلقائي لمفاتيح المرور) فقط مع المفاتيح المقيمة، وتتطلب مجموعة عمل WebAuthn حاليًا أن تكون المفاتيح مقيمة لتُعتبر كمفتاح مرور.

في لقطة الشاشة التالية، ترى قائمة بجميع المفاتيح المقيمة (معرّف بيانات الاعتماد، rpID، اسم المستخدم، اسم العرض) المخزنة على YubiKey. المفاتيح غير المقيمة ليست في القائمة، لأنها غير مخزنة على أداة المصادقة:

تدفق تسجيل الدخول:

المصدر: William Brown

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

المزايا:

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

العيوب:

1. محدودية التخزين: بعض أدوات المصادقة لديها سعة تخزين محدودة. خاصة بالنسبة لمفاتيح الأمان (مثل YubiKeys)، غالبًا ما يكون هناك حد لعدد المفاتيح المقيمة التي يمكنها تخزينها (معظمها لديه حد يتراوح من 8 إلى حوالي 100 مفتاح مقيم). بمجرد الوصول إلى هذا الحد، قد يلزم حذف المفاتيح القديمة لتوفير مساحة للجديدة، أو قد يحتاج المستخدم إلى استخدام أداة مصادقة أخرى.
2. فقدان أداة المصادقة: إذا فُقدت أداة المصادقة، على سبيل المثال، مفتاح أمان (مثل YubiKey) أو هاتف ذكي، أو تعرضت للتلف، فسيتم فقدان جميع المفاتيح المقيمة على هذا الجهاز. قد يؤدي هذا إلى منع المستخدمين من الوصول إلى خدمات متعددة حتى يعيدوا التسجيل أو يستعيدوا حساباتهم. تمنع مزامنة المفاتيح عبر حساب سحابي (مثل iCloud Keychain، Google Password Manager) أو مدير كلمات مرور حديث (مثل 1Password أو Dashlane) هذا الفقدان.
3. مخاوف أمنية: إذا سُرقت أداة مصادقة بها مفاتيح مقيمة، فقد يحاول المهاجم استخراج المفاتيح. على الرغم من أن أدوات المصادقة الحديثة لديها آليات أمان قوية لمنع الاستخراج، على سبيل المثال، يحمي المستخدم الجهاز برقم PIN قوي أو رمز مرور أو إيماءة، إلا أن الخطر، وإن كان ضئيلاً، لا يزال قائماً.

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

Want to find out how many people use passkeys?

View Adoption Data

التعريف:

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

تدفق تسجيل الدخول:

المصدر: William Brown

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

المزايا:

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

العيوب:

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

حالات الاستخدام: مثالية لأدوات المصادقة المتنقلة مثل مفاتيح الأمان (مثل YubiKeys) التي تُستخدم عبر خدمات أو منصات متعددة.

تخيل أن لديك مفتاح أمان (مثل YubiKey)، وقمت بتسجيله في خدمتين عبر الإنترنت: الخدمة A والخدمة B. بالنسبة للخدمة A، تستخدم مفتاحًا مقيمًا. بالنسبة للخدمة B، تستخدم مفتاحًا غير مقيم. عندما تصادق على الخدمة A، ما عليك سوى النقر على مفتاح الأمان الخاص بك (مثل YubiKey)، وبذلك تكون قد دخلت - لا حاجة لتحديد اسم مستخدم. بالنسبة للخدمة B، ستقدم أولاً اسم المستخدم الخاص بك في المتصفح / التطبيق الأصلي. ترسل الخدمة بعد ذلك معرّف بيانات الاعتماد المرتبط إلى مفتاح الأمان الخاص بك (مثل YubiKey)، والذي يقوم بعد ذلك بإعادة إنشاء المفتاح الخاص المؤقت للمصادقة.

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

Want to experiment with passkey flows? Try our Passkeys Debugger.

Try for Free

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

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

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

CTAP هو بروتوكول أساسي في معيار FIDO2، يسد فجوة الاتصال بين العملاء (مثل المتصفحات) وأدوات المصادقة (مثل مفاتيح الأمان، على سبيل المثال YubiKeys، أو الهواتف الذكية). لفهم CTAP بشكل أفضل، دعنا نلقي نظرة سريعة أولاً على إصدارات البروتوكول المختلفة قبل تحليل التأثير على المفاتيح المقيمة وغير المقيمة.

الإصدار الأقدم، الذي يشار إليه غالبًا باسم Universal 2nd Factor (U2F)، تم تصميمه بشكل أساسي للمصادقة الثنائية. في U2F، يوفر الخادم تحديًا، وتوفر أداة المصادقة استجابة، مما يثبت حيازة المفتاح الخاص. ومع ذلك، لا يدعم U2F المفاتيح المقيمة، مما يعني أنه يتطلب دائمًا بحثًا من جانب الخادم لتحديد المفتاح الذي يجب استخدامه للمستخدم، حيث كان هذا جزءًا من العملية عند طلب عامل ثان.

قدم CTAP2، خليفة U2F، دعمًا للمفاتيح المقيمة، مما يسمح بالمصادقة بدون كلمة مرور وبدون اسم مستخدم. مع المفاتيح المقيمة، تخزن أداة المصادقة اسم المستخدم الخاص بالمستخدم ومعرّف بيانات الاعتماد (مع معرّف الطرف المعتمد)، مما يلغي حاجة خادم الطرف المعتمد لتوفيره أثناء المصادقة. هذه قفزة كبيرة نحو تجربة مستخدم أكثر سلاسة.

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

CTAP2.1 هو إصدار لاحق من CTAP2، يجلب ميزات وتحسينات إضافية على البروتوكول. بعض النقاط الرئيسية حول CTAP 2.1 تشمل:

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

بعد إلقاء نظرة على المفاتيح المقيمة والمفاتيح غير المقيمة وإصدارات CTAP المختلفة، نقوم الآن بتحليل جانب الطرف المعتمد وبالتالي جانب خادم WebAuthn بمزيد من العمق.

تُعزى مرونة WebAuthn (ولكن أيضًا تعقيدها) إلى حد كبير إلى إعدادات الخادم الخاصة به، لا سيما داخل كائن authenticatorSelection. يوجه هذا الكائن العميل في اختيار أداة المصادقة المناسبة للمهمة.

{
    "rp": {
        "name": "corbado.com",
        "id": "corbado.com"
    },
    "user": {
        "id": "dGVzdefEyMjE",
        "name": "test-username",
        "displayName": "test-username"
    },
    "challenge": "mhanjsapJjCNaN_Ttasdfk1C0DymR-V_w_0UVOPsdfdfJG2ON_FK5-ODtqp33443tgqHzuuDjv-NUUmMAE4hg",
    "pubKeyCredParams": [
        {
            "type": "public-key",
            "alg": -7
        },
        {
            "type": "public-key",
            "alg": -257
        }
    ],
    "timeout": 60000,
    "excludeCredentials": [],
    "authenticatorSelection": {
        "authenticatorAttachment": "platform",
        "residentKey": "preferred",
        "requireResidentKey": false,
        "userVerification": "preferred"
    },
    "attestation": "none",
    "extensions": {
        "credProps": true
    }
}

يحدد خيار الخادم هذا كيفية توصيل أداة المصادقة بجهاز العميل. يوفر رؤى حول كيفية تواصل أداة المصادقة مع العميل:

القيم الممكنة

• Platform: يشير هذا إلى أن أداة المصادقة متصلة بمنصة العميل وبالتالي لا يمكن إزالتها.
• Cross-platform: يشير هذا إلى أن أداة المصادقة غير مرتبطة بمنصة العميل ويمكن استخدامها على أجهزة متعددة.

حالات الاستخدام والأمثلة

• Platform: تشمل الأمثلة ماسح بصمات الأصابع المدمج في جهاز كمبيوتر محمول أو نظام التعرف على الوجه على هاتف، على سبيل المثال، Face ID، Touch ID أو Windows Hello.
• Cross-platform: تشمل الأمثلة مفاتيح أمان USB (مثل YubiKeys)، وأجهزة Bluetooth، أو بطاقات NFC.

في مواصفات WebAuthn المستوى 1، كان يسمى خيار الخادم هذا requireResidentKey وكان يمكن أن يحمل القيم المنطقية true (يجب على أداة المصادقة إنشاء مفتاح مقيم) أو false (يجب على أداة المصادقة إنشاء مفتاح غير مقيم). استبدل WebAuthn المستوى 2 خيار الخادم هذا بخيار الخادم الجديد residentKey:

القيم الممكنة

• Required: يجب على أداة المصادقة إنشاء مفتاح مقيم (إذا لم يكن ذلك ممكنًا، يجب أن تفشل العملية).
• Preferred: يجب أن تحاول أداة المصادقة إنشاء مفتاح مقيم (إذا لم يكن ذلك ممكنًا، يجب أن تنشئ مفتاحًا غير مقيم).
• Discouraged: يجب على أداة المصادقة إنشاء مفتاح غير مقيم (إذا لم يكن ذلك ممكنًا، يجب أن تفشل العملية).

حالات الاستخدام والأمثلة

• Required: مثالي للسيناريوهات التي يكون فيها تسجيل الدخول بدون اسم مستخدم مطلوبًا أو حيث يجب على المستخدمين المصادقة فقط من الأجهزة المسجلة مسبقًا (عن طريق إضافة طبقة أمان إضافية بربط بيانات اعتماد المستخدم بجهاز معين).
• Preferred: مناسب للسيناريوهات التي ترغب فيها خدمة الويب في توفير أفضل تجربة تسجيل دخول ممكنة (عبر المفاتيح المقيمة)، ولكنها لا تزال ترغب في دعم المفاتيح غير المقيمة إذا لم تكن المفاتيح المقيمة ممكنة.
• Discouraged: ترغب خدمة ما في تقديم المصادقة بمفاتيح المرور وترغب أيضًا في ضمان أن يتمكن المستخدمون من استخدام أي أداة مصادقة، حتى تلك التي لا تحتوي على إمكانيات تخزين، دون ربط بيانات الاعتماد بجهاز معين.

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

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

القيم الممكنة

• Required: يجب أن تتضمن العملية التحقق من المستخدم.
• Preferred: يجب أن تتضمن العملية التحقق من المستخدم إن أمكن، ولكن يمكن أن تستمر بدونه.
• Discouraged: يجب ألا تتضمن العملية التحقق من المستخدم.

حالات الاستخدام والأمثلة

• Required: مثالي للتطبيقات عالية الأمان مثل الخدمات المصرفية أو الرعاية الصحية، حيث يكون التحقق من هوية المستخدم (على سبيل المثال، من خلال بصمة الإصبع أو رقم PIN) أمرًا بالغ الأهمية.
• Preferred: مفيد للتطبيقات العامة حيث تكون الأمان الإضافي ميزة إضافية ولكنها ليست ضرورية تمامًا.
• Discouraged: مناسب للعمليات منخفضة المخاطر أو السيناريوهات التي قد يكون فيها التحقق من المستخدم غير مريح.

النمط

• Authenticator attachment: platform
• Resident key: required
• User verification: required

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

النمط

• Authenticator attachment: cross-platform
• Resident key: required
• User verification: required

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

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

مثال: قد يكون لدى YubiKey القدرة على تخزين 20 مفتاحًا مقيمًا فقط. بمجرد الوصول إلى هذا الحد، لا يمكن إضافة مفاتيح مقيمة إضافية دون حذف المفاتيح الموجودة.

الحل:

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

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

يعد السلوك غير المتسق لخيارات خادم WebAuthn المختلفة على منصات مختلفة مشكلة رئيسية. على سبيل المثال، سيقوم iOS دائمًا بإنشاء مفتاح مقيم بغض النظر عن خيارات خادم WebAuthn التي تم تمريرها إليه، بينما يتطلب Android الاشتراك (على سبيل المثال، مع residentKey: preferred أو residentKey: required).

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

السبب وراء ذلك هو وجود اقتراح في WebAuthn لتخزين معلومات حول نوع بيانات الاعتماد (مفتاح مقيم أو مفتاح غير مقيم) في ملحق خصائص بيانات الاعتماد (clientExtensionResults.credProps.rk والذي يكون إما true أو false). ومع ذلك، فإن توفير هذه المعلومات إلى الطرف المعتمد غير مضمون لأن جميع ملحقات WebAuthn اختيارية، على سبيل المثال، لا يرسلها iOS (لذلك لا تعرف ما إذا كان مفتاحًا مقيمًا أم مفتاحًا غير مقيم).

خلال بحثنا، حاولنا اختبار السلوك على منصات وأدوات مصادقة مختلفة (Windows 10، Windows 11، Android 7، Android 13، iOS17، macOS Ventura، YubiKey) مع صفحتين تجريبيتين لـ WebAuthn توفران مزيدًا من التفاصيل حول بيانات الاعتماد التي تم إنشاؤها: https://webauthn.io وhttps://webauthntest.identitystandards.io/. يوفر الأخير إمكانية العمل مع الخاصية القديمة requireResidentKey (WebAuthn المستوى 1) وحتى دمجها مع الخاصية residentKey (WebAuthn المستوى 2). ومع ذلك، لم تكن النتائج موثوقة (على سبيل المثال، ذكر أنه مفتاح غير مقيم لنظام iOS ولكن من الواضح أن واجهة المستخدم الشرطية عملت).

نظام التحقق الأكثر جدارة بالثقة الذي وجدناه هو التالي:

1. تحقق من إعدادات خادم WebAuthn الخاص بك للخاصية "residentKey"
   1. إذا كان "residentKey: required" وتم إنشاء بيانات اعتماد بنجاح -> فهو مفتاح مقيم
   2. إذا كان "residentKey: preferred" أو "residentKey: discouraged"، فانتقل إلى الفحص التالي
2. هل الملحق credProps.rk مدعوم ومخزن في بيانات الاعتماد على الخادم؟
   1. إذا كان credProps.rk = true، فإن بيانات الاعتماد هي مفتاح مقيم
   2. إذا كان credProps.rk = false، فإن بيانات الاعتماد هي مفتاح غير مقيم
   3. إذا كان credProps فارغًا، فإن نوع بيانات الاعتماد غير معروف

كما ترى، هذا يساعد على تضييق نطاقه، لكن الخيار غير المعروف لا يزال قائمًا ولا يمكنك تحديد نوع المفتاح بيقين 100٪.

يتماشى هذا أيضًا مع نتائج ويليام براون من SUSE في مقالته الرائعة التي توضح كيف يمكن أن تصبح مفاتيح الأمان (مثل YubiKeys) عديمة الفائدة إذا كانت المفاتيح المقيمة مطلوبة من قبل الأطراف المعتمدة (قمنا بتوسيع جدوله):

في الجدول، ترى لخيارات المفاتيح المقيمة المختلفة لخادم WebAuthn ما إذا تم إنشاء مفتاح مقيم (true)، أو إذا تم إنشاء مفتاح غير مقيم (false)، أو حدث شيء آخر.

الحل:

• اختبار شامل: قبل النشر، اختبر تنفيذ WebAuthn الخاص بك عبر مجموعة من أدوات المصادقة الشائعة لفهم سلوكها.
• إعدادات خادم صريحة: عند إعداد خادم WebAuthn الخاص بك، كن صريحًا في متطلباتك. إذا كنت تريد أن يكون لديك مفاتيح مرور فقط، فقم بتعيين خيار residentKey إلى required (ملاحظة: قد يؤدي هذا إلى تحديات أخرى مع أدوات المصادقة ذات سعة المفاتيح المقيمة المحدودة، انظر أعلاه).

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

الحل:

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

9. أفضل الممارسات للمطورين ومديري المنتجات

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

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

إعدادات التحقق من المستخدم (UV): اعتمادًا على مستوى الأمان الذي ترغب في تحقيقه، يمكنك تحديد مدى صرامة عملية التحقق من المستخدم. إذا كنت تهدف إلى أمان عالٍ، فمن المستحسن طلب رقم PIN أو بصمة إصبع أو التعرف على الوجه (userVerification: preferred أو userVerification: required).

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

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

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

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

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

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

• authenticator: platform
• residentKey: required
• userVerification: required

الفوائد:

• بما أن جميع المفاتيح التي تم إنشاؤها هي مفاتيح مقيمة، فإن الإعداد يسمح بواجهة المستخدم الشرطية مما يجعل تسجيل الدخول الخاص بك أكثر سلاسة للمستخدمين حيث لا يتعين عليهم تذكر اسم مستخدم.
• يتم دعم جميع الأجهزة الحديثة من Apple و Google و Microsoft وتستخدم مفاتيح المرور.

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

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