Learn-json-web-tokens: معلومات خطيرة وغير صحيحة في README

البعض مدروس جيدًا وعبر بوضوح عن مخاوفه التي تعطيني بالتأكيد بعض الطعام للتفكير كشخص بدأ للتو في النظر إلى الريبو. كنت أبحث عن مثال سريع لإنشاء مثال عمل مصادقة JWT باستخدام Node. اهتمامي في JWT هو توفير نهج حديث لأفضل الممارسات لإدارة الجلسات لكل من REST API و js client مع تجنب مشكلات CORS. أنا مهتم بالأمان بشكل معتدل ولكن هذا ليس دافعي لاستخدام JWT على الرغم من أنني أقدر الدور الذي يمكن أن تلعبه الرموز المميزة في مناهج آمنة أكثر شمولاً مثل OAUTH. نظرًا لأنني قرأت من خلال هذا الريبو لأول مرة ، فقد صدمتني لأنها تضمنت الكثير من الملاحظات التي جمعها المؤلف أثناء قيامهم ببناء معرفتهم باستخدام JWT وما إلى ذلك. على الرغم من أنني أمتلك القليل من الاستثمار في هذا الريبو ، إلا أنني أميل إلى الاعتقاد بوجود مكان لمنصة محددة ، مثال عمل بسيط لتسجيل الدخول / تسجيل الخروج مع بعض الأدوات والمراجع الداعمة. كأساس للمهارات على متن الطائرة وكمبتدئ ، أعتقد أن أهداف هذا الريبو جيدة ولكن ربما يحتاج README إلى إعادة كتابة جادة وإعادة التركيز على أهداف هذا النوع من استخدام JWTs. سأكون سعيدًا لمحاولة اقتراح شيء .. joepie91 - من الواضح أن لديك تعهدًا جيدًا بالقضايا .. هل يمكنك تقديم بعض الأفكار حول الفوائد الحقيقية لهذا النوع من استخدام JWT؟

مرحبًا @ joepie91 ، نحن _stoked_ الذي وجدته وقم بقراءة ملاحظاتنا على JWT!
شكرًا لك على الوقت الذي أمضيته في فتح هذه المشكلة لإثارة مخاوفك. ❤️
سنكون سعداء إذا قمت بتقسيم كل مخاوفك إلى مشكلة _ منفصلة_ أو على الأقل ترقيمها لتسهيل مناقشتها.

نحن _ مع الاحترام_ لا نتفق على أن محتوى هذه الملاحظات "_ خطير_".

_ ملفات تعريف الارتباط _> في توجيه الاتحاد الأوروبي بشأن الخصوصية الإلكترونية Recital 25 ، cookies _ مذكور بشكل صريح _ 5 مرات:

ارى:
https://ar.wikipedia.org/wiki/Directive_on_Privacy_and_Electronic_Communications#Cookies
أو:
http://eur-lex.europa.eu/LexUriServ/LexUriServ.do؟uri=CELEX : 32002L0058: EN: HTML

منحت ، العديد من المواقع / التطبيقات (_ التي لا تستخدم ملفات تعريف ارتباط تتبع جهة خارجية_) تندرج ضمن ‘strictly necessary for the delivery of a service requested by the user’ ... وهذا هو سبب _ استخدامنا_ ملفات تعريف الارتباط في تطبيقات الويب _المحسّنة تدريجيًا_. انظر: https://github.com/dwyl/hapi-auth-jwt2#want -to-sendstore-your-jwt-in-a-cookie

تخزين JWT في _localStorage _> بينما _ نوافق على أن تخزين بيانات الجلسة / الرموز المميزة في localStorage يعني أن JavaScript مطلوب _ (_ لا نحب هذا أيضًا ، نحن نفضل التحسين التدريجي ، كان من المفترض أن نلاحظ خيارًا بديلًا ..._). localStorage هو كيفية إنشاء _ BaaS عادةً لا تقبل ملفات تعريف الارتباط ... هل تقترح أن نصف مليون مطور يستخدمون Google Firebase يفعلها خطأ_"...؟ (_هذا سيكون مناقشة رائعة - منفصلة - ...! _)

الجلسات عديمة الحالة _ exp (_وقت انتهاء الصلاحية_) ، ولكننا _ اختر / نفضل _ معرف جلسة ( jti ) _inside_ و JWT الذي يحصل على البحث عنها في مخزن رديس _after_ تم التحقق من JWT. هذا يعني أنه يمكننا _invalidate _ جلسة عندما يقوم شخص بتسجيل الخروج أو إذا سُرق جهازه ويحتاج إلى إلغاء جلسة نشطة.

نعم ، الغرض _ الأساسي _ من JWTs هو الحصول على pass claims between parties in web application environment ، وهذا _ بالضبط _ ما نستخدمه من أجله.

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

الخلاصة: لنقم بتحديث الملف التمهيدي إلى _توضيح_ الأشياء. 👍

بدلاً من تقسيم القضايا المثارة إلى مجموعة من القضايا كما اقترحت من قبل nelsonic ، أميل إلى الموافقة على أن نية وأهداف التنفيذ يجب توضيحها في نطاق README. لا أقرأ قضايا @ joepie91 على أنها انتقاد لاستخدام JWTs في سياق تطبيقات الويب على هذا النحو ، أو دعم ملفات تعريف الارتباط باعتبارها متفوقة ؛ بدلاً من ذلك ، أعتبر أن النقد هو أن وصف نظرية الحرب العادلة يتم تقديمه بطريقة تغالي أو تحرف سبب اختيار JWT.
تم التعبير عن نفس القلق أيضًا في رقم 55 (وضح أن JWT ليس تشفيرًا ...)

بالنسبة لي ، يكفي أن أكون قادرًا على تشغيل Firebase والخدمات الخاصة بي باستخدام مطالبة مشتركة تنتهي صلاحيتها. قد أقوم بتوسيعه ليشمل بعض الحالات في بعض الحالات وليس في حالات أخرى وما زلت أفضل طريقة استخدام ملفات تعريف الارتباط أو أساليب مصادقة http للتحكم في الوصول الأقدم.
يعجبني أنه يمكنني استخدام رموز JWT كجزء من نهج أكثر تعقيدًا ولكن ما زلت أوافق على أن التركيز على فوائد README يجب أن يكون على المشكلات التي نتطلع إلى حلها معهم بدلاً من الانحراف إلى أرضية أقل صلابة. ربما يمكن تحويل الكثير من المواد المرجعية في README إلى ملاحظات أو حتى إلى Wiki كمواد مناقشة؟

