واجهة برمجة تطبيقات إشارة WebAuthn: تحديث وحذف مفاتيح المرور من جانب العميل

يتطور نظام مفاتيح المرور باستمرار. ولتسهيل هذا التغيير، يتطور معيار WebAuthn الأساسي بسرعة. غالبًا ما تبدأ الميزات الجديدة بشرح تقني في GitHub ثم تتطور إلى طلب سحب (pull request) في المعيار عندما تتم مناقشتها بشكل كافٍ. مؤخرًا، أُضيف طلب السحب هذا إلى مسودة المعيار باسم واجهة برمجة تطبيقات إشارة WebAuthn. في هذا المقال، سنتناول:

• لماذا نحتاج إلى واجهة برمجة تطبيقات إشارة WebAuthn: ما هي حالات الاستخدام التي تدعمها واجهة برمجة تطبيقات إشارة WebAuthn؟
• كيف تعمل واجهة برمجة تطبيقات إشارة WebAuthn: كيف تعمل واجهة برمجة تطبيقات إشارة WebAuthn بالضبط؟ ما هي التوصيات للأطراف المعتمدة (relying parties)؟

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

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

Subscribe to our Passkeys Substack for the latest news.

Subscribe

عند إنشاء مفتاح مرور، فإنه يتضمن عدة أجزاء من المعلومات: user.id و user.name و user.displayName. يتم تحديد مفتاح المرور نفسه عبر معرف الاعتماد (Credential ID) الفريد.

• user.id: هو معرف فريد يمثل الحساب الذي يرتبط به مفتاح المرور. هذا user.id حاسم لأنه يُستخدم للمطابقة الفعلية لمفتاح المرور مع حساب المستخدم.
• user.name و user.displayName: هذه بيانات وصفية تُستخدم فقط لأغراض العرض في واجهة المستخدم.

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

من المهم أن نفهم أنه بينما يساعد user.name (غالبًا ما يكون عنوان بريد إلكتروني) و user.displayName (اسم أكثر ودية وقابلية للقراءة) المستخدم في تحديد حسابه في واجهة الاختيار، فإن الارتباط الحقيقي بين مفتاح المرور والحساب يتم الحفاظ عليه من خلال user.id و معرف الاعتماد (Credential ID):

• يمكن أن يحتوي الحساب على عدة مفاتيح مرور، ولكن يتم تحديد كل مفتاح مرور بشكل فريد ومطابقته مع الحساب باستخدام user.id.
• كل مفتاح مرور له معرف اعتماد (Credential ID) فريد يتم إنشاؤه بواسطة أداة المصادقة (authenticator).

تنشأ إحدى المشكلات عندما يتغير user.name، والذي يمكن أن يكون عنوان بريد إلكتروني. حاليًا، لا توجد آلية لتحديث هذا التغيير على أداة المصادقة (authenticator) من جانب العميل مباشرة. يمكن أن يتغير user.name لأسباب مختلفة، مثل عندما يقوم المستخدم بتحديث عنوان بريده الإلكتروني. على الرغم من هذا التغيير في البيانات الوصفية للحساب على جانب الخادم، سيستمر user.name القديم في الظهور في واجهة اختيار بيانات الاعتماد، مما قد يسبب ارتباكًا للمستخدمين.

الحل البديل لهذه المشكلة هو إنشاء مفتاح مرور جديد بـ user.name المحدث ونفس user.id، ثم الكتابة فوق مفتاح المرور الحالي. ومع ذلك، هذا النهج غير مريح لعدة أسباب:

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

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

Become part of our Passkeys Community for updates & support.

Join

حالة استخدام حاسمة أخرى هي حذف مفاتيح المرور على أداة المصادقة من جانب العميل. بمرور الوقت، قد يلغي المستخدمون بيانات الاعتماد عبر قائمة إدارة مفاتيح المرور أو يحذفون حساباتهم، ويصبح من الضروري التأكد من إزالة بيانات الاعتماد هذه من أداة المصادقة (authenticator) من جانب العميل لمنع ظهورها في واجهات اختيار بيانات الاعتماد المستقبلية (Conditional UI / الملء التلقائي لمفاتيح المرور (passkey autofill)).

تنشأ الحاجة إلى هذه الوظيفة في عدة سيناريوهات:

1. حذف مفتاح المرور عبر إعدادات الحساب: عندما لا تعود بيانات الاعتماد صالحة، كما هو الحال بعد أن يحذفها المستخدم صراحةً عبر إعدادات الحساب:

من منظور المستخدم، من الصعب فهم أن الحذف في إعدادات حسابه، في حوار مثل الموضح أعلاه، لا يؤدي إلى إزالة مفتاح المرور على هذا العميل.

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

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

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

عند تنفيذ واجهة برمجة تطبيقات إشارة WebAuthn، من الضروري مراعاة الاعتبارات التالية:

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

