ما هو JWT؟ شرح رموز JSON Web Token

الرمز بعد فك ترميزه. الترويسة: {"alg":"ES256","typ":"JWT","kid":"stg-2026-09"}. الحمولة: iss هي https://auth.staging.bank.example، وsub هي C-100482، وaud هي accounts-api، وiat وnbf كلتاهما 1790748000 (30 سبتمبر 2026، الساعة ⁦06:00:00⁩ UTC)، وexp هي 1790834400 (1 أكتوبر 2026، الساعة ⁦06:00:00⁩ UTC)، وjti هي 7d2f0c9e-4b1a-4e8e-9a3d-5c6b2f1e8a40، وscope هي accounts:read transfers:write، وrole هي customer، وname هي Sara Al-Harbi، وnational_id هي 1234567890. ومقطع التوقيع 86 حرفاً، أي 64 بايتاً، وهو حجم توقيع ES256.

الخلاصة: خمسة عيوب (عمر الرمز، والبيانات الشخصية، ومكان الحفظ، وخوارزمية none في V3، وعدم فحص الجمهور في V6 وV7)، وثلاثة أسئلة للفريق (role، وهامش السماح في V4، وهل تفحص الواجهة scope، وهو سؤال يثيره V7)، وأربعة صفوف تتصرف فيها الواجهة تصرفاً صحيحاً (V1 وV2 وV5 وV8). ولم يحتج فك الترميز إلى أي مفتاح، وهذه هي الفكرة المحورية في الدليل: كل ما في الحمولة يستطيع قراءته كل من يحمل الرمز.

الترويسة وiss وaud وsub وjti وscope — صحيحة. فقيمة alg هي ES256 ومعها kid كما يشترط T1، وiss وaud مطابقتان لـ T2. وتساوي nbf مع iat أمر طبيعي: الرمز صالح منذ لحظة إصداره. وjti هي ما يجعل قائمة الرفض في T5 ممكنة.

عمر الرمز — عيب (T3). قيمة exp - iat هي 86400 ثانية، أي 24 ساعة بدلاً من 600 ثانية (10 دقائق)، فالرمز المسرَّب يمكن استخدامه يوماً كاملاً بدلاً من دقائق معدودة. وقد تعدّ أداة عامة لتحليل المطالبات عمراً يبلغ 24 ساعة مقبولاً، لكن أساس الاختبار هنا هو T3، وT3 يحدد 10 دقائق. الخطورة: رئيسي (Major). النتيجة المتوقعة: exp = iat + 600. وبعد الإصلاح تحقّق أيضاً من أن الرمز يُرفض بعد دقائقه العشر بقليل (مضافاً إليها هامش السماح من V4)، ومن أن تطبيق الويب يجدّده برمز التحديث دون أن يُخرج العميل من حسابه.

name وnational_id — عيب (T4). الحمولة مرمّزة لا مشفّرة: لقد قرأت للتو رقم هوية وطنية دون أي مفتاح، ويستطيع ذلك كل من يرى الرمز في تخزين المتصفح أو في سجل أو في وكيل (Proxy) أو في لقطة شاشة مرفقة بتقرير عيب. كما أن الرمز يُرسل مع كل طلب. الخطورة: رئيسي، وقد تجعلها قواعد حماية البيانات في المصرف أعلى. النتيجة المتوقعة: لا تحمل الحمولة إلا المطالبات التي يسردها T4. وهذه القاعدة تخص رمز الوصول؛ أما رمز الهوية فموجّه إلى تطبيق الويب ويجوز أن يحمل الاسم (انظر سؤال المطوّر).

role — سؤال للفريق. لا يذكرها T4، فإما أن المواصفة قديمة وإما أن المطالبة يجب أن تُحذف. والدور داخل رمز موقّع ليس مشكلة أمنية في ذاته لأن التوقيع يحميه، لكن بشرط أن تتحقق الواجهة من التوقيع بخوارزمية مثبّتة، ويُظهر V3 أنها لا تفعل ذلك اليوم: فمع none يستطيع أي شخص أن يكتب أي دور.

