الجزء 2: مصادقة المستخدم كاملة: جلسات مقابل JWT

تأتي الجلسات و JWT في مقدمة التحليلات الأكثر عمقًا لمكوناتها الحقيقية: استراتيجية التخزين والتحقق من الصحة.

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

تصوير كوشيك تشودافارابو على Unsplash

جلسات مقابل JWT

مقارنة شعبية كما هي ، Sessions vs JWT غير دقيقة.

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

الاهتمام 1: آلية التخزين (ملفات تعريف الارتباط مقابل التخزين المحلي)

لماذا التخزين؟ تستخدم معرفات الجلسة دائمًا ملفات تعريف الارتباط كآلية تخزين بها. هذه العلاقة معروفة على نطاق واسع وهي موجودة في معظم حزم برامج إستراتيجية الجلسة (مثل Node.js express-session).

ومع ذلك ، يمكن أيضًا تخزين JWT ، وخاصة رمزًا مرجعيًا مرجعيًا ، في ملف تعريف الارتباط ؛ لا يجب أن يكونوا دائمًا في localStorage. الاختلافات بين ملفات تعريف الارتباط و localStorage كبيرة ، وهذا هو السبب في أن التخزين هو الشاغل الأول في تعطلنا.

الاهتمام 2: استراتيجية التحقق من الصحة (قائمة بذاتها مقابل قائمة مرجعية)

لماذا استراتيجية التحقق من الصحة؟ تعد استراتيجية التحقق من الصحة التي تقوم بمصادقة معرف (معرف الجلسة أو الرمز المميز المرجعي) مقابل مرجع في قاعدة بيانات استراتيجية مختلفة تمامًا عن تلك التي تستخدم JWT للاحتواء الذاتي للمصادقة.

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

من بين هذين الشاغلين ، تبقى لنا مقارنات أكثر دقة وملاءمة:

  • ملفات تعريف الارتباط مقابل localStorage
  • استراتيجية التحقق من الصحة: ​​قائمة بذاتها مقابل المرجع

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

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

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

ملفات تعريف الارتباط مقابل localStorage

لقد قمنا بتغطية بعض أساسيات تخزين ملفات تعريف الارتباط في الجزء الأول في وقت سابق ، لكننا لم نتحدث بالفعل عن localStorage حتى الآن. ما هو localStorage وكيف يمكن مقارنته بملفات تعريف الارتباط في سياق المصادقة؟

أساسيات التخزين المحلي

LocalStorage هي ميزة تخزين مستعرض HTML5 تسمح لموقع ويب بتخزين البيانات والوصول إليها (عبر العميل).

لاستخدام localStorage ، يجب أن يقوم JavaScript (العميل) للتطبيق الأمامي بمعالجة استجابات الخادم وكتابة البيانات التي يريد localStorage يدويًا. على عكس ملفات تعريف الارتباط ، لا يتمكن الخادم من الوصول تلقائيًا إلى آلية التخزين عبر رؤوس HTTP.

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

على الرغم من أن العميل يجب أن يقوم بالعمل يدويًا (على عكس ملفات تعريف الارتباط) ، فإن هذه العمليات بسيطة للغاية مع واجهة برمجة تطبيقات Web Storage:

localStorage.setItem ("authToken"، authToken)؛
دع authToken = localStorage.getItem ("authToken") ؛

LocalStorage متاح في جميع النوافذ / علامات التبويب لنفس الأصل (المجال). لم يقم LocalStorage أيضًا بتاريخ انتهاء الصلاحية. هاتان الميزتان تتعارضان مع الأخوة ، وميزة تخزين الويب HTML5 الأخرى ، sessionStorage.

SessionStorage لا يستمر عبر علامات تبويب متعددة ويتم حذفه عند إغلاق الجلسة (علامة تبويب). عادة ما يتم اختيار LocalStorage عبر sessionStorage للرموز بسبب ثبات علامة تبويب / نافذة متعددة ، مما ينتج عنه تجربة مستخدم أفضل.

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

