كيف تتعامل الأطر الحديثة مع المصادقة والتفويض

المصادقة مقابل التفويض: ما الذي تفصله الأطر عادةً؟

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

المصادقة: إثبات الهوية

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

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

التفويض: تقرير الوصول

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

تفصل الأطر قواعد التفويض عن المصادقة حتى تتمكن من:

• تغيير طرق تسجيل الدخول دون إعادة كتابة قواعد الوصول
• تطبيق فحوصات إذن موحدة عبر صفحات الويب والـ APIs والمهام الخلفية
• الإبقاء على منطق «من أنت» منفصلًا عن منطق «ما الذي يمكنك فعله»

نقاط التنفيذ: أين تطبّق الإطار القواعد

تطبّق معظم الأطر القواعد عبر نقاط مركزية في دورة حياة الطلب:

• Middleware/filters/interceptors التي تعمل قبل المتحكمات/المدراء
• Guards التي تمنع الوصول إلى المسارات أو الإجراءات
• فحوصات السياسات المستدعاة داخل منطق الأعمال لقرارات خاصة بالموارد

اللبنات المشتركة (محايدة للإطار)

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

الأمثلة هنا مفهومية حتى تتمكن من مطابقتها مع الإطار الذي تختاره.

مخازن الهوية ونماذج المستخدم

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

مصادر الهوية النموذجية

تدعم الأطر عادةً عدة خلفيات، مدمجة أو عبر إضافات:

• مستخدمو قاعدة بيانات التطبيق: الجدول/المجموعة التقليدية التي يديرها تطبيقك.
• موفرو هوية خارجيون (IdPs): Google، Microsoft، GitHub، أو مزوّد منفصل مثل Auth0/Okta، عادة عبر OAuth 2.0 / OpenID Connect.
• دلائل مؤسسية: LDAP/Active Directory، شائع للأدوات الداخلية وتطبيقات B2B.

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

الحقول الأساسية لنموذج المستخدم

حتى عندما يُولِّد الإطار نموذجًا افتراضيًا للمستخدم، توحِّد الفرق عادةً بضعة حقول:

• id: مفتاح أساسي غير قابل للتغيير (ويفضل ألا يكون البريد الإلكتروني).
• email/username: معرف تسجيل الدخول؛ غالبًا فريد ومطبع.
• password_hash: فقط إذا كان تطبيقك يدير كلمات المرور (لا تخزن كلمات المرور بنص واضح).
• علامات الحالة: مثل is_verified, is_active, is_locked, deleted_at.

تهم هذه العلامات لأن المصادقة ليست مجرد «هل كلمة المرور صحيحة؟»—بل أيضًا «هل مسموح لهذا الحساب بتسجيل الدخول الآن؟»

دورة حياة الحساب: أكثر من مجرد التسجيل

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

أين يوصّل الإطار

توفر معظم الأطر نقاط امتداد مثل user providers, adapters, أو repositories. هذه المكونات تحول «بمعطى معرف تسجيل دخول، احضر المستخدم» و«بمعطى معرف مستخدم، حمِّل المستخدم الحالي» إلى مخزنك المختار—سواء كان استعلام SQL، استدعاء إلى IdP، أو بحث في دليل مؤسسي.

المصادقة القائمة على الجلسة (الكوكيز والجلسات الخادمية)

المصادقة القائمة على الجلسة هي النهج «الكلاسيكي» الذي تظل العديد من أطر الويب تعتمد عليه—خاصة لتطبيقات SSR. الفكرة بسيطة: الخادم يتذكر من أنت، والمتصفح يحمل مؤشر صغير لذاك التذكر.

كيف تعمل

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

نظرًا لأن الكوكي مجرد معرف (وليس بيانات المستخدم نفسها)، يبقى المحتوى الحساس على الخادم.

علامات الكوكي التي تضبطها الأطر عادةً

تحاول الأطر الحديثة جعل كوكيات الجلسة أصعب للسرقة أو سوء الاستخدام من خلال افتراضات أمنة:

