JWT مقابل المصادقة القائمة على الجلسة
تعرف على الفروقات بين المصادقة القائمة على الجلسة و JWT. استكشف المفاضلات، المزايا، وحالات الاستخدام لاختيار نظام المصادقة المناسب لتطبيقاتك.
تعرف على الفروقات بين المصادقة القائمة على الجلسة و JWT. استكشف المفاضلات، المزايا، وحالات الاستخدام لاختيار نظام المصادقة المناسب لتطبيقاتك.
بشكل عام، الخطوة الأولى في استخدام تطبيق ما هي المصادقة، حيث يقدم المستخدم النهائي بيانات الهوية الخاصة به لتسجيل الدخول بنجاح. بعد هذه الخطوة، يعرف نظام الهوية (مثل مزود الهوية، خادم المصادقة، إلخ) من هو المستخدم وإلى أي الموارد لديه وصول.
نظراً لأن HTTP هو بروتوكول غير دائمي بطبيعته، فإن كل طلب في جلسة يكون مستقلاً ولا يسترجع المعلومات من الطلبات السابقة. إعادة المصادقة على المستخدمين لكل إجراء مرهقة وتؤثر على تجربة المستخدم.
دعونا ندخل في المصادقة القائمة على الجلسة و مصادقة JWT (JSON Web Tokens)، وهما طريقتان شائعتان للحفاظ على حالة المصادقة. لكل منهما مزاياه وتنازلاته الفريدة، وتتمثل الاختيار بينهما في تحديد احتياجات تطبيقك الخاصة. إذا كنت تقرر بين الاثنين، فإن هذا الدليل موجود هنا للمساعدة.
تعتمد المصادقة القائمة على الجلسة على الخادم للاحتفاظ بسجل لحالة مصادقة المستخدم. من خلال إنشاء وإدارة الجلسات، يمكن للخادم تمكين المستخدمين من الاستمرار في تسجيل الدخول والتفاعل مع التطبيق دون الحاجة إلى إعادة إدخال بيانات الوصول الخاصة بهم مع كل طلب.
إنشاء الجلسة
SessionID في قاعدة البيانات وتعيده إلى العميل كمجموعة ملفات تعريف الارتباط.التحقق من الجلسة
SessionID).SessionID عن طريق استشارة بيانات الجلسة المخزنة على الخادم.يمكن إبطال الجلسات في الوقت الحقيقي، مما يكون مفيداً في حالات الحاجة إلى إلغاء الوصول بسرعة.
تُدمج JWT (JSON Web Tokens) أسلوباً مختلفاً عن طريق تضمين جميع المعلومات ذات الصلة بالمستخدم مباشرة داخل الرمز، باستخدام كائن JSON. على عكس الطرق القائمة على الجلسة، فإن JWTs هي غير دائمة، مما يعني أن الخادم لا يدير سجلات المصادقة.
يتكون JWT من ثلاثة أجزاء: الرأس و الحمولة و التوقيع.