لا أعرف ما إذا كنت سأقول بالضرورة إن برنامج README خطير - يبدو قويًا بعض الشيء

ملفات تعريف الارتباط> في توجيه الاتحاد الأوروبي بشأن الخصوصية الإلكترونية Recital 25 ، تم ذكر ملفات تعريف الارتباط صراحةً 5 مرات:

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

localStorage هو كيف يتم إنشاء جميع التطبيقات التي تم إنشاؤها باستخدام "Backend-as-a-Service" ، لأن BaaS لا تقبل ملفات تعريف الارتباط عادةً ...

هذا غير ذي صلة ، ومشكلة تلك الخدمات. هذا لا يبرر استخدام JWT للجلسات في التطبيق الخاص بك.

هل تقترح أن نصف مليون مطور يستخدمون Google Firebase يفعلون ذلك "خطأ" ...؟

بصرف النظر عن حقيقة أن Firebase مصمم بشكل سيئ للغاية ، فهذا نداء للسلطة وليس له مكان في مناقشة فنية. لست مهتمًا بمناقشة قرارات شركة معينة لمنتج معين ؛ أنا مهتم فقط بمناقشة مزايا وعيوب نهج معين.

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

في هذه المرحلة ، لم تعد هناك فائدة فعلية لاستخدام JWT بعد الآن. لماذا لا تستخدم فقط express-session أو بعض حلول الجلسات الأخرى التي تم اختبارها من قبل المعركة والتي تمت مراجعتها من قبل الأقران والتي تتناسب مع مجموعتك؟ التوصية الخاصة بـ JWT لا معنى لها هنا ، لأن الأشخاص _لا يجب أن يطرحوا إدارة الجلسة الخاصة بهم في المقام الأول_.

ناهيك عن أنه يجب التعامل مع انتهاء صلاحية الجلسة _server-side_ ، وبالتالي فإن exp في JWT الخاص بك عديم الفائدة بشكل أساسي.

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

لا تتعلق JWTs بـ "بيئات تطبيقات الويب" على الإطلاق.

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

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

نحن نختلف بكل احترام على أن محتوى هذه الملاحظات "خطير".

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

@ pscott-au: joepie91 - من الواضح أن لديك تعهدًا جيدًا بالمسائل .. هل يمكنك تقديم بعض الأفكار حول الفوائد الحقيقية لهذا النوع من استخدام تطبيقات JWT؟

لا توجد فوائد في استخدام JWT لتطبيقات الويب القياسية ، إلا إذا كنت تعمل على مقياس Reddit. بعض الأمثلة الشائعة للحالات التي تكون فيها JWTs مفيدة:

• آليات تسجيل الدخول الأحادي (حيث يتم استخدام JWT كرمز مصادقة لمرة واحدة يتبادلها المستخدم لجلسة في التطبيق الهدف) ،
• رموز الوصول المؤقتة للصور الخاصة حيث من المفترض أن تكون عناوين URL قابلة للمشاركة ،
• في الأساس أي سيناريو يحتاج فيه نظامان يثقان ببعضهما البعض إلى تبادل القليل من البيانات من خلال طرف غير موثوق به ، دون الاتصال المباشر مع بعضهما البعض أو مشاركة الواجهة الخلفية.

بالنسبة لجلسات تطبيق الويب القياسية ، يجب عليك فقط استخدام تنفيذ جلسة تم اختباره جيدًا لأي مكدس تستخدمه (على سبيل المثال ، express-session عند استخدام Express).

إنه لأمر رائع إجراء هذه المناقشة لأنها تتحدى حقًا بعضًا من تجربتي. ربما يكون هناك سياق لاهتمامي الشخصي باستخدام JWT (بصرف النظر عن حقيقة أنني استخدم Firebase والتي سأكون مهتمًا بتعلم المشكلات الهندسية الضعيفة التي سأبحث فيها). عند إنشاء تطبيقات الهاتف المحمول / SPA وخاصة عند استخدام الخدمات التي يتم الحصول عليها من خوادم / مجالات متعددة ، أجد أنني غالبًا ما أحتاج إلى إمكانية تسجيل دخول واحدة يبدو أن JWT تناسبها بشكل جيد. ما أفهمه هو أن استخدام ملفات تعريف الارتباط للجلسة تطور على مدار فترة تم فيها تشديد الأمان في المتصفح ومساحة JS وتطور إدخال CORS للتعامل مع الاستثناءات من هذا الأمر مما تركنا مع حل مبتكر إلى حد ما تقوم JWT بمعالجته بطريقة ما .
لسنوات عديدة ، منحت مناهج جلسات ملفات تعريف الارتباط بالتأكيد أسلوبًا أفضل بكثير من مصادقة http الأساسية والملخصة الأصلية وهناك عدة مرات يمكنني فيها استخدام حل إدارة جلسة ملفات تعريف الارتباط لتطبيق قائم على الويب.
لكن .. أجد أن معظم التطبيقات التي أقوم ببنائها الآن هي تطبيقات محمولة أو SPA وتستخدم بشكل مكثف REST APIS. أحب أن أكون قادرًا على الاختبار بسهولة من خلال طلبات curl البسيطة دون تجميع عناصر معالجة ملفات تعريف الارتباط أو التعامل مع طلبات متعددة لإنشاء الجلسة. لذلك أجد أن التنفيذ السريع لواجهات برمجة التطبيقات يجعل الأشياء تعمل فقط عندما أستخدم JWT. في حدسي ، يبدو من الأنسب استخدام JWT لجلسات تشغيل طويلة من ملفات تعريف الارتباط على الرغم من أنني سأفكر في هذا الأمر لأنه قد يكون كسلًا أكثر من الحدس الجيد. يمكنني تمديد الأمان على غرار OAUTH إذا لزم الأمر ، وأريد تأمين الأشياء بشكل كامل ولكن في كثير من الأحيان لا تكون الجلسة شيئًا أعتبره بحاجة إلى هذا المستوى من الأمان. الشيء المهم بالنسبة لي هو المرونة التي يوفرها نهج المصادقة المستند إلى JWT فيما يتعلق بالتغييرات المعمارية في المستقبل. لقد وجدت أنه تم إعادة هيكلة الكود الأقدم لتوفير مصادقة JWT كخيار وهذا قدم القليل من التعقيد في الصيانة بشكل مدهش ولكن في معظم الحالات يبسط التطوير المستقبلي ولا أرى أي جزء منه على أنه أدنى مستوى بطبيعته من جلسات ملفات تعريف الارتباط.
هناك في الواقع مزايا لاستخدام ميزات مهلة JWT ، خاصة على الأجهزة المحمولة وبعض المكتبات الداعمة تستفيد من ذلك. يمكنك على سبيل المثال أن يكون لديك تطبيق يقوم بتسجيل خروج المستخدم أو تركه مسجلاً للدخول بناءً على هذه المهلة عندما يكون الجهاز غير متصل بالشبكة.
بالنسبة لي ، لا أرى كثيرًا أي جدال مقنع حول مزايا مقياس JWT على ملفات تعريف ارتباط الجلسة.
أرى أشخاصًا يقترحون أنه يمكن استخدام JWT كملف تعريف ارتباط للجلسة والذي يضرني أكثر مما ينفع لأن ملفات تعريف الارتباط لها فترة المهلة الخاصة بها (لا تتم إدارتها بالكامل من جانب الخادم) ومن المحتمل أن يؤدي الجمع بينها إلى إرباك.
توفر العديد من أطر عمل JS الحديثة دعمًا أكبر لـ JWT مقارنة بملفات تعريف الارتباط مما يشير إلى أن حل مراجعة الأقران الذي تم اختباره للمكدس قد يكون في الواقع يميل نحو JWT للعديد من التطبيقات. في حين أن شعبية JWT لخدمات الويب ليست حجة تقنية ، فإن رفض هذا باعتباره غير ذي صلة لأنها جميعًا غير صحيح بنفس القدر. Express ليس عنصرًا أساسيًا في المكدس الذي تستخدمه مجموعة dwyl كما يمكنني أن أقول على أفضل وجه ، لذلك لا يوجد سبب للتوافق معه.
آمل أن يكون هناك جزء من نيتي يمكنك الموافقة عليه لأنني لا أزال قلقًا ولكني غير مقتنع تمامًا بحججك.
سأوافق على أن برنامج README يحتاج إلى إصلاح جاد وأن هناك سطورًا تتبعها والتي من الأفضل إزالتها أو إعادتها إلى نص مناقشة الخلفية وليس في README الرئيسي.

