JWT هو مجرد Base64 داخل ملابس مُلَطَّة — قم بفك تشفيره عبر الإنترنت في ثوانٍ

أنت تنظر إلى علامة شبكة. هناك رأس طلب يحمل Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c وأول رد فعل هو: "ما هذا حتى؟"

الخبر الجيد: معظم هذه السلسلة هو مجرد Base64. القطعة المخيفة ترتدي ملابس ملابس ملابس، تبدو أكثر غموضًا مما هو عليه. دعنا نزيلها.

ما هو JWT بالفعل

يُعرف جزء من توكين ويب JSON على أنه ثلاث قطع مُشفّرة بـ Base64url مجمعة مع نقاط:

• رأس الصفحة – خوارزمية ونوع التوكين (مثلاً {"alg":"HS256","typ":"JWT"})
• الحمولة – البيانات: رقم المستخدم، أدوار، انتهاء الصلاحية، أي شيء قرر الخادم تضمينه
• إمضاء – الجزء الذي يُفرض فيه الحماية الحقيقية

الرأس والحمولة لا يُشفَّر. فهي مُشفّرة بـ Base64url، أي أن أي شخص يمتلك التوكين يمكنه قراءتها دون مفتاح. فقط التوقيع يمنع التلاعب: تغيير حرف واحد في الحمولة يجعلها غير صالحة.

لإعادة تشفير الحمولة الآن: احصل على القطعة الثانية (بين النقطتين)، وضَعها في مُفكّك Base64، وسترى بيانات JSON بسيطة. هذا هو كل شيء. هذا هو الحيلة السحرية.

كيفية تشفير JWT في ثوانٍ

الطريقة الأسرع: انسخ توكينك إلى مُفكّك JWT في IOTools. يقسم التوكين إلى ثلاث جزئيات، ويُفكك كل منها، ويعرض الرأس والحمولة كـ JSON مُرَتَّب — دون حساب، دون إعداد، دون "تسجيل الدخول لفتح المُفكّك".

ما ستجد فورًا في حمولة عادية:

• sub – الموضوع (غالبًا رقم المستخدم)
• iat – وقت الإصدار (بصيغة Unix)
• exp – وقت انتهاء الصلاحية
• iss – المُصدر
• أي بيانات مخصصة تضعها واجهة برمجة التطبيقات: أدوار، صلاحيات، مستوى الخطة، إلخ.

إذا كنت بحاجة فقط لمعرفة ما إذا كان التوكين قد انتهت صلاحيته دون تثبيت مُفكّك كامل، فإن مُدقق انتهاء صلاحية JWT يقرؤة exp البيان وينبغي لك أن تعرف دقة الحياة المتبقية — أو وقت وفاته.

الثلاثة مشاكل تُحرق المطورين

1. التوقيت الذي نسيت التحقق منه

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

2. ارتباك الخوارزمية

الحقل في الرأس يخبر المُتحقق بخوارزمية الاستخدام. بعض المكتبات القديمة للـ JWT كانت تقبل alg وتجعل التحقق غير مطلوب تمامًا — تُزيل التوقيع وتعتبر أي حمولة صالحة. هذه هجوم معروف. تأكد دائمًا أن مكتبة التحقق تفرض قائمة محددة للخوارزميات وتحظر {"alg":"none"} أخرى: مثال آخر: RS256 (متمايز) مقابل HS256 (متماثل). يمكن للاختراق أن يعلم مفتاحك العام ويُصنع توكينًا من خلال تغيير الرأس إلى none.

وتوقيعه باستخدام المفتاح العام كمفتاح سري — إذا كانت المكتبة تثق بذاتية الرأس HS256 الحقل. الحل: قم بتكوين مكتبة بخوارزمية محددة، وليس "ما يكتب في التوكين". alg 3. أسرار في الحمولة

لأن الحمولة مُشفّرة بـ Base64 وليس مُشفّرة، أي شيء تضعه هناك يمكن قراءته من قبل العميل (وأي شخص يحتج على توكين بطرق بسيطة، رغم أنك تستخدم HTTPS في كل الأماكن، صحيح؟). لا تضع كلمات مرور، بيانات شخصية، أو معلومات داخلية في بيانات التوكين. الحمولة مخصصة للبيانات المصادقة — وليس مكان لتخزين بيانات حساسة.