• HttpOnly: يمنع قراءة الكوكي عبر جافاسكربت (يقلّل الضرر من XSS).
• Secure: يرسل الكوكي عبر HTTPS فقط.
• SameSite (Lax/Strict/None): يتحكم في إرسال الكوكي عبر المواقع (مهم للدفاع ضد CSRF وتدفقات المصادقة الخارجية).

ستجد هذه الإعدادات غالبًا تحت "إعدادات كوكي الجلسة" أو "رؤوس الأمان".

أين تُخزن الجلسات

تتيح الأطر عادةً اختيار مخزن الجلسة:

• ذاكرة داخلية (in-memory): سريعة وسهلة، لكن الجلسات تختفي عند إعادة التشغيل وتواجه صعوبات في التوسع عبر خوادم متعددة.
• قائمة/قاعدة بيانات: دائمة وقابلة للتدقيق، لكن تضيف عبء استعلام.
• مخزن كاش/Redis: سريع ومشترك عبر الخوادم؛ جيد للتوسع، لكنك تعتمد على خدمة إضافية.

عموما، المقايضة بين السرعة مقابل الديمومة مقابل تعقيد التشغيل.

تسجيل الخروج والإبطال

تسجيل الخروج قد يعني شيئين:

• تسجيل الخروج من الجهاز الحالي: حذف الجلسة الحالية ومسح الكوكي.
• تسجيل الخروج من كل الأجهزة: إبطال كل الجلسات للمستخدم (مثلاً بعد تغيير كلمة المرور).

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

المصادقة بالرموز (JWT والرموز المظلمة)

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

ماذا يعني "رمز" عمليًا

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

الرموز المظلمة مقابل JWT

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

JWTs (JSON Web Tokens) هي مُهيكلة وموقعة. عادةً تحتوي على مطالبات مثل معرف المستخدم (sub)، المصدر (iss)، الجمهور (aud)، أوقات الإصدار/الانتهاء (iat, exp)، وأحيانًا أدوار/نطاقات. هام: JWTs مُرمَّزة وليست مُشفّرة افتراضيًا—أي من يحمل الرمز يمكنه قراءة مطالبه، حتى لو لم يستطع تزويره.

التخزين: رأس التفويض مقابل الكوكيز

إرشادات الأطر عادةً توصي بإفتراضيين آمنين:

• إرسال رموز الوصول عبر الهيدر Authorization: Bearer <token> لواجهات الـ API. هذا يقلل مخاطر CSRF لأن الكوكيز لا تُرسل تلقائيًا، لكنه يرفع متطلبات الدفاع ضد XSS لأن جافاسكربت يمكنه قراءة وإرفاق الرموز.
• استخدام الكوكيز فقط عندما يمكنك جعلها HttpOnly, Secure, وSameSite، وعندما تكون مستعدًا للتعامل مع CSRF بشكل صحيح (عادةً مصاحَبًا برموز CSRF منفصلة).

رموز التجديد، التدوير، ونقاط النهاية

تُحفظ رموز الوصول قصيرة العمر. ولتجنب إجبار المستخدمين على إعادة تسجيل الدخول باستمرار، تدعم العديد من الأطر refresh tokens: سند طويل العمر يُستخدم فقط لصكّ رموز وصول جديدة.

هيكلة شائعة:

• POST /auth/login → يعيد access token (و refresh token)
• POST /auth/refresh → يدور refresh token ويعيد access token جديد
• POST /auth/logout → يبطل refresh tokens على الخادم

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

OAuth 2.0 وOpenID Connect في منظومة الأطر

يُذكر OAuth 2.0 وOpenID Connect (OIDC) معًا غالبًا، لكن الأطر تتعامل مع كلٍ منهما بشكل مختلف لأن كلًّا منهما يحلّ مشكلة مختلفة.

OAuth 2.0 مقابل OIDC: أيهما تحتاج فعلاً

استخدم OAuth 2.0 عندما تحتاج وصولًا مفوضًا: تطبيقك يحصل إذنًا لاستدعاء API نيابة عن المستخدم (مثل قراءة تقويم أو النشر على مستودع) دون التعامل مع كلمة مرور المستخدم.

