غالبًا ما يتم مقارنة WebAuthn وJWTs كما لو كانا يحلان نفس المشكلة. لكنه لا يحدث. WebAuthn يتعلق بكيفية إثبات المستخدم لهويته. بينما JWTs هي طريقة واحدة يمكّن بها الخادم من تمثيل حالة مصادق عليها بعد نجاح ذلك الإثبات.
تعتبر هذه التفرقة مهمة لأنها تغير محادثة الهندسة المعمارية تمامًا.
أين يتناسب WebAuthn
يوفر WebAuthn مصادقة قائمة على مفاتيح عامة، مقاومة للتصيد الاحتيالي ومربوطة بالجهة الأصلية. يمكن أن يبدأ تدفق المتصفح هكذا:
const credential = await navigator.credentials.get({
publicKey: optionsFromServer,
});
النقطة المهمة ليست استدعاء واجهة برمجة التطبيقات. بل خاصية الأمان: الاعتماد هو مرتبط بالجهة الأصلية ومدعوم من خلال علم التشفير بالمفاتيح العامة.
أين تتناسب JWTs
بعد نجاح المصادقة، لا يزال يتعين على الخادم الحفاظ على نموذج الجلسة. قد يكون ذلك:
- ملف تعريف ارتباط HttpOnly
- JWT
- معرّف جلسة غير شفاف
تتعلق JWTs بنقل الجلسات وتمثيل المطالبات. إنها لا تجعل المصادقة مقاومة للتصيد الاحتيالي بمفردها.
هذا يعني أن هندسة قوية قد تبدو كالتالي: WebAuthn للتحقق من المستخدم، ثم ملف تعريف ارتباط HttpOnly أو رمز جلسة آخر للحالة المستمرة. هذه الطبقات تتعاون. إنها لا تتنافس.
قاعدة أفضل
استخدم WebAuthn لتحسين مراسم تسجيل الدخول. اختر JWTs، أو ملفات تعريف الارتباط، أو الجلسات غير الشفافة بناءً على كيفية تعامل بقية النظام الأساسي مع الحالة، والإلغاء، وأمان المتصفح.
يمكن أن يقوي WebAuthn النظام بغض النظر عن الشكل التالي لرمز الجلسة.
قراءة إضافية