إصدار JWT
تتبع العمليات القائمة على الجلسة عملية مشابهة. ومع ذلك، بعد المصادقة، يتم تخزين معلومات المستخدم على الخادم داخل جلسة، بينما تعتمد JWTs على الأكواد المرسلة إلى العميل للتخزين والاستخدام اللاحق.
التحقق من الرموز
Authorization (Bearer <token>).تتطلب المصادقة القائمة على الجلسة من الخادم الاستعلام عن مخزن الجلسة، والذي يمكن أن يكون بطيئاً، خاصة إذا كان يعتمد على قواعد بيانات خارجية أو مركزية. على النقيض من ذلك، فإن مصادقة JWT غير دائمة، حيث يتم تخزين جميع المعلومات الضرورية في رمز العميل، وتستخدم التوقيع لضمان الأمان. هذا يلغي الحاجة إلى إدارة الجلسات، مما يجعلها أسرع وأكثر قابلية للتوسع، خاصة في الأنظمة الموزعة.
في جانب العميل، عادةً ما يعني تسجيل الخروج مسح الجلسة المحلية وإزالة الرموز (رمز ID، رمز الوصول، رمز التحديث) من التخزين. ولكن بالنسبة لمصادقة JWT، فإن هذا يؤدي فقط لتسجيل خروج المستخدم محلياً، ويترك الجلسة المركزية على خادم التفويض قائمة. ونتيجة لذلك، قد يظل المستخدمون يستطيعون الوصول إلى تطبيقات أخرى تحت نفس الجلسة حتى انتهاء صلاحية الرمز أو إنهاؤه يدوياً.
إلغاء JWT (JSON Web Token) يعتبر أكثر تحدياً من المصادقة القائمة على الجلسة لأن JWTs غير دائمة ولا يمكن إبطالها بمجرد إصدارها، ما لم يتم تنفيذ استراتيجيات محددة. تشمل الطرق الشائعة:
exp قصيرة (مثل، 15 دقيقة) لـ JWT. بمجرد انتهاء صلاحيتها، يجب على المستخدم إعادة المصادقة. هذا يقلل من المخاطر إذا تم اختراق الرمز، حيث يمكن للمهاجم استخدامه لفترة محدودة فقط. للحفاظ على تجربة مستخدم سلسة، يمكن استخدام رمز التحديث لتقليل إزعاج إعادة المصادقة.JWT لا يتم تحديثه بشكل فوري
بمجرد توقيع JWT، لا يمكن إبطاله أو تحديثه، وسيعتبر صالحاً طالما أن التوقيع صالح ولم ينتهِ.
إذا تغيرت أذونات الوصول الخاصة بالمستخدم (عادةً يتم تقليلها)، سيظل للمستخدم إمكانية الوصول المحذوف للموارد حتى ينتهي صلاحية JWT. وبالمثل، إذا كانت JWT تحتوي على معلومات تفويض قائمة على الأدوار، فإن نطاق التفويض الجديد لن يسري حتى تنتهي صلاحية JWT القديمة. بعبارة أخرى، لا تناسب JWT التحديث في الوقت الحقيقي ويمكن للمستخدمين وضع وقت انتهاء صلاحية مناسب للتخفيف من هذه المشكلة.
معضلة الأجهزة المتعددة والإبطال
من غير الممكن التحقق من صحة جميع JWTs المصدرة قبل انتهائها لتنفيذ إبطال المستخدم لجميع الأجهزة. بينما من الممكن نظرياً إلغاء مفتاح التوقيع لجعل JWT غير صالح، لكن هذا سيجعل أيضاً جميع JWTs التي تستخدم ذلك المفتاح غير صالحة، وستجعل عملية معالجة مفاتيح الكاش هذه الطريقة غير عملية لعمليات إبطال المستخدم البسيطة.
قد يكون لدى بعض مزودي الهوية حلول جاهزة للمشاكل المتعلقة بـ JWT. لمزيد من المعلومات، تحقق من "أفضل الممارسات لتحسين تجربة مصادقة JWT".
الجلسات و JWTs هما نهجان شهيران للحفاظ على سياق المصادقة والتفويض في عالم HTTP غير الدائم. بينما لكل منهما مزاياه وعيوبه، يقدم كل منهما فوائد وعيوب مختلفة.
تقدم الجلسات ضمانات أقوى لتفويض الطلب الفردي وهي أبسط للتنفيذ بشكل آمن. ومع ذلك، فإن اعتمادها على التحقق من صحة قاعدة بيانات الجانب الخادم يضيف زمن استجابة إضافي، مما يمكن أن يؤثر سلباً على تجربة المستخدم للتطبيقات عالية الاستجابة.
بينما تكون JWTs، من ناحية أخرى، مفيدة للتفويض السريع والتفاعل مع التطبيقات الخارجية، لكنها تتطلب جهوداً أكبر من المطورين لمعالجة تعقيدات الأمان. على سبيل المثال، يمكننا استخدام الويب هوكس لإبلاغ العملاء عند إلغاء وصول المستخدم، بحيث يمكن للعملاء مسح JWT المحفوظ وإجبار المستخدم على إعادة المصادقة.
نظراً لأن المصادقة القائمة على الرموز أكثر ملاءمة للتوسع مع أن عيوبها لا تزال قابلة للإدارة، فإنها تعتمد من قبل المزيد من التطبيقات الحديثة.
يجب أن تتماشى طريقة المصادقة الخاصة بك مع بنية تطبيقك واحتياجاتك الخاصة. إليك دليل سريع لمساعدتك في اتخاذ القرار:
تعمل المصادقة القائمة على الجلسة بشكل أفضل عندما تحتاج إلى التحكم في الجلسات في الوقت الحقيقي، أو تحتاج إلى إدارة مركزية، أو عندما لا تكون القابلية للتوسع مصدر قلق رئيسي. إليك حيث تبرز:
تطبيقات الويب ذات الجلسات المستمرة
بالنسبة لمنصات مثل مواقع التسوق على الإنترنت، تكون الجلسات ضرورية لتتبع المستخدمين، عربات التسوق، والتفضيلات خلال زيارتهم.
التطبيقات التي تتطلب التحكم في الجلسات في الوقت الحقيقي
تستفيد التطبيقات مثل الخدمات البنكية أو المالية من البيانات الجلسية التي يتحكم بها الخادم، حيث توفر إدارة وصول قوية وأماناً.
الأنظمة الخاصة بالخادم الواحد أو الأنظمة الصغيرة
تزدهر الأدوات الداخلية أو التطبيقات الصغيرة دون احتياجات توسع ثقيلة على إدارة الجلسات البسيطة لسهولة الاستخدام والموثوقية.
تعتبر مصادقة JWT أفضل تناسباً للتطبيقات التي تعطي الأولوية للتوسع والكفاءة والأنظمة الموزعة. إنها مفيدة بشكل خاص للتفاعلات غير الدائمة بين العملاء والخوادم. فكر في استخدام المصادقة القائمة على الرموز للحالات التالية:
تسجيل الدخول الأحادي (SSO)
تعتبر JWTs مثالية لـ تسجيل الدخول الأحادي، مما يسمح للمستخدمين بالمصادقة مرة واحدة والوصول بسلاسة إلى خدمات أو تطبيقات متعددة باستخدام نفس الرمز. شارك تفسيرًا مفصلاً حول تأمين التطبيقات القائمة على السحابة باستخدام OAuth 2.0 و OIDC، بصيغة JWT لكل من رموز الوصول و رموز التعرف الشخصي.
تطبيقات المحمول
تفضل تطبيقات المحمول غالباً JWTs للمصادقة حيث يمكن تخزين الرموز بأمان على الجهاز وإرسالها مع كل طلب API. استكشف التكامل السريع لمصادقة JWT لتحصل على Android / iOS.
بنيات المايكروسيرفيس
في بيئات المايكروسيرفيس، تسمح JWTs لكل خدمة بالتحقق من صحة الرمز بشكل مستقل دون الاعتماد على مخزن جلسة مركزي، مما يضمن القابلية للتوسع والكفاءة.
المصادقة عبر المجالات
تتفوق JWTs في السيناريوهات التي تتضمن مجالات متعددة أو نطاقات فرعية (مثل api.example.com، dashboard.example.com، و docs.example.com). على عكس ملفات تعريف الارتباط، تسمح JWTs بالمصادقة عبر المجالات دون تبعيات إضافية.
واجهات برمجة التطبيقات والخدمات الويب
عادةً ما تستخدم واجهات برمجة تطبيقات RESTful والخدمات الويب JWTs للمصادقة لأنها خفيفة الوزن ومحمولة وتلغي الحاجة إلى إدارة الجلسات على الجانب الخادم. تعرف على المزيد حول المصادقة الآلية لسيناريوهات حيث يحتاج التطبيق الخاص بك للتواصل مباشرة مع الموارد.
تعتبر مصادقة JWT أداة رائعة، ولكنها قد تأتي بتحديات تؤثر على تجربة المستخدم. يوفر Logto حلاً سهلاً وموثوقاً لتجاوز هذه العوائق، مما يجعله خياراً ممتازاً للمصادقة الآمنة والكفؤة.
إحدى القضايا الشائعة مع مصادقة JWT هي ضمان تجربة خروج مستخدم مناسبة. يعمل Logto على تبسيط هذه العملية باستخدام SDK المجهز بشكل كامل.
هذا يضمن إدارة جلسات متسقة وآمنة عبر نظامك البيئي. تعرف على المزيد حول آليات تسجيل الخروج وكيفية تنفيذ تسجيل الخروج.
يمكن أن يكون إدارة التغييرات في الوقت الحقيقي لصلاحيات المستخدم مع JWT معقداً. نظراً لأن JWTs غير دائمة بحسب التصميم، فإن أي صلاحيات أو أدوار محدثة قد لا تصبح فعالة حتى ينتهي صلاحية الرمز. يوفر Logto استراتيجيات للتعامل مع هذا الأمر بفعالية:
تساعد هذه الحلول في الحفاظ على صلاحيات محدثة وضمان نظام أكثر استجابة وآمناً. تعرف على المزيد حول إدارة التغييرات في الوقت الحقيقي لصلاحيات المستخدم.
يوفر Logto، وهو بنية تحتية لإدارة الوصول المعياري، حلاً كاملاً للهوية مع كل من خدمة السحابة والنسخة المفتوحة المصدر المتاحة.