استخدم OpenID Connect عندما تحتاج تسجيل دخول/هوية: تطبيقك يريد معرفة من هو المستخدم ويتلقى ID token مع مطالبات هوية. عمليًا، "تسجيل الدخول عبر X" عادةً يكون OIDC فوق OAuth 2.0.

التدفقات الأساسية التي تدعمها الأطر عادة

تركز معظم الأطر ومكتبات المصادقة فيها على تدفقين:

• Authorization Code flow + PKCE: الافتراضي لتطبيقات المتصفح والموبايل. PKCE يمنع اعتراض الكود ويُتوقع من معظم المزودين.
• Client Credentials flow: للمكالمات خدمة-إلى-خدمة حيث لا يوجد مستخدم نهاية (وظائف، عمال الخلفية، خدمات داخلية).

معالجة رد النداء: حيث تهم تفاصيل الأمان

توفر تكاملات الأطر عادةً مسار رد نداء (callback) وmiddleware مساعد، لكن لا تزال تحتاج إلى تكوين الأساسيات بشكل صحيح:

• تحقق من redirect URI بدقة (النمط/المضيف/المسار). تجنب عناوين URI بدلية.
• استخدام والتحقق من معامل state لمنع هجمات تسجيل دخول شبيهة بـ CSRF.
• بالنسبة لـ OIDC، أنشئ وتحقق من nonce لتقليل مخاطر إعادة تشغيل الرموز.
• خزّن القيم العابرة (state/nonce/verifier) في جلسة آمنة أو كوكي مشفر، لا في التخزين المحلي.

النطاقات (scopes)، المطالبات (claims)، وربطها بالمستخدم المحلي

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

• Scopes هي أذونات OAuth لواجهات الـ API (ما الذي يمكن للرمز الوصول إليه).
• Claims هي سمات الهوية في ID token الخاص بـ OIDC (من هو المستخدم).

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

كلمات المرور، التجزئة، المصادقة متعددة العوامل واسترداد الحساب

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

إعدادات تجزئة كلمات المرور (ولماذا التجزئة العادية غير آمنة)

تفترض الأطر الحديثة ومكتبات المصادقة فيها استخدام مجزئات كلمات مرور مخصصة مثل bcrypt, Argon2, أو scrypt. هذه الخوارزميات بطيئة متعمدة وتضيف salt، مما يساعد على منع هجمات الجداول المحسوبة ويجعل كسرها مكلفًا على نطاق واسع.

تجزئة سريعة مثل SHA-256 غير مناسبة لكلمات المرور لأنها مصممة لتكون سريعة؛ إذا سُرقت قاعدة البيانات، تتيح التجزئات السريعة للمهاجمين تجربة مليارات التخمينات بسرعة. المجزئات المخصصة تضيف معاملات تكلفة (work factors) لتتمكن من ضبط الأمان مع تحسن الأجهزة.

سياسات كلمات المرور التي ستراها عادةً

توفر الأطر عادة نقاط إضافة لفرض قواعد معقولة دون ترميزها في كل نقطة نهاية:

• سياسات التركيز على الطول (عبارات ممر أطول أفضل من قواعد التعقيد القصيرة)
• التحقق من الانكشاف مقابل قوائم كلمات مرور مسربة (مبدأيًا: "لا تسمح بكلمات مررت مكشوفة")
• تقييد المعدل وقفل مؤقت بعد محاولات فاشلة لتبطيء هجمات القوة الغاشمة

خيارات MFA وموازنات المقايضة

تدعم معظم المنظومات إضافة المصادقة متعددة العوامل كخطوة ثانية بعد التحقق من كلمة المرور:

• TOTP (تطبيقات المصادقة): مدعومة على نطاق واسع وتعمل دون اتصال؛ قابلة للصيد إذا خدع المستخدم لإدخال الأكواد.
• WebAuthn / passkeys: حماية قوية ضد التصيد وإعادة التشغيل؛ تجربة مستخدم ممتازة بعد الإعداد.
• رموز SMS: سهل التنفيذ لكن أضعف بسبب هجمات تبديل الشريحة (SIM-swap) واعتراض الرسائل—أفضل من لا شيء، لكنها ليست مثالية للحسابات عالية المخاطر.