(بصرف النظر عن حقيقة أنني أستفيد من Firebase والتي سأكون مهتمًا بتعلم المشكلات الهندسية الضعيفة التي سأبحث فيها)

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

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

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

CORS هي قضية منفصلة ، ولا تتعلق بهذا حقًا.

لكن .. أجد أن معظم التطبيقات التي أقوم ببنائها الآن هي تطبيقات محمولة أو SPA وتستخدم بشكل مكثف REST APIS. أحب أن أكون قادرًا على الاختبار بسهولة من خلال طلبات curl البسيطة دون تجميع عناصر معالجة ملفات تعريف الارتباط أو التعامل مع طلبات متعددة لإنشاء الجلسة. لذلك أجد أن التنفيذ السريع لواجهات برمجة التطبيقات يجعل الأشياء تعمل فقط عندما أستخدم JWT.

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

بصرف النظر عن ذلك ، يدعم cURL ملفات تعريف الارتباط بشكل جيد ، وهناك العديد من عملاء اختبار API الأفضل مثل httpie أو حتى موجه http .

يمكنني تمديد الأمان على غرار OAUTH إذا لزم الأمر ، وأريد تأمين الأشياء بشكل كامل ولكن في كثير من الأحيان لا تكون الجلسة شيئًا أعتبره بحاجة إلى هذا المستوى من الأمان.

تعتبر الجلسة من أهم جوانب تطبيقك. إذا لم يكن التطبيق آمنًا بشكل كافٍ ، فسيكون تطبيقك معطلاً بشكل أساسي وهشاشة تمامًا. لهذا السبب تخزين JWTs في LocalStorage هو فكرة سيئة.

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

لم يتم تقديم أي مرونة هنا سيحتاجها 99.99٪ من المطورين على الإطلاق ، وقد أبرزت بالفعل بعض المشكلات التي يقدمها ، مثل البيانات القديمة وعدم القدرة على إبطال الرموز المميزة.

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

هذا ليس فريدًا بالنسبة لـ JWT ؛ يمكنك القيام بذلك مع جلسات من جانب الخادم على ما يرام. في الواقع ، لا يمكن إبطال JWTs دون إدخال بنية ذات حالة (معقدة) ، لذلك تربح الجلسات هنا في الواقع.

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

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

توفر العديد من أطر عمل JS الحديثة دعمًا أكبر لـ JWT مقارنة بملفات تعريف الارتباط مما يشير إلى أن حل مراجعة الأقران الذي تم اختباره للمكدس قد يكون في الواقع يميل نحو JWT للعديد من التطبيقات.

لا يزال يتعين علي رؤية إطار عمل لا يدعم ملفات تعريف ارتباط الجلسة.

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

هذه هي مشكلتهم. كان Express مجرد مثال واحد ، حيث توجد تطبيقات تم اختبارها جيدًا لكل إطار عمل شائع الاستخدام.

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

@ joepie91 لا أستطيع أن أخبرك كيف _delighted_ أنني وجدت الريبو / الملاحظات الخاصة بنا واستثمرت وقتك لقراءتها وإعطائنا ملاحظات! على محمل الجد ، إذا قابلتك شخصيًا في أي وقت ، فسأقدم لك _بليت _ ما تحب أن تشربه! 🍺

إذا جعلتك مساهمًا في هذا الريبو ، فهل ستراجع طلب السحب الخاص بي لتحسينه؟ 📝

وأيضًا ، AshleyPinner ، alfiepates ، @ sunny-g كيف تعثرت أنت يا سادة في هذه المناقشة الخاصة؟ هل تمت مشاركة المشكلة على Redit / Hackernews؟ (_ أنا أشعر بالفضول فقط كيف يجد الناس منشوراتنا ..._)

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

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

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

nelsonic بالنظر إلى 4744cd1bb8991bc4057c749f86007fcecac19d1d ، يبدو أن صياغة أوضح بكثير. و رأس لا يبدو لتعكس التغيرات، وإن كان.

@ pscott-au: في تطبيقات SPA وتطبيقات الأجهزة المحمولة الحديثة.

هذا متعامد مع اختيارك لآلية الجلسة. ناهيك عن أن معظم الأشياء التي تعتبر SPA اليوم ، لا ينبغي أن تكون كذلك. استخدام SPA لموقع ويب (على عكس تطبيق الويب) يكسر الويب.

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

