كيف تبني نظام تسجيل دخول آمن

مقدمة

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

في هذا المقال سنبني الصورة العامة لنظام تسجيل دخول آمن من منظور Frontend Developer، مع نقاط مهمة يجب الاتفاق عليها مع Backend.

Authentication vs Authorization

قبل أي كود، يجب التفريق بين مصطلحين.

Authentication تعني: من أنت؟ هل المستخدم سجل الدخول فعلا؟

Authorization تعني: ماذا يسمح لك أن تفعل؟ هل هذا المستخدم admin؟ هل يستطيع حذف مقال؟ هل يستطيع رؤية صفحة معينة؟

مثال بسيط: المستخدم قد يكون مسجل الدخول، لكنه لا يملك صلاحية دخول لوحة التحكم.

هذا التفريق مهم لأن حماية route لا تعتمد فقط على وجود user، بل أحيانا على role أو permission.

الطرق الشائعة لإدارة الجلسة

هناك طريقتان منتشرتان:

الأولى: Session تعتمد على Cookie ومعرف جلسة محفوظ في السيرفر. السيرفر يعرف الجلسة ويستطيع إلغاءها بسهولة.

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

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

أين نخزن التوكن؟

واحد من أهم القرارات هو مكان تخزين التوكن.

تخزين access token في localStorage شائع، لكنه يحمل خطرا واضحا: إذا حدث XSS وتمكن كود ضار من العمل داخل الصفحة، يمكنه قراءة التوكن.

الخيار الأكثر أمانا غالبا هو استخدام HttpOnly Cookie. هذه cookie لا يستطيع JavaScript قراءتها، فيقل خطر سرقة التوكن من الواجهة.

لكن cookies لها تحديات أخرى مثل CSRF، لذلك يجب ضبطها بشكل صحيح:

• HttpOnly لمنع JavaScript من قراءتها.
• Secure لإرسالها عبر HTTPS فقط.
• SameSite لتقليل مخاطر CSRF.

Access Token و Refresh Token

في أنظمة كثيرة، يتم استخدام نوعين من التوكن:

Access token قصير العمر، يستخدم للوصول إلى الموارد.

Refresh token أطول عمرا، يستخدم لاستخراج access token جديد عند انتهاء القديم.

الفكرة أن التوكن الذي يستخدم كثيرا يكون قصير المدة، وإذا تسرب يكون أثره محدودا. أما refresh token فيجب حمايته أكثر، ويفضل وضعه في HttpOnly Cookie.

حماية Routes في React

في React، يمكنك إنشاء wrapper يحمي الصفحات التي تحتاج تسجيل دخول.

function ProtectedRoute({ user, children }) {
  if (!user) {
    return <Navigate to="/login" replace />;
  }

  return children;
}

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

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

التعامل مع انتهاء الجلسة

يجب أن تتوقع أن الجلسة قد تنتهي في أي وقت. مثلا:

• access token انتهى.
• المستخدم سجل الخروج من جهاز آخر.
• السيرفر ألغى الجلسة.
• refresh token لم يعد صالحا.

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

تجنب عمل refresh loop لا نهائي. يجب أن يكون السلوك واضحا ومحدودا.

تسجيل الخروج Logout

تسجيل الخروج ليس مجرد حذف user من state. يجب أيضا إبلاغ السيرفر حتى يلغي الجلسة أو refresh token إذا كان النظام يدعم ذلك.

خطوات logout جيدة:

1. إرسال طلب logout للسيرفر.
2. حذف بيانات المستخدم من client state.
3. إفراغ cache الخاصة بالمستخدم.
4. تحويل المستخدم إلى صفحة login أو الصفحة الرئيسية.

إذا كنت تستخدم TanStack Query مثلا، فمن المهم تنظيف query cache بعد logout حتى لا تظهر بيانات المستخدم السابق.

XSS و CSRF ببساطة

XSS يحدث عندما يستطيع مهاجم تشغيل JavaScript داخل موقعك. إذا كنت تخزن التوكن في localStorage، قد يستطيع قراءته. لذلك يجب تجنب عرض HTML غير موثوق، واستخدام sanitization عند الحاجة، وعدم إدخال بيانات المستخدم مباشرة في DOM بطرق خطرة.

CSRF يحدث عندما يستغل موقع خارجي cookies الخاصة بالمستخدم لإرسال طلب إلى موقعك. تقليل الخطر يكون من خلال SameSite cookies، واستخدام CSRF token في بعض الحالات.

المهم أن تفهم أن تخزين الجلسة في cookies يحل مشكلة ويجلب مشكلة أخرى تحتاج ضبطا صحيحا.

نصائح للـ Frontend

لا تعتمد على route guards فقط كحماية نهائية.

لا تخزن كلمات المرور أو refresh tokens في localStorage.

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

لا تفترض أن user object في الواجهة دليل على الصلاحية. اسأل السيرفر عند العمليات المهمة.

استخدم HTTPS دائما في الإنتاج.

مثال لتدفق تسجيل دخول جيد

التدفق العملي قد يكون كالتالي:

1. المستخدم يرسل email وpassword.
2. السيرفر يتحقق من البيانات.
3. السيرفر يضع refresh token في HttpOnly Cookie.
4. الواجهة تستقبل بيانات المستخدم أو access token قصير العمر.
5. عند فتح التطبيق، يتم طلب /me لمعرفة المستخدم الحالي.
6. عند انتهاء access token، يتم طلب refresh.
7. عند فشل refresh، يتم logout تلقائيا.

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

الخلاصة العملية

نظام تسجيل الدخول الآمن لا يعتمد على كود واحد، بل على مجموعة قرارات متناسقة بين Frontend وBackend. افهم نوع الجلسة، مكان التخزين، طريقة refresh، وكيفية التعامل مع الأخطاء.

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