ملفات تعريف الارتباط مقابل localStorage: سرقة المصادقة من العميل (XSS)

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

الهجوم الشائع لسرقة المصادقة هو هجوم Scripting عبر المواقع (XSS). تتمثل النتيجة النهائية لهجوم XSS الناجح في قدرة المهاجم على تنفيذ JavaScript نيابة عن المستخدم. في الأساس ، يمتلك المهاجم سيطرة كاملة على العميل.

يمكن حماية البيانات الموجودة في ملف تعريف الارتباط من هجوم XSS ناجح إذا كان يستخدم إعداد HttpOnly لملف تعريف الارتباط ، مما يمنع العميل JavaScript من قراءة ملف تعريف الارتباط. ومع ذلك ، فإن ملف تعريف الارتباط بدون هذا الإعداد سيكون عرضة للخطر.

LocalStorage عرضة لهجوم XSS ناجح لأن localStorage يمكن الوصول إليه دائمًا من خلال عميل JavaScript.

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

لذلك من المهم دائمًا مكافحة XSS مباشرة في أي موقف ، بغض النظر عن جهاز التخزين المستخدم - ملف تعريف الارتباط أو غير ذلك.

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

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

أخيرًا ، يمكن أيضًا سرقة تفاصيل المصادقة بناءً على طلبات (https) غير الآمنة - هجوم رجل في الوسط ، شائع عبر شبكة wifi العامة. يمكن أن يؤثر ذلك على كل من localStorage وملفات تعريف الارتباط. إن فرض جميع الطلبات على أن يكون https (مع إعادة التوجيه 301 و HSTS) واستخدام الإعداد "آمن" لملف تعريف الارتباط يساعد على منع هجمات رجل في الوسط.

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

ملفات تعريف الارتباط مقابل localStorage: تزوير الطلبات من جانب الخادم مع المصادقة (CSRF)

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

على سبيل المثال ، يمكن إرسال طلب نيابة عن مستخدم مصادق عليه بالفعل لإعادة تعيين كلمة مرور ذلك المستخدم أو لإرسال دفعة من المستخدم إلى attacker@somedomain.com.

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

نظرًا لأن المستعرض يوفر تلقائيًا مصادقة ملف تعريف الارتباط في رؤوس HTTP ، فإن المصادقة التي توفرها ملفات تعريف الارتباط تكون عرضة لهذا النوع من الهجوم. مصادقة LocalStorage تكون عرضة لـ CSRF فقط عندما يكون هناك استخدام غير صحيح لطرق HTTP.

على وجه الخصوص ، تم تأسيس الاتفاقية على أن طرق GET و HEAD يجب ألا يكون لها أهمية اتخاذ إجراء بخلاف الاسترجاع.

عادةً ما تأتي الوقاية من هجمات CSRF للمصادقة التي توفرها ملفات تعريف الارتباط في شكل رموز مزامنة (موصى بها من قبل OWASP) ، وإعداد ملف تعريف الارتباط SameSite ، و / أو الاعتماد على سياسة نفس أصل المستعرض (في حالة استخدام نقاط النهاية لخادم الوصول إلى XHR فقط) . أوصي قراءة شاملة من خلال ورقة الغش CSRF لمنع OWASP.

نظرًا لتخزين الرمز المميز للمزامن (أو CSRF) عادةً في localStorage ، فإن هجوم XSS الناجح يعني أن المهاجم يمكنه أيضًا تقديم طلبات XHR مستضافة الأصل مع الرمز المميز للمزامن.

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

الخلاصة: يتمتع LocalStorage بالفوز هنا على ملفات تعريف الارتباط لأنه غير عرضة لهجمات CSRF طالما يتم استخدام أساليب HTTP بشكل صحيح لمعالجة الطلبات.

ملفات تعريف الارتباط مقابل localStorage: صعوبات التنفيذ

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

ومع ذلك ، يتطلب localStorage المعالجة اليدوية (العميل / JavaScript) للمصادقة من الاستجابة إلى التخزين والتخزين لطلب.

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

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

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