مثل؟

التصور الذي يخلقه ملصق المشكلة هو أن JWT عبارة عن تقنية غير ناضجة غير موثوقة تم اختراقها معًا وغير مناسبة للتطبيقات الحديثة

لا ، ليس كذلك. JWT كتقنية ليست فظيعة (حتى لو كانت هناك _ بعض القرارات المشكوك فيها في المواصفات) - الجلسات ليست فقط الغرض المقصود منها ، وهي غير مناسبة لحالة الاستخدام هذه.

أنا لا أقول أن الأداة سيئة ، بل أقول إنك تستخدمها بشكل خاطئ.

وربما يكون هذا التأكيد أكثر خطورة من

ما هو سبب ذلك؟

لقد وجدت مقالة OATH هذه مفيدة.

معالجتها نقطة بنقطة:

• عديم الجنسية وقابل للتطوير ومنفصل: لقد أقرت بالفعل أن هذه فائدة نظرية ، لكنها في الواقع ميزة لا يحتاجها أحد تقريبًا. يجب أن تضع في اعتبارك أيضًا أن Auth0 لها مصلحة مكتسبة هنا ، وهي مصلحة _ لا _ تفيدك كمطور: _ "يمكن لخدمات الجهات الخارجية مثل Auth0 التعامل مع إصدار الرموز المميزة ، وبعد ذلك يحتاج الخادم فقط إلى التحقق من صحة الرمز المميز. "_ بالمناسبة ، تعد الاستعانة بمصادر خارجية للمصادقة الخاصة بك فكرة _ رهيبة_.
• عبر المجال و CORS: هراء كامل ومطلق. يتحدث هذا عن طريقة التخزين ، وهي منفصلة تمامًا عما إذا كان الرمز المميز يحتوي على بيانات الجلسة أم لا. يمكنك إرسال معرف جلسة يدويًا ، أو يمكنك تخزين JWT في ملف تعريف ارتباط. لا علاقة له بـ JWT مقابل الجلسات - مما يُظهر أيضًا تحيز / جهل كاتب المقالة ، حيث إن مقارنة "ملفات تعريف الارتباط مقابل الرموز المميزة" _ ليس من المنطقي أن تبدأ بـ_. كما أنه يتجاهل تمامًا مشكلة الأمان هذه .
• تخزين البيانات في JWT: ليست ميزة. الأمر نفسه ينطبق على الجلسات. وبالمناسبة ، ملفات تعريف الارتباط.
• الأداء: هذا مجرد تكرار لنقطة "عديمة الحالة" ، في الغالب - بصرف النظر عن حقيقة أنه ليس من الواضح على الإطلاق ما إذا كان التحقق من التشفير يمكنه بالضرورة التغلب على شيء مثل Redis في أداء معالجة بيانات الجلسة (مقارنتها بنظام RDBMS غير واقعية) ، إنه أيضًا تحسين أداء غير مهم تمامًا لكل تطبيق ويب تقريبًا. هذا يسمى "التحسين السابق لأوانه" ، ويوصى به على نطاق واسع لسبب وجيه للغاية.
• جاهز للجوال: هراء. إذا كانت مكتبة HTTP الخاصة بك لا تدعم ملفات تعريف الارتباط ، فابحث عن مكتبة HTTP أفضل. يتم دعم ملفات تعريف الارتباط بشكل جيد ، إنها مجرد رؤوس HTTP.

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

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

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

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

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

[...] عندما ذكرت CORS سابقًا ربما كان من الأفضل أن نكون واضحين في الإشارة إلى صعوبات استخدام نطاقات متعددة مع ملفات تعريف الارتباط. بالتأكيد ، يمكنك تعيين مجالات أحرف البدل ، ولكن إذا كانت مختلفة بشكل كافٍ ، فستصبح ملفات تعريف ارتباط الجلسة التقليدية غير عملية بسرعة.

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

لكن استخدام JWT سيصبح أكثر بروزًا فقط كنقطة انطلاق لجلسات المصادقة

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

لذلك لرفض هذا لأننا استخدمنا ملفات تعريف الارتباط للجلسة لفترة طويلة

أنا لم أقل شيئا من هذا القبيل. لقد قدمت العديد من الأسباب الواضحة جدًا لسبب أن JWT _ موضوعيا أدنى_ من أجل إدارة الجلسة.

ويتعرفون على JWT ويستخدمونه فقط عندما يجدون أنهم غير قادرين على مشاركة ملفات تعريف الارتباط عبر المجالات

في هذه الحالة ، مشكلة أمنية . ملفات تعريف الارتباط _ ليست اختيارية_.

أو تحتاج إلى الوصول إلى واجهة برمجة تطبيقات تابعة لجهة خارجية

لا علاقة لها بالجلسات.

أو تحتاج إلى أن تكون قادرًا على تحديد انتهاء الصلاحية دون التحقق من الخادم

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

أو تشكك في تخزين بيانات اعتماد تسجيل دخول المستخدم على الجهاز المحمول وما إلى ذلك وما إلى ذلك.

بسكويت. منتهي.

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

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

هذا ما يسمى "الضجيج" ، وهو ضار للغاية.

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

لا تحتاج التطبيقات غير المتصلة بالإنترنت إلى المصادقة _على الإطلاق_. لا يوجد ، بحكم التعريف ، تفاعل مع الأنظمة الأخرى.

مصادقة بيانات الاعتماد عبر المجال: مهم إذا قمت بتقسيم تطبيقك إلى خدمات مصغرة باستخدام خوادم متعددة

صيح. لكن في هذه الحالة ، لا تستخدم JWT _ كآلية الجلسة الخاصة بك_ ، بل تستخدمه كرمز رمزي للاستخدام الفردي يمكن تبادله _ لجلسة. هناك فرق كبير بين الاثنين والمفاضلات التي يقدمها.

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

يمكنك الاستمرار في رفض فائدة JWT

مرة أخرى ، أنا لا أفعل أي شيء من هذا القبيل. هذه هي كلماتك بالكامل.

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

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

الاعتماد على ملف تعريف الارتباط لإدارة جلسة تسجيل دخول iOS ليس هو الحل الأفضل افتراضيًا.

لماذا ا؟

يمكن إساءة استخدام ملفات تعريف الارتباط