مكان الحفظ — عيب (T6). الرمز محفوظ في localStorage تحت المفتاح access_token، حيث يستطيع قراءته أي سكربت يعمل في الصفحة، بما في ذلك سكربت محقون عبر ثغرة برمجة عبر المواقع (XSS). ومع عمر يبلغ 24 ساعة يبقى الرمز المسروق صالحاً يوماً كاملاً ما لم يسجّل العميل خروجه (ويُظهر V8 أن تسجيل الخروج يبطله فعلاً). الخطورة: رئيسي. النتيجة المتوقعة: ملف تعريف ارتباط HttpOnly وSecure وSameSite. وحين يصل الإصلاح، الصق ترويسة Set-Cookie الخاصة به في أداة Cookie Analyzer لتتأكد من السمات الثلاث، وتحقّق من أن localStorage لم يعد يحتوي على الرمز.

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

V3 — عيب حرج (Critical) (T1 وT7). النتيجة المتوقعة: 401، لأن T1 لا يسمح إلا بـ ES256. والاستجابة 200 مع حسابات العميل C-100483 هي الإخفاق (Failure)، أما العيب الذي خلفه فهو أن الواجهة تدع ترويسة الرمز نفسها تختار الخوارزمية، ومع none لا تفحص أي توقيع إطلاقاً. ومع V2 يتضح أن التحقق يعمل حين تقول الترويسة ES256، ويتوقف حين تطلب الترويسة ذلك. فكل من يعرف رقم عميل أو يخمّنه يستطيع قراءة حساباته، ويستطيع أن يكتب أي مطالبة أخرى أيضاً، مثل scope تتضمن transfers:write.

V4 — سؤال. يسمح RFC 7519 للمتحقق بهامش سماح صغير لفروق الساعات بين الخوادم، لا يتجاوز عادةً بضع دقائق، ولا يذكر T3 شيئاً عن ذلك. ويُظهر V5 أن exp تُفحص، فالهامش يقع في مكان ما بين 40 ثانية و15 دقيقة. اسأل الفريق عن القيمة المضبوطة واطلب إضافتها إلى المواصفة، ثم اختبر الحدّ بقيمتين: رمز يُستخدم داخل الهامش مباشرة فيُقبل، ورمز يُستخدم بعد نهايته بثانية واحدة فيحصل على 401. وإن تبيّن أن الهامش أطول من بضع دقائق فأبلغ عنه عيباً، لأنه يطيل عمر كل رمز. V5 — صحيح: 401.

V6 — عيب (T2). النتيجة المتوقعة: 401، لأن aud هي cards-api لا accounts-api. فالرمز الصادر لخدمة يفتح خدمة أخرى، والرمز المسرَّب من واجهة البطاقات، أو من أي خدمة تتلقى مثل هذه الرموز، يفتح حسابات العملاء أيضاً. V7 — عيب له السبب الجذري نفسه: رمز الهوية موجّه إلى تطبيق الويب لا إلى واجهة API، ويقول الدليل إنه يجب ألا يُستخدم أبداً كرمز وصول. أبلغ عن V6 وV7 معاً في عيب واحد، «واجهة الحسابات لا تفحص aud»، مع الصفّين مثالين؛ فتقريران منفصلان يصفان السبب الجذري نفسه مرتين. الخطورة: رئيسي (وبعض الفرق تعدّه حرجاً). ويثير V7 سؤالاً أيضاً: رمز الهوية لا يحمل scope إطلاقاً ومع ذلك أعاد قائمة الحسابات، فاسأل هل تفحص الواجهة accounts:read، وأضف اختباراً لذلك.

V8 — صحيح: 401 بعد تسجيل الخروج، فقائمة الرفض المبنية على jti في T5 تعمل. لكنها لا تجعل عمراً يبلغ 24 ساعة بلا ضرر: فالعميل الذي لا يسجّل خروجه أبداً يترك رمزاً يبقى صالحاً يوماً كاملاً.

