إدارة الجلسات لتطبيقات الويب: الكوكيز مقابل JWTs مقابل توكنات التحديث

ما الذي تفعله إدارة الجلسات فعلاً

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

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

تعتمد معظم إعدادات تطبيقات الويب على ثلاث مكوّنات أساسية:

• جلسات خادمية معتمدة على الكوكيز: المتصفح يخزن كوكي، والخادم يبحث عن الجلسة عند كل طلب.
• توكنات الوصول JWT: العميل يرسل توكن موقع يمكن للخادم التحقق منه دون استعلام قاعدة بيانات.
• توكنات التحديث (Refresh tokens): بيانات اعتماد طويلة العمر تُستخدم للحصول على توكنات وصول قصيرة العمر.

هذه ليست "أنماط" متنافسة بقدر ما هي طرق مختلفة للتعامل مع نفس المقايضات: السرعة مقابل التحكم، البساطة مقابل المرونة، و"هل يمكننا إبطال هذا الآن؟" مقابل "هل ينتهي صلاحيته من تلقاء نفسه؟"

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

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

نماذج التهديد التي تغير الإجابة الصحيحة

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

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

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

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

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

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

جلسات الكوكيز: كيف تعمل وماذا تحمي

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

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

الكثير من الحماية يأتي من إعدادات الكوكي:

• HttpOnly: يمنع جافاسكربت من قراءة الكوكي.
• Secure: يرسل الكوكي فقط عبر HTTPS.
• SameSite: يقيّد متى يرسل المتصفح الكوكي في الطلبات عبر المواقع.

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

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

توكنات الوصول JWT: القوة والحواف الحادة

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

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

نقاط القوة

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

مثال: بوابة عملاء تستدعي "قائمة الفواتير" و"تحديث الملف" على خدمات منفصلة. يمكن لـ JWT حمل معرف العميل ودور مثل customer، لذا يمكن لكل خدمة منح الإذن دون البحث في جلسة في كل مرة.

الحواف الحادة

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

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

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

توكنات التحديث: جعل إعدادات JWT قابلة للعمل

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

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

التدوير هو ما يجعل توكنات التحديث قابلة للعمل في الأنظمة الحقيقية. بدلًا من استخدام نفس توكن التحديث لأسبوع، تُبدّله في كل مرة يُستخدم فيها: يعرض العميل توكن التحديث A، يصدر الخادم توكن وصول جديدًا بالإضافة إلى توكن تحديث B، ويصبح توكن A غير صالح.

إعداد تدوير بسيط يتبع عادة قواعد قليلة:

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

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

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

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

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

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

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

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

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

ما يمكنك وعد المستخدمين به بشكل واقعي:

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

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

خطوة بخطوة: اختيار نهج الجلسات لتطبيقك

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

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

ترتيب عملي يناسب معظم الفرق:

1. اذكر عملائك: الويب، iOS/Android، أدوات داخلية، وصول الطرف الثالث.
2. اختر نموذج تهديد افتراضي: XSS، CSRF، جهاز مسروق.
3. قرر ما الذي يجب أن يضمنه تسجيل الخروج: هذا الجهاز، كل الأجهزة، إيقاف قسري من المسؤول.
4. اختر نمطًا أساسيًا: جلسات معتمدة على الكوكيز (الخادم يتذكر) أو توكن وصول + توكن تحديث.
5. اضبط مهلات الوقت وقواعد الاستجابة: انتهاء الخمول مقابل انتهاء مطلق، وما تفعل عند رؤية إعادة استخدام مريبة.

ثم وثّق الوعود الدقيقة التي يقدمها نظامك. مثال: "تنتهي جلسات الويب بعد 30 دقيقة من الخمول أو 7 أيام مطلقة. يمكن للمسؤول فرض تسجيل الخروج خلال 60 ثانية. يمكن تعطيل الهاتف المفقود عن بُعد." تلك الجمل أهم من المكتبة التي تستخدمها.

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

أخطاء شائعة تؤدي إلى استيلاء على الحساب

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

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

فخ آخر هو جعل JWTs طويلة العمر لتجنب توكنات التحديث. توكن وصول لمدة 7 أيام يعني نافذة استخدام معاد 7 أيام إذا تم تسريبه. توكن وصول قصير مع توكن تحديث مُدار جيدًا أصعب في الاستغلال، خاصة عندما يمكنك قطع التحديث.

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

أخطاء أخرى تظهر غالبًا بعد مراجعات الحوادث:

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

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

فحوص سريعة قبل الإطلاق

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

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

قائمة فحص قبل الإصدار

مر بهذه الفحوص في البيئة التجريبية، ثم مرة أخرى في الإنتاج:

• اجعل توكنات الوصول قصيرة العمر (بالدقائق)، وتأكد أن الـ API يرفضها فعلًا بعد انتهاء الصلاحية.
• عامل توكنات التحديث ككلمات مرور: خزّنها حيث لا يقرأها جافاسكربت إذا أمكن، أرسلها فقط إلى نقطة تحديث التوكن، ودوّرها بعد كل استخدام.
• إذا استخدمت الكوكيز للمصادقة، تحقق من الأعلام: فعل HttpOnly وSecure، واضبط SameSite عن عمد. وتأكد أيضًا أن نطاق ومسار الكوكي ليسا أوسع من اللازم.
• إذا كانت الكوكيز تُستخدم للمصادقة، أضف دفاعات CSRF، وتأكد أن نقاط النهاية التي تغيّر الحالة تفشل بدون إشارة CSRF.
• اجعل الإبطال حقيقيًا: بعد إعادة تعيين كلمة المرور أو تعطيل الحساب، يجب أن تتوقف الجلسات الحالية عن العمل بسرعة (حذف الجلسة على الخادم، إبطال توكنات التحديث، أو فحص "نسخة الجلسة").

بعد ذلك، اختبر وعود تسجيل الخروج. غالبًا ما يعني "تسجيل الخروج" "إزالة الجلسة المحلية"، لكن المستخدمين يتوقعون أكثر.

اختبار عملي: سجّل الدخول على حاسوب محمول وهاتف، ثم غيّر كلمة المرور. يجب أن يُطرَد الحاسوب المحمول على الطلب التالي، ليس بعد ساعات. إذا عرضت "تسجيل الخروج من كل الأجهزة" وقائمة أجهزة، فتأكد أن كل جهاز يقابله سجل جلسة أو سجل توكن تحديث يمكن إبطاله.

مثال: بوابة عملاء بها حسابات موظفين وتسجيل خروج قسري

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

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

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

يمكن أن يبدو ذلك كالتالي:

• مدة توكن الوصول: 5 إلى 15 دقيقة.
• تدوير توكن التحديث: كل عملية تحديث تصدر توكن تحديث جديدًا ويُبطل القديم.
• خزّن توكنات التحديث بأمان: على الويب، احتفظ بتوكن التحديث في كوكي HttpOnly وSecure؛ على الجوال، احتفظ به في مخزن آمن للنظام.
• تتبع توكنات التحديث على الخادم: خزّن سجل توكن (المستخدم، الجهاز، وقت الإصدار، آخر استخدام، علم الإبطال). إذا أعيد استخدام توكن مُدوَّر، اعتبره سرقة وأبطل السلسلة كلها.

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

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

الخطوات التالية: نفّذ، اختبر، واجعل الصيانة ممكنة

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

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

قائمة اختبار عملية

شغّل اختبارات تغطي الحالات الفوضوية:

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

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

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

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