هذا بيان فارغ. _كيف يساء استخدامها؟ وكيف لا ينطبق هذا على القيم المخزنة في التخزين المحلي؟ وما علاقة هذا حتى بـ JWT _at all_ نظرًا لأن "ملفات تعريف الارتباط" هي طريقة تخزين وليست آلية جلسة؟ مقارنة "JWT مقابل ملفات تعريف الارتباط" هي مقارنة التفاح والبرتقال ، فهما ليسا نفس فئة الأشياء!

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

أنالست. لدي استثناءات محددة بوضوح حيث JWT _ هو الحل الصحيح. لقد أشرت أيضًا - بوضوح شديد - إلى أن JWT غير مناسبة كآلية جلسة للأغراض العامة . التوقف عن وضع الكلمات في فمي.

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

لأنه لا يوجد سبب يمنعك من استخدام _b كل من _ JWT والجلسات ، لأغراض مختلفة. إن محاولة تكديس كل شيء في آلية واحدة من أجل ذلك أمر مضلل تمامًا. استخدام الأداة المناسبة - "لا يتطلب إنشاء ملفات تعريف ارتباط جديدة" هو مقياس تعسفي تمامًا وواقعي ، وليس الفائدة التي تدل عليها.

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

مرة أخرى. لا. انا قلت. توقف عن وضع الكلمات في فمي.

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

إنها ميزة تتطلب جلسات ذات طابع معماري من نوع ما. أنا لا أجادل في أن هذا يتم توفيره من خلال ملفات تعريف الارتباط للجلسة - أنا أزعم أنه _ من الممكن _ باستخدام الرموز المميزة عديمة الحالة.

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

مرة أخرى ، ليس ما قلته.

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

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

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

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

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

مرة أخرى ، ليس ما قلته.

JWT ليست هي الخطوة التالية لاستبدال جميع ملفات تعريف الارتباط للجلسة ولكنها ليست كذلك أمرًا فظيعًا (عند استخدامها لإدارة الجلسات) كما أشرت.

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

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

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

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

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

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

لا يوجد _is_ "مرونة أكبر". مرة أخرى ، إذا كنت تعتقد أنه يوجد ، اشرح كيف.

على أي حال - أنت أكثر بلاغة مني ومن الواضح أنك لا تتزعزع في وضعك

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

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

... وسيكون هذا مثالًا رائعًا لمثل هذه المغالطة.

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

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

إذا كنت تريد الاستمرار في الاعتقاد بأن نظرية الحرب العادلة هي الكأس المقدسة على الرغم من عدم وجود حجج فنية لدعم هذه الفكرة ، فهذا هو خيارك - لكنك لن تقنعني ما لم تبتكر _ حججًا تقنية فعلية_ ، وتستمر في تكرار نفس التأكيدات مرة أخرى. ومرة أخرى لن يساعد أي شخص.

لتلخيص نقاطي لأولئك الذين يتصفحون المناقشة بأكملها:

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

(بالمناسبة ، يستخدم Reddit الجلسات ذات الحالة).