استرداد الحساب بطريقة آمنة

إعادة تعيين كلمة المرور طريق هجوم شائع، لذا تشجع الأطر أنماطًا مثل:

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

قاعدة جيدة: سهل الاسترداد للمستخدمين الشرعيين، لكن مكلف للهجوم الآلي.

Middleware، الحراس، ودورة حياة الطلب

تتعامل معظم الأطر الحديثة مع الأمان كجزء من خط معالجة الطلب: سلسلة خطوات تعمل قبل (وأحيانًا بعد) المتحكم/المدير. تختلف المسميات—middleware, filters, guards, interceptors—لكن الفكرة متسقة: كل خطوة يمكنها قراءة الطلب، إضافة سياق، أو إيقاف المعالجة.

نموذج ذهني عملي لخط المعالجة

تدفق نموذجي:

1. التوجيه يحدد نقطة النهاية (مثلاً /account/settings).
2. مكونات المعالجة المسبقة تعمل (middleware/filters/interceptors).
3. المصادقة تحاول تحديد المتصل.
4. التفويض يقرر ما إذا كان المتصل المعرّف يمكنه الوصول.
5. المتحكم/المدير ينفّذ منطق الأعمال.
6. المعالجة اللاحقة قد تُحوّل الاستجابة أو تسجل تفاصيل.

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

أين تحدث المصادقة (الهوية أولًا)

المصادقة هي الخطوة التي يثبت فيها الإطار سياق المستخدم من الكوكيز، معرفات الجلسة، مفاتيح API، أو رموز Bearer. إذا نجحت، تخلق هوية نطاق الطلب—غالبًا معروضة ككائن user, principal, أو context.auth.

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

• معرف مستخدم ثابت
• أدوار/مطالبات (أحيانًا)
• بيانات وصفية مثل طريقة المصادقة أو عمر الجلسة

أين يحدث التفويض (فحوصات الأذونات)

يُنفَّذ التفويض عادةً كـ:

• حراس على مستوى المسار (مثلاً: "يجب أن تكون مسجل الدخول")
• فحوصات سياسات (مثلاً: "هل يمكنه تعديل هذا المستند؟") تُقيَّم بعد تحميل المورد

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

401 مقابل 403: التعامل مع الفشل بوضوح

تفصل الأطر بين حالتين شائعتين:

• 401 Unauthorized (غير مصادق): لم تُثبت هوية صالحة. غالبًا يُحوَّل المستخدم إلى صفحة تسجيل الدخول لتطبيقات المتصفح، أو يُعاد JSON خطأ للـ APIs.
• 403 Forbidden (ممنوع): الهوية معروفة لكنها تفتقر للصلاحية.

تجنَّب تسريب التفاصيل في ردود 403؛ ارفض الوصول دون شرح أي قاعدة فشلت.

نماذج التفويض: الأدوار، الأذونات، والسياسات

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

التحكم في الوصول حسب الدور (RBAC)

RBAC يعيّن للمستخدم أدوارًا (مثل admin, support, member) ويقيد الميزات بناءً على هذه الأدوار.

سهل الفهم والتطبيق، خاصة عندما توفر الأطر مساعدات مثل requireRole('admin'). لكن التسلسلات الهرمية للأدوار قد تُخفي امتيازًا: تغيير صغير في دور أب قد يمنح وصولًا واسعًا ضمن التطبيق.

RBAC يعمل بشكل جيد للتمييزات العامة والثابتة.

التفويض القائم على الأذونات (دقيق)

التحقق القائم على الأذونات يقارن فعلًا ضد مورد، عادةً على الشكل:

• فعل: read, create, update, delete, invite
• مورد: invoice, project, user، أحيانًا مع ID أو حالة الملكية

هذا النموذج أكثر دقة من RBAC؛ على سبيل المثال، "يمكنه تحديث المشاريع" يختلف عن "يمكنه تحديث المشاريع التي يملكها"—الأخير يتطلّب فحصًا لملكية البيانات.

تنفّذ الأطر هذا غالبًا عبر دالة مركزية "can?" تُستدعى من المتحكمات، الـ resolvers، العمال، أو القوالب.

