ما هو JWT؟ دليل شامل لـ JSON Web Tokens

ما هو JWT؟

JSON Web Token (JWT) هو معيار مفتوح (RFC 7519) يعرف طريقة مدمجة وقائمة بذاتها لنقل المعلومات بشكل آمن بين الأطراف ككائن JSON. رموز JWT هي تنسيق الرموز السائد في تطبيقات الويب الحديثة، وتُستخدم لكل شيء بدءًا من مصادقة المستخدم وتفويض API إلى تبادل البيانات الآمن بين الخدمات المصغرة.

كيف تعمل مصادقة JWT

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

تدفق المصادقة

1. يقوم المستخدم بتسجيل الدخول — يرسل العميل بيانات الاعتماد (اسم المستخدم وكلمة المرور) إلى خادم المصادقة.
2. يقوم الخادم بإنشاء JWT — يتحقق الخادم من بيانات الاعتماد، وينشئ JWT يحتوي على هوية المستخدم وصلاحياته، ويوقعه بمفتاح سري أو خاص، ويعيده إلى العميل.
3. يخزن العميل الرمز — يخزن العميل JWT، عادةً في localStorage أو sessionStorage أو كـ HTTP-only cookie.
4. يرسل العميل الرمز مع كل طلب — لكل طلب API لاحق، يضمن العميل JWT في ترويسة Authorization باستخدام نظام Bearer: Authorization: Bearer <token>.
5. يتحقق الخادم من الرمز — يتحقق الخادم من توقيع JWT، ويتحقق من وقت انتهاء الصلاحية، ويستخرج مطالبات المستخدم لتفويض الطلب.
6. لا حاجة للبحث عن الجلسة — لأن JWT يحتوي على جميع المعلومات اللازمة، لا يحتاج الخادم إلى الاستعلام عن قاعدة بيانات أو ذاكرة تخزين مؤقت لتحديد المستخدم.

لماذا هذا مهم

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

JWT مقابل المصادقة القائمة على الجلسات

| الجانب | مصادقة JWT | المصادقة القائمة على الجلسات | |--------|--------------------|------------------------------| | التخزين | جانب العميل (في الرمز) | جانب الخادم (في الذاكرة أو قاعدة البيانات) | | قابلية التوسع | لا حاجة لمخزن جلسات مشترك | يتطلب مخزن جلسات مشترك عبر النسخ | | النطاقات المتقاطعة | يعمل بشكل طبيعي عبر النطاقات | صعب مشاركة الجلسات | | ملاءمة الجوال | نعم (لا حاجة لـ cookies) | يتطلب دعم cookies | | الإلغاء | صعب (حتى تنتهي صلاحية الرمز) | سهل (حذف الجلسة من المخزن) | | حجم payload | أكبر لكل طلب (الرمز في الترويسة) | أدنى (معرف الجلسة فقط) |

لماذا تُستخدم JWT لأمان API

الخصائص التي تجعل JWT مناسبة للمصادقة تجعلها أيضًا مثالية لتأمين APIs.

عديمة الحالة وقابلة للتوسع

كل JWT يحمل جميع المعلومات التي يحتاجها الخادم لتفويض الطلب. لا توجد قاعدة بيانات جلسات للاستعلام عنها، ولا ذاكرة تخزين مؤقت للتحقق منها، ولا حالة للمزامنة عبر الخوادم. يمكن لموازنات التحميل توجيه الطلبات إلى أي نسخة خادم دون تنسيق.

النطاقات المتقاطعة والأصول المتقاطعة

يعمل JWT بشكل طبيعي عبر النطاقات والأصول المختلفة. يمكن استخدام رمز صادر من auth.example.com للوصول إلى api.example.com و admin.example.com. هذا يجعل JWT أساس أنظمة الدخول الموحد (SSO).

التفويض الدقيق

يمكن أن يتضمن payload JWT مطالبات مخصصة للأدوار والصلاحيات وعضويات المؤسسة:

{
  "sub": "user_abc123",
  "role": "admin",
  "permissions": ["read:users", "write:users", "delete:users"],
  "org_id": "org_xyz789",
  "iat": 1516239022,
  "exp": 1516325422
}

يقرأ خادم API هذه المطالبات مباشرة من الرمز دون أي بحث إضافي.

JWT للدخول الموحد (SSO)

الدخول الموحد هو أحد أكثر حالات استخدام JWT شيوعًا. في بنية SSO النموذجية:

1. يقوم المستخدم بتسجيل الدخول إلى مزود الهوية (IdP) — مثل Auth0 أو Okta أو Keycloak.
2. يصدر IdP رمز JWT موقعًا بمفتاحه الخاص.
3. يقدم المستخدم JWT هذا إلى تطبيقات متعددة.
4. يتحقق كل تطبيق من التوقيع باستخدام المفتاح العام لـ IdP.
5. يثق كل تطبيق في الرمز دون التواصل مع IdP في كل طلب.

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

أفضل ممارسات أمان JWT

بينما توفر JWT أسسًا قوية لأمان API، فإن التنفيذ الصحيح ضروري.

اجعل الرموز قصيرة العمر

عيِّن مطالبة exp (انتهاء الصلاحية) لمدة قصيرة — 15 دقيقة إلى ساعة واحدة لرموز الوصول. استخدم رموز تحديث أطول عمرًا (أيام أو أسابيع) للحصول على رموز وصول جديدة دون مطالبة المستخدم بإعادة المصادقة.

استخدم HTTPS دائمًا

JWT لا تشفر payload الخاص بها. يمكن لأي شخص يعترض الرمز فك تشفير وقراءة محتوياته. انقل دائمًا رموز JWT عبر HTTPS لمنع الاعتراض.

تحقق من كل شيء

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

خزّن الرموز بأمان

على جانب العميل، خزّن رموز JWT في HTTP-only cookies عندما يكون ذلك ممكنًا، أو في الذاكرة لتطبيقات الصفحة الواحدة. تجنب localStorage للرموز التي توفر الوصول إلى بيانات حساسة.

مفاهيم خاطئة شائعة حول JWT

"JWT مشفرة." — لا. JWT موقعة، وليست مشفرة. الـ payload مشفر بـ base64url، وهو قابل للعكس. توفر JWE (JSON Web Encryption) التشفير، لكنها مواصفة منفصلة لا تغطيها JWT القياسية.

"JWT تمنع CSRF." — ليس بمفردها. JWT في ترويسة Authorization تساعد، لكن إذا كان الرمز في cookie، فلا تزال هناك حاجة لحماية CSRF.

"JWT فقط للمصادقة." — تُستخدم JWT للمصادقة، ولكن أيضًا لتبادل بيانات التفويض، والجلسات عديمة الحالة، ومشاركة المعلومات الآمنة بين الخدمات.

فك تشفير واستكشاف JWT عبر الإنترنت

استخدم أداة فك تشفير JWT لفحص أي JSON Web Token. الصق رمزك وشاهد header و payload وخوارزمية التوقيع المفكوكة فورًا. تساعدك الأداة في فهم البيانات التي تحملها رموزك والتحقق من أنها منظمة بشكل صحيح.