ما دور Token based authentication في حماية تطبيقات الويب؟

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

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

ويصبح من الصعب على الخادم تتبع المستخدمين النشطين وإدارة جلساتهم

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

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

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

وعليكم السلام ورحمة الله وبركاته .

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

الآلية التقليدية لل Token based authentication تعمل بالطريقة التالية:

تسجيل الدخول: المستخدم يقوم بإدخال بيانات الاعتماد (اسم المستخدم وكلمة المرور).

التحقق من الاعتماد: يتم التحقق من صحة بيانات الدخول. إذا كانت صحيحة، يتم إنشاء وإرجاع توكن (Token).

إرسال ال token: token يتم إرساله إلى العميل (المتصفح أو التطبيق).

استخدام ال token: العميل يقوم بإرفاق الtokenفي كل طلب يقوم به إلى الخادم.

الآن نأتي لسؤالك الأساسى وهو الإكتفاء فقط بالتحقق الأولي بعدها ندع المستخدم يرسل الطلبات بدون التحقق منها مادام أنه لم يقم بتسجيل الخروج . هذا سؤال جيد ولكن يوجد سؤال لك كيف سنعرف أن هذا المستخدم هو من يقوم بإرسال الطلبات في كل مرة ؟؟ كيف سترسل المعلومات ؟ ستقول مثلا أنه يتم وضعها في ال session إذا أى شخص يستطيع وضعها في ال session فمن الممكن أنني أعرف أن الحساب بك هو test@test.com إذا سأقوم بوضعها في ال session وأنتحل شخصيتك ولن يفرق الخادم بيننا . حيث أنه في ال token يتم تشفيره برقم سرى في الخادم وحين يتم إرجاع ال token فك تشفيره بكلمة السر هذه ولو تم تشفير ال token بكلمة سر خاطئة فلن يتم إستكمال الطلب وهذا يجعل مستحيل إنتحال شخصية ال token إلا عن طريقة سرقة ال token نفسه من الشخص ولكن غير ذلك فمن المستحيل إنتحال شخصية شخص عن طريق ال token.