• توفر أداة المصادقة: تعتمد فعالية واجهة برمجة تطبيقات إشارة WebAuthn على توفر أداة المصادقة. يشمل ذلك التوفر المادي (على سبيل المثال، وجود مفتاح أمان (security key)) ودعم البرامج (على سبيل المثال، توافق المتصفح ونظام التشغيل). لا يمكن للمتصفح تنفيذ الإجراءات إلا إذا كانت أداة المصادقة (authenticator) متاحة وتدعم العمليات اللازمة دون الحاجة إلى المصادقة البيومترية.

• قيود النطاق: تضمن الواجهة أن الطرف المعتمد (relying party) المرتبط بنطاق معين هو الوحيد الذي يمكنه طلب تغييرات على بيانات الاعتماد المتعلقة بهذا النطاق. هذا إجراء أمني لمنع التعديلات غير المصرح بها من قبل أطراف ثالثة.

• معرف الاعتماد كمفتاح: عند الإشارة إلى مفاتيح المرور، فإن معرف الاعتماد (Credential ID) هو المفتاح الأساسي الذي تستخدمه واجهة برمجة تطبيقات إشارة WebAuthn. يحدد هذا المعرف بشكل فريد مفتاح المرور على أداة المصادقة من جانب العميل. تسمح الواجهة للأطراف المعتمدة بتغيير البيانات الوصفية المرتبطة بمفاتيح المرور أو الإشارة إلى أنه لا ينبغي الوصول إلى مفاتيح مرور معينة، ولكن فقط من خلال معرف الاعتماد. في حالة عدم معرفة أداة المصادقة (authenticator) بمعرف اعتماد معين، فإنها ستتجاهله بصمت.

هذه الاعتبارات ضرورية لفهم أهم جوانب وظائف واجهة برمجة تطبيقات إشارة WebAuthn بشكل صحيح.

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

تحديث البيانات الوصفية باستخدام signalCurrentUserDetails(options)

صُممت طريقة signalCurrentUserDetails(options) في واجهة برمجة تطبيقات الإشارة خصيصًا لتحديث البيانات الوصفية لمفاتيح المرور. تسمح هذه الطريقة للأطراف المعتمدة بتوفير القيم الحالية لـ user.name و user.displayName.

إليك كيفية عمل العملية (انظر أيضًا معيار WebAuthn المستوى 3).

1. بنية الطريقة: تتضمن طريقة signalCurrentUserDetails(options) rp.id و user.id والقيم المحدثة لـ user.name و user.displayName.

PublicKeyCredential.signalCurrentUserDetails({
    rpId: "example.com",
    userId: "aabbcc", // user handle, base64url.
    name: "New user name",
    displayName: "New display name",
});

2. تحديث البيانات الوصفية المحلية: ابحث عن بيانات الاعتماد المتاحة محليًا (على أداة المصادقة) التي تطابق rpId و userId. لجميع بيانات الاعتماد المطابقة، ستقوم أداة المصادقة بتحديث name و displayName لبيانات الاعتماد.

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

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

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

توفر واجهة برمجة تطبيقات إشارة WebAuthn آليات للأطراف المعتمدة (RPs) للإشارة إلى حذف مفاتيح المرور من أدوات المصادقة (authenticators) من جانب العميل. هذا ضروري لضمان عدم ظهور بيانات الاعتماد القديمة أو غير الصالحة في واجهة اختيار بيانات الاعتماد، وبالتالي الحفاظ على تجربة مستخدم مبسطة وآمنة. هناك طريقتان لحذف مفاتيح المرور محليًا: signalUnknownCredential(options) و signalAllAcceptedCredentials(options). يمكن استخدام الأولى في الحالات التي لا يكون فيها المستخدم مصادقًا عليه، بينما يمكن استخدام الثانية عندما يكون المستخدم مصادقًا عليه. لذلك، يجب تفضيل الأخيرة لأسباب تتعلق بالخصوصية.

إليك كيفية عمل الطريقتين:

1. بنية الطريقة: تتضمن طريقة signalUnknownCredential(options) rpId (معرف الطرف المعتمد) و credentialId (المعرف الفريد لبيانات الاعتماد المراد حذفها).

PublicKeyCredential.signalUnknownCredential({
    rpId: "example.com",
    credentialId: "aabbcc", // credential id the user just tried, base64url
});

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

3. معالجة الطريقة: عند استدعاء طريقة signalUnknownCredential(options)، تحاول أداة المصادقة من جانب العميل العثور على بيانات الاعتماد التي تطابق rpId و credentialID المحدد للإغفال. اعتمادًا على قدرات أداة المصادقة (authenticator)، تتم إزالة بيانات الاعتماد أو يتم استخدام إجراء خاص بأداة المصادقة لإخفاء بيانات الاعتماد في مراسم المصادقة المستقبلية.