ملفات تعريف الارتباط مقابل localStorage: التطبيقات أحادية الصفحة (SPA) وخوادم API و Microservices

عند الاتصال بخادم API على مجال منفصل عن العميل (حالة SPA) ، يلزم مشاركة الموارد عبر المصادر (CORS). من السهل بعض الشيء التواصل مع المصادقة عبر CORS مع localStorage ، ولكن لا يزال ذلك ممكنًا مع ملفات تعريف الارتباط (باستخدام XHR مع بيانات الاعتماد ورؤوس استجابة التحكم في الوصول).

يتطلب استخدام ملفات تعريف الارتباط في هذه الحالة (يُطلق عليها "ملفات تعريف ارتباط الطرف الثالث") الاحتفاظ بقائمة بيضاء الأصل نظرًا لعدم السماح باستخدام wildcard (*) لـ Access-Control-Allow-Origin عند تمرير ملفات تعريف الارتباط. ومع ذلك ، على الرغم من أن ذلك ممكن ، إلا أن استخدام ملفات تعريف ارتباط الطرف الثالث للمصادقة يصبح مشكلة بسبب التكتيكات (مثل Safari ITP) المصممة لمنع تتبع ملفات تعريف الارتباط للمعلن (أيضًا من جهة خارجية). لذلك قد يكون من المستحسن الاعتماد على ملفات تعريف ارتباط الطرف الثالث في المستقبل.

يقيد بعض وكلاء المستخدم كيفية سلوك ملفات تعريف الارتباط للجهات الخارجية. على سبيل المثال ، يرفض بعض وكلاء المستخدم إرسال عنوان ملف تعريف الارتباط في طلبات الجهات الخارجية. يرفض البعض الآخر معالجة رأس Set-Cookie استجابةً لطلبات الجهات الخارجية.

إذا تطلب الأمر تمرير المصادقة نفسها إلى خدمات / واجهات برمجة التطبيقات متعددة النهاية في مجالات منفصلة ، فسيصبح من الصعب استخدام ملفات تعريف الارتباط. على سبيل المثال ، إذا احتاج كل من microservice-A.com و microservice-B.com إلى الوصول إلى ملف تعريف ارتباط مصادقة HttpOnly نفسه ، فستكون هذه مشكلة. هناك بعض الحلول لهذه المشكلة (على سبيل المثال الوكيل ، iframe المخفية) ، لكنها تضيف طبقات من التعقيد.

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

لا يتأثر استخدام localStorage بهذه المشكلات لأن عميل JavaScript يمكنه إرسال بيانات localStorage إلى أي مكان يريد.

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

ملفات تعريف الارتباط مقابل localStorage: الاستنتاج النهائي

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

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

بقدر ما يتعلق الأمر بالأمن ، يجب منع هجمات XSS و CSRF و MIM من خلال الأساليب الصحيحة عند استخدام ملفات تعريف الارتباط أو localStorage. لا يؤدي استخدام ملفات تعريف الارتباط إلى منع XSS كما أن استخدام localStorage لا يمنع CSRF تمامًا.

قائمة بذاتها مقابل المصادقة المستندة إلى المرجع

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

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

قائمة بذاتها مقابل المشار إليه: انعدام الجنسية والراحة

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

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

تم تقديم مصطلح نقل الحالة التمثيلية وتم تعريفه عام 2000 من قبل روي فيلدنج في رسالة الدكتوراه. أوضحت أطروحة Fielding مبادئ REST التي كانت تُعرف باسم "نموذج كائن HTTP" الذي بدأ في عام 1994 ، واستخدمت في تصميم معايير HTTP 1.1 و Uniform Resource Identifiers (URI).

ماذا يعني بالضبط الذهاب عديمي الجنسية لخدمات الويب؟

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

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

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

استراتيجية المصادقة المستندة إلى مرجع ينتهك انعدام الجنسية.