اختبارات تحقق لا يتضمنها السجل بعد (تكفي ثلاثة منها): ترويسة غُيّرت إلى HS256 مع رمز موقّع بسر HMAC من اختيارك، بأداة JWT Generator مثلاً، والنتيجة المتوقعة 401، وينبغي أن يُظهر سجل الواجهة أن الرفض كان بسبب الخوارزمية، لأن الخادم لا الترويسة هو من يختار الخوارزمية؛ وnone بحالة أحرف أخرى مثل None وNONE بعد الإصلاح، لأن الفحص الذي يحظر السلسلة none بحروفها هذه فقط قد يفوّتها؛ ورمز موقّع بمفتاح ES256 خاص بك بدلاً من مفتاح خادم المصادقة، والمتوقع 401، لأنه لا يجوز الوثوق إلا بالمفاتيح المنشورة في JWKS؛ ورمز من خادم المصادقة في بيئة التطوير (أي iss أخرى ومفتاح آخر)، ورمز تقع قيمة nbf فيه في المستقبل، والمتوقع لكليهما 401؛ ورمز وصول لا تتضمن scope فيه accounts:read، والمتوقع رفض الطلب (يوصي RFC 6750 بالرمز 403 عند عدم كفاية النطاق، فتأكد من الرمز المعتمد مع الفريق)؛ واختبار حدّ هامش السماح من V4. والرموز ذات المطالبات المختارة والتوقيع ES256 الصالح تحتاج إلى مساعدة فريق المصادقة على بيئة Staging، مثل عميل اختباري يصدرها؛ فاطلبها بدلاً من أن تتخطى هذه الاختبارات.

سؤال المطوّر: لا بالنسبة إلى national_id، وليس بهذه الصيغة بالنسبة إلى name. فالبيانات الشخصية لا مكان لها في رمز الوصول (T4). ورمز الهوية هو الرمز الموجّه إلى تطبيق الويب، وهو يحمل اسم العميل أصلاً (انظر V7)، فيمكن للصفحة أن تعرض الاسم من رمز الهوية أو من نقطة نهاية تعيد الملف الشخصي للعميل وصلاحياته، أما national_id فلا مكان له في أي من الرمزين. ثم إن قراءة رمز الوصول بـ JavaScript لا تنجح إلا لأن الرمز محفوظ في localStorage: فحين ينتقل إلى ملف تعريف ارتباط HttpOnly كما يشترط T6 لن تستطيع سكربتات الصفحة قراءته أصلاً، فلا بد من تغيير التصميم في كل الأحوال. أما إخفاء قائمة «التحويلات» فلا بأس به تسهيلاً في واجهة المستخدم، لكنه ليس ضابطاً أمنياً: فك الترميز ليس تحققاً، ويجب أن تفحص واجهة الحسابات transfers:write في كل طلب تحويل. وأضف اختباراً لذلك: طلب تحويل برمز لا تتضمن scope فيه transfers:write يجب أن يُرفض.

أبلغ عن V3 أولاً. مثال للعنوان: «واجهة الحسابات تقبل رموزاً غير موقّعة مع alg: none، وتغيير sub يعرض حسابات عميل آخر». وهو الأول لأنه لا يحتاج إلى رمز مسروق ولا إلى مفتاح، بل إلى رقم عميل فقط، ويكشف حسابات كل العملاء: الخطورة حرج، والأولوية هي الأعلى. ولأنه عيب أمني، أخبر المطوّرين فوراً واتبع إجراء فريقك للمسائل الأمنية، كتذكرة مقيّدة الوصول مثلاً. ثم عيب الجمهور (V6 وV7)؛ ثم العمر البالغ 24 ساعة والحفظ في localStorage، اللذان يحددان معاً كم من الوقت وبأي سهولة يمكن استخدام رمز مسروق؛ ثم البيانات الشخصية في الحمولة. وإن قدّم فريقك رقم الهوية الوطنية لأن قواعد حماية البيانات في المصرف تعدّه حادثة، فهذا سبب وجيه؛ المهم أن تتبع الأولوية الأثر. وبعد كل إصلاح أعد تنفيذ الصفوف المعنية اختباراتِ تأكيد (Confirmation testing)، وأعد تنفيذ V1 وV2 وV5 وV8 اختباراتِ انحدار (Regression)، لأن أي تغيير في شيفرة التحقق قد يكسر ما يعمل اليوم.

لتتحقق من عملك: يجب أن تكون لديك خمسة عيوب، ولا عيب في V1 أو V2 أو V5 أو V8. فإن صنّفت V2 عيباً، فأعد قراءة قسم «فك الترميز ليس تحققاً» في الدليل: الرفض بـ 401 لحمولة معدّلة هو بالضبط ما يجب أن يفعله المتحقق. وإن عددت تساوي nbf مع iat مشكلة، فأعد قراءة قسم المطالبات: nbf تحدد فقط متى أصبح الرمز صالحاً.