JWT مقابل المصادقة القائمة على الجلسة

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

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

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

ما هي المصادقة القائمة على الجلسة؟#

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

كيف تعمل المصادقة القائمة على الجلسة؟#

إنشاء الجلسة

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

التحقق من الجلسة

1. يمكن تشغيل العملية يدوياً من قبل المستخدم (مثل النقر على علامة تبويب، تحديث الصفحة) أو تلقائياً من قبل العميل (مثل أثناء تحميل الصفحات الأولية أو عبر نداءات API باستخدام SessionID).
2. يتم إرسال كل نداءات لاحقة من HTTP من العميل تحتوي على ملفات تعريف الارتباط الخاصة بالجلسة إلى الخادم.
3. يقوم الخادم بالتحقق من صلاحية SessionID عن طريق استشارة بيانات الجلسة المخزنة على الخادم.
4. إذا كانت صالحة، يقوم الخادم بمعالجة الطلب والمصادقة على المستخدم.

كيفية إلغاء جلسة؟#

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

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

مزايا المصادقة القائمة على الجلسة#

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

عيوب المصادقة القائمة على الجلسة#

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

ما هي مصادقة JWT؟#

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

كيف تعمل مصادقة JWT؟#

يتكون JWT من ثلاثة أجزاء: الرأس و الحمولة و التوقيع.

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

إصدار JWT

1. يقوم العميل بإرسال بيانات المستخدم إلى خادم المصادقة (يكون موفر الهوية العالمي مفيداً بشكل خاص لإدارة الوصول عبر مجالات متعددة.)
2. بعد اعتماد المصادقة، يقوم الخادم بتوليد JWT يحتوي على رأس و حمولة و توقيع.
3. يقوم خادم المصادقة بإرسال الرمز الصادر إلى العميل. يخزن العميل JWT (مثل، في ملفات تعريف الارتباط، localStorage، أو sessionStorage).

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

التحقق من الرموز

1. للطلبات اللاحقة من API، يرسل العميل JWT في رأس Authorization (Bearer <token>).
2. يقوم الخادم بالتحقق من توقيع JWT باستخدام مفتاح سري أو مفتاح عام ويفحص مطالباته (مثل، انتهاء الصلاحية، المُصدر).
3. إذا كان الرمز صالحاً، يمنح الخادم العميل الوصول إلى الموارد المطلوبة.

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

كيفية إلغاء JWT؟#

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

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

• أوقات انتهاء قصيرة: تعيين مطالبة exp قصيرة (مثل، 15 دقيقة) لـ JWT. بمجرد انتهاء صلاحيتها، يجب على المستخدم إعادة المصادقة. هذا يقلل من المخاطر إذا تم اختراق الرمز، حيث يمكن للمهاجم استخدامه لفترة محدودة فقط. للحفاظ على تجربة مستخدم سلسة، يمكن استخدام رمز التحديث لتقليل إزعاج إعادة المصادقة.
• قائمة سوداء للرموز: في الحالات الحرجة (مثل، تسجيل خروج المستخدم، تغييرات كلمة المرور)، قم بإدارة قائمة سوداء من الرموز المبطلة. يقوم الخادم بفحص الرموز الواردة ضمن هذه القائمة المحظورة ويرفض أي مطابقات. على الرغم من فعاليته، يتطلب هذا النهج تتبع الرموز المبطلة، مما يتعارض مع الطبيعة غير الدائمة لـ JWTs ويمكن أن يصبح غير فعال إذا زاد حجم القائمة بشكل كبير.
• نقطة نهاية الإبطال: إدخال نقطة نهاية للإبطال على خادم التفويض حيث يمكن إبطال الرموز (مثل، رموز التحديث). بمجرد إبطال رمز تحديث، لن يتم تجديد أي رموز وصول صادرة من خلاله. يعمل هذا الأسلوب بشكل جيد في تدفقات OAuth2.

مزايا مصادقة JWT#

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

عيوب مصادقة JWT#

• JWT لا يتم تحديثه بشكل فوري

  بمجرد توقيع JWT، لا يمكن إبطاله أو تحديثه، وسيعتبر صالحاً طالما أن التوقيع صالح ولم ينتهِ.

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

• معضلة الأجهزة المتعددة والإبطال

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

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

ما هو الفرق بين JWT والجلسة؟#

الجلسات و JWTs هما نهجان شهيران للحفاظ على سياق المصادقة والتفويض في عالم HTTP غير الدائم. بينما لكل منهما مزاياه وعيوبه، يقدم كل منهما فوائد وعيوب مختلفة.

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

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

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

الجلسة مقابل JWT: اختيار الطريقة المناسبة#

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

متى تستخدم المصادقة القائمة على الجلسة#

تعمل المصادقة القائمة على الجلسة بشكل أفضل عندما تحتاج إلى التحكم في الجلسات في الوقت الحقيقي، أو تحتاج إلى إدارة مركزية، أو عندما لا تكون القابلية للتوسع مصدر قلق رئيسي. إليك حيث تبرز:

• تطبيقات الويب ذات الجلسات المستمرة

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

• التطبيقات التي تتطلب التحكم في الجلسات في الوقت الحقيقي

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

• الأنظمة الخاصة بالخادم الواحد أو الأنظمة الصغيرة

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

متى تستخدم مصادقة 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#

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

التعامل مع مشاكل تسجيل الخروج للمستخدم مع JWT#

إحدى القضايا الشائعة مع مصادقة JWT هي ضمان تجربة خروج مستخدم مناسبة. يعمل Logto على تبسيط هذه العملية باستخدام SDK المجهز بشكل كامل.

• عن طريق تنظيف الرموز والجلسات المحلية على جانب العميل وتوجيه المستخدمين إلى نقطة نهاية الجلسة الخاصة بـ Logto، يمكنك بسهولة إنهاء الجلسات على كل من التطبيق العميل والخادم.
• بالإضافة إلى ذلك، يدعم Logto ميزة تسجيل الخروج عبر القناة الخلفية، مما يسمح لـ AuthServer بإبلاغ جميع التطبيقات العميلة التي تشارك نفس الجلسة عند تسجيل الخروج.

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

التعامل مع تغييرات صلاحيات المستخدم#

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

• لتقليل صلاحيات هذا المستخدم: استخدام أوقات صلاحية قصيرة للرموز أو التحقق ديناميكياً من الصلاحيات عبر نداء API.
• لإضافة صلاحيات جديدة لهذا المستخدم: تحديث AuthServer لتضمين نطاق الصلاحيات الجديدة وإعادة الموافقة للمستخدمين لتطبيق هذه التغييرات.

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

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