التفويض القائم على السياسات (قواعد بشروط)

السياسات تجمع منطق التفويض إلى مُقَيِّمين قابلين لإعادة الاستخدام: "يمكن للمستخدم حذف تعليق إذا كان هو كاتبه أو كان مشرفًا." تقبل السياسات سياقًا (user, resource, request)، مما يجعلها مثالية ل:

• فحوصات الملكية
• قواعد خطة الاشتراك
• قيود زمنية أو خاصة بالمنظمة

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

التعليقات/السمات مقابل الفحوصات البرمجية

التعليقات (annotations) مثل @RequireRole('admin') تبقي النية قريبة من المعالج، لكنها قد تتفكك عندما تصبح القواعد معقدة.

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

الحمايات المدمجة الشائعة: CSRF، CORS، ورؤوس الأمان

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

CSRF: حماية تطبيقات المتصفح المعتمدة على الكوكي

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

أنماط شائعة:

• رمز متزامن (synchronizer token): يدرج الخادم رمزًا في النماذج ويتحقق منه عند POST/PUT/PATCH/DELETE.
• إرسال مزدوج للكوكي: يُخزن رمز CSRF في كوكي ويُرسل أيضًا في هيدر/الجسم؛ يتحقق الخادم من تطابقهما.

زادِم CSRF مع كوكيات SameSite (غالبًا Lax افتراضيًا) لتقليل الخطر، وتأكد من أن كوكي الجلسة HttpOnly وSecure حيث يلزم.

CORS: واجهات الـ API تحتاج قواعد صريحة

CORS ليس آلية مصادقة؛ إنه نظام أذونات عبر المتصفح. توفر الأطر عادة middleware/إعدادًا للسماح للأصول الموثوقة باستدعاء API الخاص بك.

تكوينات خاطئة لتجنبها:

• Access-Control-Allow-Origin: * مع Access-Control-Allow-Credentials: true (سيرفضها المتصفح وتدل على لبس)
• انعكاس أي رأس Origin دون قائمة سماح صارمة
• نسيان السماح بالرؤوس المطلوبة (مثل Authorization) أو الطرق المطلوبة، مما يجعل الطلبات تعمل عبر curl لكن تفشل في المتصفح

منع اختطاف النقر (clickjacking) ورؤوس الأمان

يمكن لمعظم الأطر تعيين قيم افتراضية آمنة أو تسهيل إضافة رؤوس مثل:

• X-Frame-Options أو Content-Security-Policy: frame-ancestors لمنع clickjacking
• Content-Security-Policy للتحكم بالأصول والسكريبتات
• Referrer-Policy وX-Content-Type-Options: nosniff

التحقق من المدخلات مقابل التفويض

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

أنماط حسب نوع التطبيق: SSR، SPA، الموبايل، والميكروسيرفيسز

النمط الصحيح للمصادقة يعتمد كثيرًا على مكان تشغيل الكود وكيفية وصول الطلبات إلى الـ backend. قد تدعم الأطر خيارات متعددة، لكن الافتراضات التي تبدو طبيعية في نوع تطبيق قد تكون غير مناسبة أو محفوفة بالمخاطر في آخر.

التطبيقات الخادمية (SSR)

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

قاعدة عملية: اجعل كوكيات الجلسة HttpOnly, Secure وبإعداد SameSite معقول، واعتمد فحوصات التفويض على الخادم لكل طلب يعرض بيانات خاصة.

تطبيقات الصفحة الواحدة (SPA)

تستدعي SPAs واجهات برمجة تطبيقات عبر جافاسكربت، مما يجعل خيارات الرموز أكثر حساسية. يفضل العديد من الفرق تدفق OAuth/OIDC الذي يمنح رموز وصول قصيرة العمر.

تجنّب تخزين الرموز طويلة العمر في localStorage إن أمكن؛ فهو يزيد مجال تأثير XSS. بديل شائع هو نمط backend-for-frontend (BFF): تتحدث الـ SPA إلى خادمك الخاص مع كوكي جلسة، والخادم يتبادل/يحتفظ بالرموز للنداءات إلى APIs الخارجية.

