التوكنز والعودة: سر إدارة الجلسات في Back-End

المشهد: العميل 247 وصلاحية التصريح خلصت​

الضوء الخافت، الشاشة الحمراء، وصوت المطر على الزجاج - الرسالة بتقول: العميل 247 انتهت صلاحية التصريح.
الكل اتوقف. نفس اللحظة دي ممكن تحصل فعلاً في أي نظام ويب أو API - توكن صلاحيتُه خلصت، والمستخدم اتقفل من الخدمة لحد ما يجدد دخوله. ‍

بس هل ده معناه إن المهمة انتهت؟ لأ خالص. العالم الحقيقي والعالم الرقمي ليهم حاجة اسمها إدارة الجلسات بشكل ذكي - ومين اللي ماسك الجزئين دول؟ الـ Back-End.

---

الفكرة البسيطة: إيه الفرق بين Access Token و Refresh Token؟​

هنتكلم بالعربي سهل وبصيغة قصة صغيرة عشان الموضوع يبقى واضح:

• Access Token هو تصريح الدخول المؤقت. زي تصريح مؤقت بيدخلك المبنى عشان تنجز مهمة. قصير الأجل، سريع، ولو اتسرق أو خلص - تقدر تقفل الوصول فورًا.
• Refresh Token هو المفتاح الذهبي اللي في جيب العميل. مش بيتنقل مع كل طلب، محفوظ أكتر، وبيستعمله العميل لما الـ Access Token يخلص علشان يطلب تصريح جديد من السيرفر من غير ما المستخدم يعمل تسجيل دخول تاني.

يعني: Access Token = تصريح قصير. Refresh Token = مفتاح لتجديد التصريح.

---

ليه النظام ده ذكي؟ (لماذا ما نديش صلاحية طويلة للـ Access Token؟)​

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

المنطق هنا زي نظام أمني في فيلم جاسوسي: تصريح مؤقت علشان المهمة تمشي، ومفتاح خاص لو احتجت تدخل تاني من غير ما ترجع للمقر.

---

مثال عملي: إزاي السيرفر بيعمل Flow للتوكنز (Node.js مثال عملي)​

هوريك مثال عملي وسريع بكود Node.js باستخدام JWT - مجرد نموذج مبسط عشان الفكرة توضح.

// مثال بسيط جدًا على Express + jsonwebtoken
const express = require('express');
const jwt = require('jsonwebtoken');
const app = express();
app.use(express.json());

const ACCESS_SECRET = 'access-secret-very-short';
const REFRESH_SECRET = 'refresh-secret-very-long';

let refreshTokensDB = []; // بدل DB بسيطة في الذاكرة

// تسجيل دخول - يصدر لك access + refresh
app.post('/login', (req, res) => {
  const user = { id: 1, name: 'agent247' }; // مثال
  const accessToken = jwt.sign(user, ACCESS_SECRET, { expiresIn: '15m' });
  const refreshToken = jwt.sign(user, REFRESH_SECRET, { expiresIn: '7d' });
  refreshTokensDB.push(refreshToken);
  res.json({ accessToken, refreshToken });
});

// تجديد Access Token باستخدام Refresh Token
app.post('/token', (req, res) => {
  const { token } = req.body;
  if (!token || !refreshTokensDB.includes(token)) return res.sendStatus(403);
  jwt.verify(token, REFRESH_SECRET, (err, user) => {
    if (err) return res.sendStatus(403);
    const newAccess = jwt.sign({ id: user.id, name: user.name }, ACCESS_SECRET, { expiresIn: '15m' });
    res.json({ accessToken: newAccess });
  });
});

// مثال endpoint محمي
app.get('/secure', (req, res) => {
  const auth = req.headers['authorization'];
  if (!auth) return res.sendStatus(401);
  const token = auth.split(' ')[1];
  jwt.verify(token, ACCESS_SECRET, (err, user) => {
    if (err) return res.sendStatus(403);
    res.json({ msg: 'أنت داخل يا بطل', user });
  });
});

app.listen(3000, () => console.log('Server on 3000'));

المثال ده للتوضيح مش Production-ready - هنكمل بعد شوية نصايح عملية عن الحماية.

---

تجربة سريعة: ازاي تشوف إن الـ Access Token انتهت صلاحيتها؟​

لو عندك Access Token من المثال فوق، جرب تطلب الـ endpoint المحمي بعد 15 دقيقة - هتلاقي 401 أو 403. لو عندك Refresh Token سليم، ترجع تطلب /token وهايرجع لك Access Token جديد.

مثال curl لتجديد:

curl -X POST http://localhost:3000/token -H "Content-Type: application/json" -d '{"token":"<REFRESH_TOKEN>"}'

---

أخطاء شائعة لازم تتجنبها (عشان المهمة ما تفشلش)​

1. حفظ الـ Refresh Token في الـ LocalStorage في المتصفح - خطر لأنه قابل للوصول عبر XSS. استخدم HttpOnly cookies.
2. عدم عمل blacklist للـ Refresh Tokens عند logout - لو مستخدم عمل logout والـ token لسه شغال، حد تاني يقدر يستخدمه. لازم تلغي التوكن من السيرفر.
3. جعل صلاحية الـ Refresh Token طويلة جدًا - دايماً فكر في التوازن.
4. عدم التحقق من جملة الأدلة (signature) وIssuer/Audience في JWT - تحقق جيدًا.

---

أفضل ممارسات لحماية الـ Tokens​

• خزن الـ Refresh Token في HttpOnly Secure Cookie بدل التخزين في الـ localStorage.
• استخدم rotating refresh tokens: كل مرة تستخدم refresh، اطلع token جديد وقلل صلاحية القديم.
• اعمل revoke list للـ refresh tokens في DB عشان تقدر تلغيهم فورًا.
• فعل MFA / 2FA لعمليات تغيير كلمات المرور أو إعادة إصدار توكنات طويلة.
• اطّلع على نشاط الجلسات: لو IP أو User-Agent اتغير فجأة، اطلب إعادة مصادقة.

---

النهاية: العميل رجع للميدان لأن النظام مظبوط​

المشهد السينمائي بتاعنا ماكنش صدفة. العميل 247 رجع للميدان لأن فيه نظام ذكي بيحمي الصلاحيات: Access Token للمهام اليومية وRefresh Token للمفتاح اللي يجدد التصاريح. وكل ده تحت رقابة الـ Back-End اللي بيعمل توقيع، تحقق، وتجميد لما يحصل خطر.

---

Check-list سريع قبل ما تطلع الإنتاج (Deploy)​

• Access Token قصير الصلاحية (مثلاً 10-30 دقيقة).
• Refresh Token محفوظ في HttpOnly cookie.
• وجود Mechanism لإلغاء الـ Refresh Token عند اللوج آوت.
• Logging لكل محاولات التجديد الفاشلة.
• Rate limiting على endpoint تجديد التوكن عشان تمنع brute-force.
• مراجعة JWT claims: issuer, audience, expiry.