يوجد الرمزان لحلّ تعارض مباشر: يجب إرسال access token في كل طلب (لذا فهو مكشوف كثيرًا)، لكنك في الوقت نفسه تريد جلسات تدوم طويلًا دون إجبار المستخدم على تسجيل الدخول المتكرر. لا يمكنك الحصول على الأمرين معًا بأمان في رمز واحد — لذا تقسم المهمة.
يوجد الرمزان لحلّ تعارض مباشر: يجب إرسال access token في كل طلب (لذا فهو مكشوف كثيرًا)، لكنك في الوقت نفسه تريد جلسات تدوم طويلًا دون إجبار المستخدم على تسجيل الدخول المتكرر. لا يمكنك الحصول على الأمرين معًا بأمان في رمز واحد — لذا تقسم المهمة.
Authorization في كل استدعاء API. لأنه يُنقل باستمرار، فالتسريب مُرجَّح؛ إبقاؤه قصيرًا يعني أن المسروق ينتهي صلاحيته فورًا تقريبًا.Login ──▶ access (15m) + refresh (30d)
Every API call ──▶ send access
Access expired ──▶ send refresh ──▶ new access (+ rotated refresh)
| access token واحد طويل العمر | Access + refresh | |
|---|---|---|
| التعرّض | يُرسَل في كل طلب، ويعيش طويلًا ← نافذة سرقة كبيرة | access قصير العمر؛ refresh يُرسَل نادرًا |
| الإبطال | صعب (JWT عديم الحالة لا يمكن سحب إصداره) | أبطل refresh token؛ يموت access خلال دقائق |
| تجربة المستخدم | إعادة تسجيل دخول متكررة إن كان قصيرًا | يبقى مسجّلًا دون إعادة إدخال بيانات الاعتماد |
| نطاق ضرر التسريب | كبير | صغير (access ينتهي بسرعة) |
httpOnly، بعيدًا عن متناول XSS.هذا هو تصميم المصادقة الحديث المعياري، ويطرحه المحاورون ليروا ما إذا كنت تفهم السبب، لا مجرد الكيفية. الفكرة الجوهرية هي المقايضة: انعدام الحالة والتعرّض القصير (access) مقابل الجلسات الطويلة وقابلية الإبطال (refresh). الخطأ فيه — access token طويل العمر، بلا تدوير، refresh مخزَّن في localStorage — يحوّل رمزًا مسرَّبًا واحدًا إلى اختراق حساب طويل الأمد. تسمية هذا الفصل وما يمنحك إياه كل رمز هو ما يُتوقَّع من مهندس واعٍ أمنيًا أن يعرفه.
مكتبة من أسئلة مقابلات تقنية المعلومات مع إجابات مفصّلة — من المبتدئ إلى المتقدم.
تبرع