كيف تعمل مصادقة JWT — رموز بلا جلسات
كيف تعمل مصادقة JWT، موضّحةً على لوحة تفاعلية: بيانات الاعتماد، والرمز الموقّع ذو الأجزاء الثلاثة، وكيف يُتحقّق من كل طلب دون حالة مخزّنة.
الـJSON Web Token بيان موقّع وقائم بذاته عن هويتك: ينشئه الخادم مرة واحدة عند تسجيل الدخول، ثم يثبت كل طلب لاحق نفسه بالرمز بدل الاستعلام عن جلسة.
كيف تعمل مصادقة JWT — رموز بلا جلسات
لوحة FlowJam التفاعلية لهذا الشرح — كل مسار وصف وسهم أعلاه جزء من مخطط QueryChart حقيقي يمكنك فتحه وتعديله.
كيف تقرأ هذا الشرح المرئي
- اقرأ من اليسار إلى اليمين: تسجيل الدخول، ثم إصدار الرمز، ثم الطلبات المُصادَق عليها.
- يتناوب صف المستخدم وصف الخادم، فكل سهم إما أن يكون المستخدم يقدّم شيئاً أو الخادم يقرّر شيئاً.
- شكلا الرفض في أعلى عمودَي تسجيل الدخول والطلبات هما نقطتا نهاية الإخفاق — وكل قرار على اللوحة يغذّي واحدة منهما.
إثبات هويتك
«يقدّم المستخدم بريده الإلكتروني وكلمة مروره» و«يتحقّق الخادم من بيانات الاعتماد مقابل قاعدة البيانات» هما الموضع الوحيد الذي توجد فيه كلمة مرور في المسار كله. وقرار «هل بيانات الاعتماد صالحة؟» ينقسم إلى المسار السليم وإلى «رُفض تسجيل الدخول». هذه مصادقة تقليدية — أما جزء JWT فيبدأ بعد نجاح التحقّق من بيانات الاعتماد.
سكّ الرمز
«يبني الخادم الترويسة والحمولة والتوقيع» هو قلب الشرح المرئي. فالترويسة تسمّي خوارزمية التوقيع؛ والحمولة تحمل المطالبات — معرّف المستخدم، وانتهاء الصلاحية، وأي صلاحيات؛ والتوقيع يربطها معاً حتى لا يمكن تغيير الرمز دون أن يُكتشف ذلك. وخطوة «يوقّع الخادم الرمز بمفتاحه السري» هي الفعل الذي يجعله جديراً بالثقة: فلا يستطيع إنتاج توقيع صالح إلا خادم يملك المفتاح السري. وخطوة «يستلم العميل الـJWT ويخزّنه» تسلّم الناتج إلى العميل، حيث يبقى حتى انتهاء صلاحيته.
التحقّق دون حالة
تبدأ خطوة «يرسل العميل الـJWT في ترويسة Authorization» الجزء المتكرر من المسار، وخطوة «يتحقّق الخادم من التوقيع بمفتاحه السري» هي سبب قابلية هذا الأسلوب للتوسّع: فإعادة فحص التوقيع عملية حسابية لا استعلام من قاعدة بيانات، فلا مخزن جلسات مركزي يُرجَع إليه. ويضيف قرار «هل التوقيع صالح والرمز غير منتهي الصلاحية؟» فحص الوقت، فيوجّه الرموز غير الصالحة أو المنتهية إلى «رُفض الطلب برمز 401» والصالحة إلى «يثق الخادم بالمطالبات وينفّذ الطلب».
العلاقات الرئيسية والخلاصات
- الـJWT ثلاثة أجزاء — ترويسة وحمولة وتوقيع — تصلها نقاط؛ والحمولة قابلة للقراءة لكن أي عبث بها ينكشف.
- التوقيع يحوّل الهوية إلى قدرة: فحيازة رمز صالح لم تنته صلاحيته هي ما يصادق على الطلب.
- التحقّق يجري دون حالة مخزّنة — فإعادة حساب التوقيع تحلّ محلّ الاستعلام عن الجلسة.
- على العميل أن يخزّن الرمز بأمان وأن يرسله مع كل طلب، فانتهاء صلاحيته هو الحد الأمني الحقيقي.
- يتكامل JWT مع OAuth: فـOAuth يقرّر ما يجوز للعميل فعله، وJWT صيغة شائعة للرمز الذي يحمل ذلك القرار.
متى تستخدم هذا الشرح المرئي
- تعليم فريق خلفية جديد لماذا لا حاجة إلى جدول جلسات، وما الذي يثبته التوقيع فعلاً.
- الاختيار بين JWT والجلسات المخزّنة على الخادم لخدمة يجعل فيها التوسّع الأفقي الحالة المشتركة عبئاً.
- مراجعة مطالبات الرمز — انتهاء الصلاحية والمُصدِر والجمهور — قبل الوثوق به داخل خدمة مصغّرة.
كيف تعمل
اسرد المطالبات التي تحملها رموزك فعلاً
على خطوة «الترويسة والحمولة والتوقيع»، أضف المطالبات الحقيقية التي تصدرها — sub وexp وiss وaud وأي صلاحيات — ليوثّق المخطط عقد الرمز لديك.
أضف مسار التحديث
أدرج مسار رمز التحديث بعد انتهاء الصلاحية: يقدّم العميل رمز تحديث طويل العمر، ويسكّ الخادم رمز وصول جديداً، وتستمر الجلسة دون تسجيل دخول جديد.
سمِّ استراتيجية مفاتيح التوقيع لديك
علّق على خطوة التوقيع بإدارة المفاتيح لديك — سر مشترك واحد (HS256) أو زوج مفاتيح عام وخاص (RS256) — فهذا الاختيار يحدّد من يستطيع التحقّق من الرمز.
أضف فروع الإخفاق
أدرج الرموز المنتهية والمشوّهة والمعبوث بها كنقاط نهاية صريحة، ليغطي المخطط حالات الرفض التي يعيدها API لديك فعلاً.
الأسئلة الشائعة
ما هو JWT وماذا يحتوي؟
الـJSON Web Token سلسلة نصية من ثلاثة أجزاء تفصلها نقاط: ترويسة تذكر خوارزمية التوقيع، وحمولة من المطالبات عن المستخدم وعن عمر الرمز، وتوقيع. والترويسة والحمولة هما JSON مُرمَّز بـbase64 — يستطيع أي أحد قراءتهما — والتوقيع هو ما يمنع تغييرهما بلا مفتاح التوقيع.
لماذا تُسمّى مصادقة JWT عديمة الحالة؟
لأن الخادم لا يخزّن شيئاً عن الجلسة. فكل طلب يصل ومعه الرمز، ويتحقّق الخادم من التوقيع ومن انتهاء الصلاحية في الحال. فلا جدول جلسات يُستعلم عنه ولا حالة تُنسخ بين الخوادم، وهذا ما يجعل هذا الأسلوب قابلاً للتوسّع أفقياً. والثمن أن الرمز لا يمكن إلغاؤه قبل انتهاء صلاحيته دون آلية إضافية.
هل يبقى JWT آمناً إذا كان بإمكان أي أحد قراءة الحمولة؟
القراءة والثقة أمران مختلفان. الحمولة غير مشفَّرة — فلا تضع فيها أسراراً — لكن التوقيع يعني أن أي تعديل يُبطل الرمز، فلا يستطيع العميل تغيير مطالباته الخاصة. وأما أمان النقل فالرمز ينتقل داخل HTTPS، والبيانات التي يمنح الوصول إليها يحميها خادم الموارد بفرضه المطالبات.
ما العلاقة بين JWT وOAuth؟
كل منهما يحلّ نصفاً مختلفاً من المشكلة. فـOAuth هو بروتوكول التفويض — أي كيف يحصل العميل على الإذن وعلى الرمز. وJWT صيغة رمز. وفي الواقع كثيراً ما تكون رموز وصول OAuth بصيغة JWT: يوقّع خادم التفويض رمز JWT يحمل الصلاحيات، وتتحقّق منه خوادم الموارد. وتغطّي هذه اللوحة نصف المصادقة؛ أما الشرح المرئي الخاص بـOAuth فيغطّي نصف التفويض بالإنابة.
عدّل هذا الشرح المرئي في QueryChart (FlowJam)
افتح لوحة JWT هذه نفسها كمخطط خاص بك، وأعد تسمية العميل والخادم لتطابق خدماتك، وعلّق على مطالباتك أنت.