في سياق قابلية معالجة المورد ، يكون انعدام الجنسية منطقيًا ، ولكن لماذا من المهم المصادقة أو الجلسات؟ وهل يهم أن المصادقة المستندة إلى المرجع تنتهك انعدام الجنسية؟

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

الوجبات السريعة الرئيسية هنا (والحجة النموذجية) في سياق انعدام الجنسية للمصادقة هي السرعة وقابلية التوسع.

يعد توسيع نطاق تطبيق ويب لدعم عدد كبير من الطلبات المتزامنة أو الجلسات النشطة مشكلة تقليدية عند التعامل مع إدارة الجلسة.

باستخدام JWT للمصادقة المحتوية ذاتياً ، تعيش المصادقة بالكامل داخل العميل ولم يعد من الضروري تخزين حالة العميل (معرف المصادقة في هذه الحالة) على الخادم.

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

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

تجدر الإشارة أيضًا إلى أن محاولة إبطال JWTs - وهو مطلب شائع من وجهة نظر الأمان - إما من خلال نظام القائمة السوداء أو نظام الإصدار من المحتمل أن يكسر شرط انعدام الجنسية. أقل من القائمة السوداء ، لكن الخادم لا يزال يخزن بيانات حالة / جلسة العميل. تطبق القائمة السوداء أيضًا عكس التصميم الأمني ​​المثالي - باستخدام القائمة البيضاء بدلاً من القائمة السوداء.

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

ثم نترك سؤالًا عن مدى أهمية الالتزام الصارم بقيود REST ، وهل يمكن أن يكون هناك بعض المرونة عندما يتعلق الأمر بالمصادقة؟

إذا نظرنا إلى كيفية استخدام الشركات الشائعة لـ REST في خدماتها على الويب ، فغالبًا ما نشهد انتهاكًا للتوافق الصارم عديمي الجنسية. عادةً ما تستخدم خدمات الويب الشائعة مفاتيح API أو ملفات تعريف الارتباط أو الرموز المخزنة في قاعدة البيانات أو أي شكل آخر من أشكال معرف المصادقة ذات الحالة ؛ عادةً لأسباب جيدة أيضًا - الإلغاء ، تتبع الاستخدام ، أغراض التحليلات المختلفة ، تحديد الأسعار ، إلخ.

لقد تحول قرار المطابقة إلى REST أو حتى كيف تتوافق مع REST إلى حجة دينية بين المطورين.

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

REST هو تصميم برمجي على نطاق عقود: كل التفاصيل تهدف إلى تعزيز عمر البرنامج والتطور المستقل. تعارض العديد من القيود بشكل مباشر الكفاءة على المدى القصير. - روي فيلدينج

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

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

قائمة بذاتها مقابل المشار إليه: السرعة

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

أولاً ، من شأن تخزين جميع بيانات المستخدم في JWT أن يفتح لك مجموعة من المشكلات الأخرى ، بما في ذلك ...

  • مزيد من المخاوف الأمنية إذا تم سرقة JWT.
  • مشاكل حجم تخزين البيانات
  • مشكلات الثبات والتوافر (المزيد من المشكلات الهندسية)

ثانياً ، تقوم مكالمات قاعدة البيانات هذه بإضافة مايكروثانية إلى الطلب.

هناك حجة تتعلق بالموثوقية (فائدة انعدام الجنسية) ، لكن الجهوزية أقل إثارة للقلق مما كانت عليه قبل سنوات.

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

قائمة بذاتها مقابل المشار إليه: إبطال

تكمن مشكلة أمنية مشتركة في أي نظام مصادقة في إبطال جلسات العمل النشطة ، إذا دعت الحاجة إلى ذلك.

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

لسوء الحظ ، لا يعد إبطال مصادقة قائمة بذاتها بهذه البساطة.

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

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

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

قائمة بذاتها مقابل المشار إليها: التحليلات والتتبع