عملاء الموبايل

لا تعتمد تطبيقات الموبايل على قواعد الكوكي في المتصفحات بنفس الطريقة. تستخدم عادة OAuth/OIDC مع PKCE، وتخزن رموز التجديد في مخزن آمن للمنصة (Keychain/Keystore).

خطط لاسترداد "الجهاز المفقود": إبطال الرموز، تدوير بيانات الاعتماد، وتسهيل إعادة المصادقة—خاصة عند تمكين MFA.

الميكروسيرفيسز وبوابات الـ API

مع تعدد الخدمات، عليك الاختيار بين هوية مركزية وتنفيذ على مستوى الخدمة:

• مركزية عبر البوابة: تتحقق البوابة من الرموز وتنقل سياق الهوية.
• العمق الدفاعي: كل خدمة تتحقق من الرموز وتنفّذ التفويض لمواردها.

للمصادقة خدمة-إلى-خدمة، تندمج الأطر عادةً مع mTLS (هوية قناة قوية) أو OAuth client credentials (حسابات خدمة). المهم أن تتحقق من المتصل وتفوض ما يمكنه فعله.

الانتحال ووصول المدير

ميزات "انتحال المستخدم" الإدارية قوية وخطيرة. فضِّل جلسات انتحال صريحة، اطلب إعادة مصادقة/MFA للمسؤولين، وسجِّل دائمًا (من انتحل مَن، متى، وما الإجراءات التي اتُخذت).

الاختبار، القابلية للرصد، والأخطاء الشائعة لتجنبها

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

اختبار تدفقات المصادقة بدون إعدادات هشة

ابدأ بفصل ما تختبره:

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

توفر معظم الأطر مساعدة للاختبار حتى لا تضطر لبناء جلسات أو رموز يدويًا في كل مرة. أنماط شائعة تشمل:

• عميل اختبار يحتفظ بالكوكيز عبر الطلبات (مفيد للجلسات)
• مساعدات لتسجيل دخول مستخدم وهمي (أو إرفاق JWT/opaque token) بدون المرور عبر واجهة المستخدم
• fixtures/factories للمستخدمين، الأدوار، والموارد ليظل الاختبار مقروءًا

قاعدة عملية: لكل اختبار "المسار السعيد" أضف اختبارًا "يُرفَض" يبرهن أن فحص التفويض يعمل فعلاً.

القابلية للرصد: إثبات ما حصل، لا ما تأمل أن يكون قد حصل

عندما يخطئ شيء، تريد إجابات بسرعة وبثقة.

سجّل و/أو دوّن أحداثًا رئيسية:

• أحداث المصادقة: نجاح/فشل تسجيل الدخول، تحديات MFA، إعادة تعيين كلمات المرور، تجديد الرموز.
• رفضات التفويض: أي سياسة فشلت، على أي مورد، لأي مستخدم (تجنّب تسجيل الأسرار).
• معرفات الترابط: request ID تنتقل عبر السجلات والتتبعات لتتبع محاولة تسجيل دخول عبر الخدمات.

أضف مقاييس خفيفة أيضًا: معدل استجابات 401/403، زيادات في فشل تسجيل الدخول، وأنماط غير عادية في تجديد الرموز.

أخطاء شائعة الأطر لن تحميك تمامًا منها

• الثقة في ادعاءات العميل: لا تعتمد على أعلام الواجهة أو "الأدوار" من العميل—نفّذ دائمًا على الخادم.
• فحوص مفقودة على النقاط الثانوية: التصدير، المهام الخلفية، أدوات المسؤول، وAPIs "الداخلية" ما زالت بحاجة تفويض.
• نطاقات/أدوار واسعة جدًا: الصلاحيات "جيدة الآن" تميل إلى البقاء وتوسيع الامتياز.
• تسريب الرموز: تخزين الرموز في أماكن سهلة النسخ (السجلات، عناوين URL، localStorage) أو إرسالها لأطراف ثالثة.

عامل أخطاء المصادقة كتصرّف قابل للاختبار: إذا يمكن أن يتراجع، فله أن يملك اختباراً.