فك توكين من تطبيقك الخاص وشاهد ما داخله. قد تفاجأ بأشياء أُدخلت من قبل مطور سابق منذ سنوات.

JWT مقابل توكينات الجلسة: ما الذي يميزهما حقًا

الجدل المستمر. إليك مقارنة مباشرة:

JWT

	توكين جلسة	أين توجد الحالة
داخل التوكين (مُستقل)	على الجانب الخادم (قاعدة بيانات أو ذاكرة)	إلغاء التوكين
صعب — يبقى صحيحاً حتى	إلا إذا أدارت قائمة ممنوعة exp سهل — احذف سجل الجلسة	مثالي لأنظمة موزعة؛ لا حاجة لخادم جلسة مشترك
قابلية التوسع	يتطلب جلسة ملتصقة أو نظام مشترك (مثل Redis، إلخ)	رؤية محتوى الحمولة
يمكن للعميل قراءة البيانات (غير مشفّرة)	مُستحيل للعميل	خطر التخزين
localStorage عرضة للهجوم عبر XSS؛ Cookie httpOnly أمن أكثر	Cookie httpOnly (المنهج القياسي)	حجم التوكين
أكبر — يحمل كل البيانات	أصغر — مجرد رقم	أفضل للاستخدام في
الواجهات، الخدمات الصغيرة، التحقق عبر الحدود	التطبيقات التقليدية التي تُعرض على الخادم	لا توجد طريقة أفضل. يُظهر JWT فعالية في التحقق من الحالة دون تكامل بين عدة خدمات. أما توكينات الجلسة فهي أبسط عندما تتحكم بالكامل في النظام وتحتاج إلى إلغاء فوري (مثلاً "تسجيل الخروج من كل الأماكن" في حالة حادث أمني).

استكشاف توكينات JWT في سيناريوهات العمل الحقيقية

هنا تسلسل عادة يحدث عندما يفشل تطبيق يستخدم توكينات JWT:

نسخ التوكين

1. من طلب فشل (رأس التحقق، معلمة الاستعلام، أو ملف تعريف - أي مكان يضعه تطبيقك) الإدخال إلى
2. لرؤية البيانات الخام مُفكّك JWT هل التوكين انتهت صلاحيته؟ استخدم
3. أكمل exp إذا لم ترغب في حساب توقيت Unix بذكاء مُدقق انتهاء الصلاحية هل يتطابق المُصدر والجمهور مع ما تتوقعه من الخدمة؟
4. أكمل iss و aud تحقق من الخوارزمية
5. في الرأس - هل تتطابق مع إعداد الخادم؟ تحقق من صيغة التوقيع
6. هل هناك 3 أجزاء؟ 2؟ قد يظهر توكين مُختل بـ 2 أجزاء دون توقيع أغلب حالات تدقيق JWT تنتهي عند الخطوة 3. كان التوكين مُصدرًا بفترة صلاحية قصيرة، محفوظًا في مكان ما، ووصل إلى انتهائه. هذه حالة بسيطة وشائعة.

التوقيع: الجزء الوحيد الذي يهم

يُحسب كالتالي:

. يُولد الخادم التوقيع عند إصدار التوكين. عند التحقق، يعيد حساب نفس الـ hash ويقارن. إذا تم تغيير أي جزء من الحمولة - حتى حرف واحد - فلن يتطابق الـ hash ويُرفض التوكين. HMACSHA256(base64url(header) + "." + base64url(payload), secret)هذا هو السبب الذي يجعل فك التوكين لقراءة البيانات آمنًا وسهلًا، ولكن تضمينه دون المفتاح غير ممكن. Base64 هي المظهر؛ التوقيع هو مفتاح الباب.

لخوارزميات غير متماثلة (RS256، ES256)، يكون مفتاح التوقيع مفتاحًا سريًا لا يترك الخادم. يكون مفتاح التحقق مفتاحًا عامًا يمكن لأي خدمة استخدامه - لا حاجة لسرّ مشترك. هذه هي البنية المناسبة للاستخدام في خدمات ميكرو التي تحتاج إلى تحقق من التوكين من قبل عدة خدمات ولكن لا يُسمح بصدورها من أكثر من خدمة.

JWT هو مجرد Base64 بملابس ملابس - فكها عبر الإنترنت في ثوانٍ 2

قد يعجبك أيضاً