1. بنية الطريقة: تتضمن طريقة signalAllAcceptedCredentials(options) rpId (معرف الطرف المعتمد)، و userId، وقائمة بمعرفات الاعتماد الصالحة allAcceptedCredentialIds (قائمة بالمعرفات الفريدة لبيانات الاعتماد التي يجب الاحتفاظ بها).

PublicKeyCredential.signalAllAcceptedCredentials({
    rpId: "example.com",
    userId: "aabbcc", // user handle, base64url.
    allAcceptedCredentialIds: ["bb"],
});

2. استدعاء الطريقة: تستدعي الأطراف المعتمدة هذه الطريقة كلما اكتشفت أنه يجب حذف بيانات اعتماد والإشارة إلى قائمة ببيانات الاعتماد الصالحة. يجب تفضيل هذه الطريقة على signalUnknownCredential(options) لحذف بيانات الاعتماد.

3. معالجة الطريقة: عند استدعاء طريقة signalAllAcceptedCredentials(options)، تطابق أداة المصادقة من جانب العميل rpId و userId. تبحث أداة المصادقة عن جميع بيانات الاعتماد المحلية التي تطابق rpId و userId. تتم مقارنة النتيجة بـ allAcceptedCredentialIds. إذا كانت هناك بيانات اعتماد محلية غير موجودة في allAcceptedCredentialIds، فسيتم إزالة بيانات الاعتماد هذه محليًا (أو إخفاؤها اعتمادًا على أداة المصادقة).

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

5. نصائح مفيدة:

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

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

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

• ترقب تحديثات واجهة برمجة تطبيقات إشارة WebAuthn والتنفيذ الفعلي: ابق على اطلاع بآخر التطورات والتحديثات المتعلقة بواجهة برمجة تطبيقات الإشارة. تم تمكين واجهة برمجة تطبيقات إشارة WebAuthn مع Google Chrome 132، وستتبعه متصفحات أخرى (على سبيل المثال، أعلن Safari عن دعمه أيضًا). تحقق بانتظام من التقدم والتحديثات على واجهة برمجة تطبيقات إشارة WebAuthn لضمان توافق تنفيذك مع أحدث المعايير والممارسات. سنقوم بتحديث هذا المقال في المستقبل، وهو يعتمد حاليًا على المعلومات المتاحة اعتبارًا من 14 يناير 2025.
• ابدأ بنهج signalAllAcceptedCredentials(options) بعد كل عملية تسجيل دخول ناجحة: يضمن هذا النهج تحديث جميع البيانات الوصفية ومعرفات الاعتماد في طريقة واحدة، مما يبسط العملية ويحافظ على الاتساق عبر الأجهزة والمنصات وفي نفس الوقت يعطل بيانات الاعتماد المحذوفة أو القديمة.
• استخدام الرسائل في الوقت الفعلي مع signalUnknownCredential(options) للنشرات واسعة النطاق: فكر في استخدام الرسائل في الوقت الفعلي مع طريقة signalUnknownCredential(options) في النشرات واسعة النطاق أو عندما تكون هناك حاجة لتحديثات فورية. يمكن لهذه الطريقة أن تعزز كفاءة ودقة إدارة بيانات الاعتماد، مما يضمن إزالة بيانات الاعتماد غير الصالحة أو القديمة على الفور من واجهة الاختيار.

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

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

• لماذا نحتاج إلى واجهة برمجة تطبيقات الإشارة؟ تعد واجهة برمجة تطبيقات الإشارة ضرورية لتحديث البيانات الوصفية لمفاتيح المرور وحذف مفاتيح المرور على أدوات المصادقة من جانب العميل. فهي تحل المشكلات المتعلقة بمعلومات user.name و user.displayName القديمة، والتي يمكن أن تسبب ارتباكًا عند تقديم بيانات الاعتماد في واجهة الاختيار. بالإضافة إلى ذلك، تساعد في الحفاظ على واجهة اختيار بيانات اعتماد نظيفة وآمنة عن طريق إزالة مفاتيح المرور الملغاة أو المحذوفة.
• كيف تعمل واجهة برمجة تطبيقات الإشارة؟ تعمل واجهة برمجة تطبيقات الإشارة عن طريق السماح للأطراف المعتمدة باستدعاء طرق حول الحالة الحالية لبيانات الاعتماد، بما في ذلك تحديثات البيانات الوصفية والإشارة إلى حذف مفاتيح المرور. تتم معالجة هذه التقارير بواسطة أداة المصادقة من جانب العميل، مما يضمن أن المعلومات المقدمة للمستخدمين دقيقة ومحدثة. صُممت الواجهة للحفاظ على الخصوصية وتعمل دون تقديم ملاحظات إلى الطرف المعتمد حول نجاح التحديثات.

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