أعتقد أن القصد من هذا الريبو هو تمهيد الطريق لتنفيذ SPA الهجين المحمول واستخدام JWT كبديل لجلسات ملفات تعريف الارتباط هو نهج شائع وشبه قياسي.
أحد العوامل الدافعة لذلك هو مشكلة ارتباط ملفات تعريف الارتباط بالمجال عندما يتطلب SPA في الواقع الوصول إلى الخدمات الصغيرة عبر مجالات متعددة على منصات مختلفة. JWT هو نهج أنيق لقيود ملفات تعريف الارتباط في هذا السياق. قد يكون استخدام نهج OAUTH أو OAUTH2 أكثر قوة من وجهة نظر الأمان ولكنه يقدم تعقيدًا قد لا يكون مطلوبًا للعديد من التطبيقات. جلسات حامل JWT التي لا تعتمد على التفاوض على رمز AUTH لا تعد إساءة استخدام لـ JWT ولكنها تطبيق لنهج أقل أمانًا من أجل اكتساب البساطة والتطبيقات التي يمكن الاستفادة منها أكثر من التنفيذ السريع أكثر من الأمان الإضافي الذي يوفره أكثر نهج قوي. في نفس الوقت الذي يتم فيه تبسيط التنفيذ السريع ، فإنه يوفر مسار انتقال أوضح إلى الرموز المميزة للاستخدام الفردي ثم الأساليب الأخرى.
بعض ردود الفعل العنيفة والنقد اللاذع ضد استخدام رؤوس الرموز المميزة لـ JWT Bearer كبديل لملفات تعريف الارتباط للجلسة تستند بالفعل إلى بعض الأشخاص الذين يقدمونها كتطور أو تحسين على ملفات تعريف الارتباط على نطاق أوسع وهو ما أوافق على أنه ليس هو الحال. أطلب منك النظر في حالات الاستخدام الخاصة بي وكيف ستتعامل معها باستخدام ملفات تعريف الارتباط.
يجب أن يتم استخدام JWT لإدارة جلسة المصادقة بحذر ويجب توضيح أوجه القصور بشكل واضح ، ومع ذلك فإن رفضها على أنها دعاية غير مجدية تُستخدم دائمًا خارج السياق يعد أمرًا مضللًا وغير صحيح.
يعني استخدام JWT أنك لست بحاجة إلى تحديث ملفات تعريف الارتباط في كل مرة يتصل فيها العميل بالخادم. يمكن ضمان الثقة المعقولة دون التحقق من قاعدة البيانات على الرغم من أنه من السهل تمديد هذا الفحص كما هو الحال مع استخدام ملفات تعريف الارتباط للجلسة.
يعني استخدام JWT أن العملاء الذين تم حظر ملفات تعريف الارتباط لديهم لن يضطروا إلى الرجوع إلى استخدام متغيرات النشر المخفية وما إلى ذلك كردم.
يتيح استخدام JWT عبر خدمات متعددة خدمة لا تتطلب مصادقة ولكنها تريد بعض المؤشرات على صلاحية حقل بيانات بسيط مثل uid الذي يمكن تغليفه في JWT وتمريره.
نهج JWT يصلح لمقاربات OAUTH الأكثر تعقيدًا.
يمكن إجراء طلبات JWT REST دون نشر بيانات الاعتماد أو طلب ملف تعريف ارتباط قبل الوصول إلى الخدمة التي يمكن أن تبسط تنفيذ REST / SPA.
لا يختلف استخدام رأس الحامل أو رأس ملف تعريف الارتباط بشكل كبير عندما يتعلق الأمر بالأمان (باستثناء قيود المجال التي قد تكون غير مرغوب فيها بشكل صحيح. (ملاحظة: أنا لا أضع كلمات في فمك ولكني أحاول تفسير ما تلمح إليه بقول ذلك الأمن أسوأ)
عندما تكون فترات الغياب الطويلة شائعة / متوقعة كما هو الحال مع تطبيقات الهاتف المحمول ، فقد تكون ملفات تعريف الارتباط أقل استحسانًا من نهج JWT. يمكن أن يؤدي وجود مسار أوضح للفحص الذاتي لبيانات الاعتماد إلى تسهيل السلوك دون تسجيل الوصول مع الخادم.
إذا قبلت أن هناك حالات استخدام للجلسات التي قد يكون لها فترات طويلة في وضع عدم الاتصال ، فلن تكون الجلسات بالضرورة ذات حالة.
إذا كنت قادرًا على قبول أن الجلسات يمكن أن توجد بنجاح مع حالات متعددة من منظور العميل والخادم ، فربما يمكنك الاقتراب من حالات الاستخدام التي تتضمن فترات طويلة من عدم الاتصال بالخادم (على سبيل المثال ، جمع بيانات المستخدم لتحديث المجموعة عند إعادة الاتصال). هناك حالات يمكن فيها للعميل العمل بشكل أكثر فاعلية مع العلم أن الجلسة قد انتهت وأن التحديث مطلوب دون إدارة طبقة أخرى من البيانات. يمكن أيضًا أن تكون القدرة على استخدام JWT كتحقق من صحة الجلسة حتى بعد تغيير كلمة المرور وما إلى ذلك مفيدة في بعض الحالات للسماح بتمرير البيانات إلى طبقة منطق الأعمال وتحديد كيفية قبول الطلب.
أنت تخبرني باستمرار أن ملفات تعريف الارتباط آمنة والتي أفترض أنها تشير إلى التنفيذ في المتصفحات وما إلى ذلك - خارج المستعرض أخفق في معرفة سبب كونها أكثر أمانًا بطبيعتها - ربما يمكنك توضيح ذلك؟
في تطبيقات SPA / Hybrid ، لا يكون الاعتماد على ملفات تعريف الارتباط هو موضع البداية الوحيد بالضرورة - فالاعتماد على معالجة ملفات تعريف الارتباط بواسطة المتصفح لا يجعلك أقرب إلى المحتوى الأصلي ولكنه يقدم اعتمادًا على UIWebView أو أي شيء آخر ، ولا أظل واثقًا من أنه سيظل دائمًا. تتصرف كما أتوقع.
يمكن الاحتفاظ بالرموز في الذاكرة لحياة تنفيذ التطبيق دون الحاجة إلى الاستمرار - وهذا ليس في الحقيقة نفس الشيء مثل الاعتماد على سلامة ملفات تعريف الارتباط - هناك المزيد من التحكم الدقيق في iOS على الأقل على أذونات التخزين الموجودة خارج المتصفح وهذا يبدو لي أنه أكثر ملاءمة من الالتزام بأساليب تخزين المتصفح.
ملفات تعريف الارتباط اختيارية بالفعل - لا يوجد قانون ينص على أنه يجب عليك استخدام ملفات تعريف الارتباط فقط.
قد يكون فصل الجلسة عن الخادم أمرًا سيئًا في بعض الحالات ولكن ليس دائمًا - الأساليب الحديثة بما في ذلك استخدام JWT تقدم مخاوف جديدة ولكن أيضًا مرونة جديدة وهذه المرونة لا تشمل فقط الأساليب السيئة الأقل.

لتلخيص موقفي:
لا تتفوق ملفات تعريف ارتباط الجلسة دائمًا على استخدام JWT كجزء من حل جلسة المصادقة
تعد JWT مناسبة للجلسة إذا كنت على دراية بالمزايا ولديك سبب لعدم طلب إبطال مبسط.
ملفات تعريف الارتباط ليست الحل الوحيد.
المقياس الكبير ليس حالة الاستخدام الوحيدة للجلسة عديمة الحالة - استخدام رؤوس JWT للمصادقة عبر المجالات / الخدمات هو سبب وجيه لاستخدامها كبديل لملفات تعريف الارتباط للجلسة.

أطلب منك النظر في حالات الاستخدام الخاصة بي وكيف ستتعامل معها باستخدام ملفات تعريف الارتباط.

بالتأكيد.

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

هذا هو نفسه بالنسبة لملفات تعريف الارتباط للجلسة وملفات تعريف الارتباط التي تحتوي على JWT و _ و_ رموز JWT المميزة نفسها - ما عليك سوى "تحديثها" صراحةً إذا كانت على وشك الانتهاء. لا يوجد فرق هنا.

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

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

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

يتيح استخدام JWT عبر خدمات متعددة خدمة لا تتطلب مصادقة ولكنها تريد بعض المؤشرات على صلاحية حقل بيانات بسيط مثل uid الذي يمكن تغليفه في JWT وتمريره.

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

نهج JWT يصلح لمقاربات OAUTH الأكثر تعقيدًا.

يستخدم OAuth الرموز المميزة أحادية الاستخدام. إنه ليس بديلاً عن الجلسات. مرة أخرى ، انظر تحرير رسالتي السابقة.

يمكن إجراء طلبات JWT REST دون نشر بيانات الاعتماد أو طلب ملف تعريف ارتباط قبل الوصول إلى الخدمة التي يمكن أن تبسط تنفيذ REST / SPA.

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

لا يختلف استخدام الرأس الحامل أو رأس ملف تعريف الارتباط بشكل كبير عندما يتعلق الأمر بالأمان (باستثناء قيود المجال التي قد تكون غير مرغوب فيها بشكل صحيح.

لا أرى حجة هنا.

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

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

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

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

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

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

ما زلت لم أر أي أمثلة ملموسة لمثل هذه "المرونة".

إن استخدام JWT كجزء من حل الجلسة لا يتفوق دائمًا على ملفات تعريف الارتباط للجلسة

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

تعد JWT مناسبة للجلسة إذا كنت على دراية بالمزايا ولديك سبب لعدم طلب إبطال مبسط.

لا ، تعتبر رموز JWT هي _آخر منتجع _ عندما لا تتمكن من تلبية متطلبات ملفات تعريف الارتباط للجلسة.

ملفات تعريف الارتباط ليست الحل الوحيد.

صحيح من الناحية الفنية.

المقياس الكبير ليس حالة الاستخدام الوحيدة لجلسة عديمي الجنسية.

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

أسألك هذا - كيف يمكنني نشر تطبيق يستخدم 3 خدمات مختلفة (ربما على بنية أساسية مختلفة للحاويات وما إلى ذلك) ودمجها في التطبيق بالاعتماد على ملفات تعريف الارتباط للجلسة؟ إذا قمت بإعداد خدمة مصادقة وأرغب في فصلها عن خدمة أخرى ، فهل أفضل طريقة لتشغيل معالج جلسة ملف تعريف ارتباط مشترك؟ هل هذه حالة متطرفة؟
كيف تزودني ملفات تعريف الارتباط بقدر أكبر من الأمان والمرونة والامتثال للمعايير بدلاً من استخدام JWT طويل الأمد لتتبع جلستي. بافتراض أنني لا أريد أو أهتم بالقدرة على إنهاء الجلسة عند الطلب (على الرغم من أن هذه ليست ميزة متأصلة في ملفات تعريف الارتباط بل في التعامل مع الطلبات) ، فإنني أستخدم عنوان Bearer مع كل منشور وأستجيب له فشل مع موجه المصادقة / النشر للحصول على جلسة JWT ليتم تضمينها في جميع الرؤوس - قد أكون غبيًا ولكني لا أرى كيف أن هذا أقل أمانًا؟ تتوفر تفاصيل ملفات تعريف الارتباط في التطبيق المختلط مثلها مثل الرمز المميز على الرغم من وجود تحكم أقل في الاستمرارية ... أعتقد أنني لا أفهم سبب كون هذا نهجًا سيئًا. تأكد من أنك بحاجة إلى تقديم بيانات الاعتماد للحصول على JWT ولكنك تفعل ذلك مرة واحدة - وليس في كل خدمة.

أسألك هذا - كيف يمكنني نشر تطبيق يستخدم 3 خدمات مختلفة (ربما على بنية أساسية مختلفة للحاويات وما إلى ذلك) ودمجها في التطبيق بالاعتماد على ملفات تعريف الارتباط للجلسة؟

يعتمد على ما تفعله الخدمات الثلاث. هل يمكنك التفصيل؟

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

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

1. إذا كان موقع ويب عاديًا: تقوم خدمة المصادقة بإعادة التوجيه إلى صفحة مصادقة على خادم التطبيق ، على سبيل المثال. تمرير رمز JWT كمعامل استعلام. يتحقق خادم التطبيق من صحة الرمز المميز ، ويمنح المستخدم ملف تعريف ارتباط الجلسة.
2. إذا كان SPA: تقوم خدمة المصادقة بإرجاع الرمز المميز الذي تم إنشاؤه في استجابتها (JSON؟). يقوم تطبيق الواجهة الأمامية بإجراء طلب HTTP إلى نقطة نهاية مصادقة خادم التطبيق ، بما في ذلك الرمز المميز كمعامل ، وبعد التحقق من صحة بواسطة خادم التطبيق ، يتلقى ملف تعريف ارتباط الجلسة في المقابل.
3. إذا كان تطبيقًا مستقلاً (سطح المكتب أو الهاتف المحمول): مثل لـ SPA ، ولكن باستخدام مكتبة HTTP تدعم ملفات تعريف الارتباط ، بدلاً من تطبيق الواجهة الأمامية في المستعرض.

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

تحرير: تمت إضافة حالة تطبيق قائمة بذاتها.

لنفترض أننا في سيناريو تطوير تطبيقات الأجهزة المحمولة SPA / Hybrid. افترض أيضًا أننا نستخدم JWT للجلسة فقط - وليس OUATH مع رموز المصادقة والحامل - فقط قم بتسجيل الدخول واستلام رمز الحامل.
دعنا نتخيل أن لدينا تطبيقًا في الوقت الفعلي مع تقديم طلبات في كل جلسة لجميع الخدمات الثلاث كل 5-15 ثانية. يقوم العديد من المستخدمين بتسجيل الدخول للتحقق السريع من الحالة أو لنشر بيانات GIS أو شيء ما بحيث يكون متوسط ​​وقت الاستخدام أقل من دقيقة واحدة ولكنهم يرغبون في بدء تشغيل التطبيق - إغلاقه - إعادة التشغيل بعد 3 أيام بدون بيانات الاعتماد وما إلى ذلك (إضافة التفاصيل غير ذات الصلة إلى حد كبير هنا ولكن الأشياء التي من شأنها أن تبعدني عن ملفات تعريف الارتباط)

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

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

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

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

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

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

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

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

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

لا تهم الخدمات تقريبًا - لست متأكدًا مما تشير إليه؟

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

دعنا نقول [...]

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

متى يمكنني الاعتماد على JWT بثقة؟

لا يمكنك.

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

من غير المرجح. انظر ملاحظتي حول الخدمات ذات الحالة مقابل الخدمات عديمة الجنسية.

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

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

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

لماذا نحد من الإطار الزمني لنصف الطريق؟

في المثال الذي أعطيته؟ لأنها مخصصة كرموز تبادل ذات استخدام واحد ، وليست معرفات ثابتة. أنت لا تريدها أن تكون معرّفات ثابتة ، لأنه لا يمكنك إبطالها.

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

لا يوجد خطر في تحديث الجلسة.

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

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

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

يبدو أننا يمكن أن نلخص اعتراضك على JWT لأن نهج إدارة الجلسة قد يؤدي إلى إرفاقك بتعريف الجلسات التي تتطلب الإلغاء لكل طلب (وبعض الميزات الأخرى التي كانت تقليديًا جزءًا من ضمان أن المستخدم مصرح له للوصول) والخطر المرتبط بإنعاشهم (إذا تم اعتراضهم). المعالجة الموزعة هي المعيار الجديد - الخدمات المتعددة شائعة جدًا - إذا أردنا اعتماد استخدام هذا النوع من النهج في بنية متعددة الخدمات ، فنحن بحاجة إلى فهم النتائج بشكل كامل. قواعد البيانات الموزعة موجودة لفترة طويلة. توجد مخازن البيانات الموزعة مثل DNS منذ البداية. في بعض الأحيان ، توفر بساطة البنية مزايا أكثر من محاولة الضغط على المعيار السائد الحالي خارج حدود التصميم الخاصة به. إذا كنا على دراية بقضايا حامض المعاملة ACID للمعاملات في جلسات طلب الخدمة الخاصة بنا ، فلا يوجد سبب يمنعنا من تبني نهج إدارة جلسة JWT لخدمات المصادقة لاستغلال الإمكانات بالكامل دون التقيد بما سيصبح بسرعة بنية تحتية معقدة إذا أصررنا على القيود الصارمة وحاول استخدام ملفات تعريف الارتباط الخاصة بجلسة الحذاء كحل أفضل.
@ joepie91 - عند الاقتضاء ، يمكنك استخدام مصادقة جلسة ملف تعريف الارتباط
تأتي ملفات تعريف ارتباط جلسة https أيضًا مع بعض المخاطر - فمن المدهش عدد المواقع التي لم يتم ضبط علامة ssl عليها وتمرير ملف تعريف الارتباط كنص عادي عند الاتصال بـ SSL. هل هذا يجعل جلسات ملفات تعريف الارتباط خطيرة؟
إن الخطر الأكبر الذي يبدو أنني قادر على العثور عليه هو أن المبرمج يسمح بإرسال الرمز المميز إلى الخادم الخطأ وأن الرمز المميز يسمح بشكل فعال لطرف ثالث بالوصول إلى موارد المستخدم الثانوية هذه. يجب وضع علامة على ذلك بأحرف حمراء كبيرة في مكان ما ووضع عبء كبير على المطور لضمان عدم حدوث ذلك. يجب على المطور اتخاذ الخطوات المناسبة لضمان اتخاذ التدابير الأمنية اللازمة ويجب أن يشرح الريبو مثل هذا بعض هذه الأساليب ويدرجها في الأمثلة. في رأيي ، هذا سعر مقبول يجب دفعه مقابل مرونة مصادقة الخدمة المحدودة بوقت عبر النطاقات للخدمات غير الحرجة.
عند تصميم حل معقد ، من المحتمل أن تتضمن ملفات تعريف الارتباط للجلسة في نهاية المصادقة ويمكن تمديدها لتشمل الرموز المميزة لمرة واحدة وما إلى ذلك عند الاقتضاء. النقطة المهمة هي أن هذه الأشياء ممكنة ، وفي حين أن هناك أماكن يمكن أن تسوء وتكشف المخاطر ، فإنها توفر الفرصة لبناء تطبيقات أكثر ثراءً ورشاقة في كثير من الحالات ، ولهذا السبب لا أعتقد أنه يجب إهمال هذا الريبو كما هو مقترح بواسطة مسجل القضية.
يبدو أن الميل لمحاولة الحصول على أفضل ما في العالمين باستخدام JWT كسلسلة الجلسة بالنسبة لي يؤدي إلى ظهور مشكلات - والأكثر لفتًا للنظر هو فترات المهلة / TTL المتضاربة المحتملة. كما أنه يفرض نفس قيود الوصول إلى النطاق التي ربما كنا نحاول تجنبها في المقام الأول ، لذا فإن وضع ذلك في المثال الأساسي قد يدفع الناس إلى التساؤل عن سبب استخدام JWT في المقام الأول؟

يعد استخدام JS كاعتمادية بسيطًا جدًا - في سياق SPA المحمول الهجين ، من غير المحتمل أنك بحاجة إلى استيعاب عميل JS مجاني. إن الإيحاء بأن هذه مشكلة بينما الادعاء بالمثل أن redis يوفر خيارًا فعالًا لتخزين الجلسة يبدو متناقضًا بعض الشيء.
لا يعد انتهاء الصلاحية في JWT عديم الفائدة من حيث أنه يوفر مهلة جلسة يجب التعامل معها إما عن طريق التحديث (تمامًا بالطريقة التي يتم بها تحديث جلسات ملفات تعريف الارتباط) أو تتطلب إعادة المصادقة. يضمن توقيع JWT أنه لم يتم العبث به وبالتالي يلغي المطلب المطلق للتحقق من صحة التخزين الدائم من جانب الخادم ، على الرغم من أنه يمكن القيام بذلك إذا كان ذلك مطلوبًا ويحقق نفس النتيجة مثل جلسات ملفات تعريف الارتباط دون تنفيذ رأي كبير ومع القدرة على استخدام المجال المتقاطع إذا كان ذلك مناسبًا. في تطبيق الهاتف الهجين ، يمنح تخزين ملفات تعريف الارتباط أو JWT في التخزين المحلي مزيدًا من التحكم مرة أخرى. تعتبر الاعتراضات على استخدام التخزين المحلي على أمان تنفيذ المتصفح مسألة ثقة في البائع وقبول تعامله مع بيانات الاعتماد هذه.
المرونة مفيدة للعديد من مطوري SPA الهجين المتنقلين ولكنها تتطلب فهم ماهية القيود.
يمكن إبطال JWT ببساطة عن طريق تغيير مفتاح التوقيع ومرة ​​أخرى يوفر هذا المرونة - يمكنك استخدام مفتاح توقيع خاص مشترك عبر الخدمات أو إنشاء عشوائي لكل جلسة مستخدم وإدراك نوع مزايا التنصل من ملفات تعريف الارتباط للجلسة.
تدعم جميع أطر عمل JS الحديثة تقريبًا JWT وسيكون من الصعب العثور على نظام أساسي رئيسي لا يدعمه - ولكن ربما لا ينبغي فعلاً ذلك (ملحق Wordpress JWT .. hmm .. لم ينظر إليه ولكنه يجعلني متوترًا).
يجب أن يتضمن استخدام JWT الخلفية في OAUTH والمفاضلات وفوائد استخدام جلسات ملفات تعريف الارتباط. بالنسبة لي ، هناك مزايا عمل حقيقية للمطورين الهجينين العاديين الذين يستخدمون خدمات متعددة ولكن هناك مصائد يسهل الوقوع فيها. قد نحتاج إلى العديد من الأمثلة لتوضيحها بالكامل.

المنطق الأصلي الخاص بي لاستخدام JWT كرمز للتفويض هو أن التحقق من JWT مرتبط بوحدة مرتبطة بالإدخال
http://stackoverflow.com/questions/868568/what-do-the-terms-cpu-bound-and-io-bound-mean

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

أعرف أن JWTs ربما لم يتم _تصميمها_ لاستخدامها كرموز مميزة في رؤوس التفويض ، لكنني لا أعتقد أنني أفهم تمامًا سبب كونها "فكرة سيئة" نظرًا لأنها _ أسرع_ من أنظمة إدارة الجلسات الأخرى ...

ملاحظة: ما زلت أوافق على أن زاوية "عدم وجود ملفات تعريف الارتباط" ليست الطريقة الصحيحة لبدء هذا الملف التمهيدي / البرنامج التعليمي. 👍