من المتطلبات الشائعة لمعظم أنظمة المصادقة أن تكون قادرًا على تتبع عادات المستخدم ...

  • كم مرة يقوم المستخدم بتسجيل الدخول؟
  • كم عدد المستخدمين الذين قاموا بتسجيل الدخول في أوقات معينة؟
  • كم يبلغ متوسط ​​مدة جلسة المستخدم؟
  • كم عدد الطلبات التي يمكن / لديها جلسة قدمت في إطار زمني معين؟

الخ

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

الاستنتاج: فوز بسيط هنا للمصادقة المستندة إلى المرجع.

قائمة بذاتها مقابل المشار إليها: المحمول / الجهاز ودية

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

مع JWT قائمة بذاتها ، وهذا هو أصعب بكثير القيام به.

الاستنتاج: فوز بسيط هنا للمصادقة المستندة إلى المرجع.

قائمة بذاتها مقابل المشار إليه: الاستنتاج النهائي

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

متطلبات REST الخاصة بانعدام الجنسية في سياق المصادقة ليست واضحة دائمًا - هل لا يزال استخدام سر JWT الخاص بالمستخدم مؤهلاً لتفاعل عديم الحالة أو هل يعتبر السر المخزن أيضًا "سياق مخزّن؟" وإذا لم يكن الأمر كذلك ، فأين لا يوجد خط عديم الجنسية بين سر تطبيق وسر مخزنة في قاعدة بيانات؟

عند التركيز على فوائد انعدام الجنسية (الرؤية والموثوقية والسرعة والتدرجية) ، يبدو أن قابلية معالجة الموارد أكثر أهمية.

استنتاجات لمصادقة المستخدم

لقد مررنا بالكثير! وهناك دائمًا ما يحدث في مساحة المصادقة (توقيعات رأس HTTP ، OpenId ، إلخ).

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

وبالتالي ، ملخصي للتوصيات الشخصية لمعظم التطبيقات:

  • التمسك استراتيجية تستند إلى مرجع لمصادقة المستخدم. أصبح من الأسهل التعامل معها ، وباستخدام حلول تخزين البيانات الحالية ، لم تعد قابلية التوسع مشكلة كبيرة بالنسبة لمعظم التطبيقات بعد الآن. من الجيد استخدام JWT للمصادقة الذاتية ، لكن يجب أن يكون لديك سبب وجيه لاستخدامه (ربما الدخول الموحد).
  • أصبحت حالات انعدام الجنسية (أحد قيود REST) ​​للمصادقة مقابل القابلية للمعالجة مخاوف مختلطة ، وتحولت REST إلى أكثر من كلمة طنانة تشير عادةً إلى تطبيق واحد وجزئي فقط لنمط REST. دائما النظر في الأسباب الكامنة وراء استخدام نمط أو عنصر من نمط.
  • إذا كان لديك بنية خدمة معقدة ، فقد تحتاج إلى استخدام localStorage. سيستغرق إعداد العمل أكثر قليلاً ، ولكن سيكون لديك آلام أقل نمواً. ملفات تعريف الارتباط أسهل قليلاً في الإعداد ، ولكن يمكن أن تقدم آلامًا متنامية على الطريق إذا احتجت إلى توسيع نطاق خدماتك بشكل أفقي.
  • يمكن أن يسبب استخدام ملفات تعريف الارتباط مشكلات CSRF ويجب وضع استراتيجية لمنع ذلك. يُعد XSS تهديدًا محتملًا بغض النظر عما إذا كنت تستخدم - ملفات تعريف الارتباط أو التخزين المحلي. ومع ذلك ، يجب معالجة كل من XSS و CSRF بغض النظر عن آلية التخزين لديك.
  • تأكد من فرض HTTPS للمساعدة في منع هجمات MIM.

شكر! يرجى التعليق أدناه ، اتبعني (Nick Jagodzinski) ، أو أعطِ بعضًا إذا وجدت هذه المقالات مفيدة. أيضًا ، أرسل تعليقًا إذا كان لديك أي أسئلة أو أشياء فاتنيها أو أفكار أو آراء!