فاكّ JWT

JSON Web Token هو ثلاث شرائح مُرمَّزة بـ base64url مفصولة بنقاط: header.payload.signature. الرأس والحمولة JSON؛ والتوقيع ناتج HMAC أو RSA/ECDSA على الشريحتين الأُوليين. تقوم الأداة بالتقسيم عند النقاط، وفك ترميز كل جزء بـ base64url، وتحليل JSON، وعرض المطالبات الزمنية القياسية مثل exp كتواريخ مقروءة. لا تتحقق من التوقيع — راجع الأسئلة الشائعة أدناه للسبب.

مثال

الرمز التوضيحي من مواصفات JWT (موقَّع بـ HS256 بالسر your-256-bit-secret):

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

الرأس المفكوك:

{
  "alg": "HS256",
  "typ": "JWT"
}

الحمولة المفكوكة:

{
  "sub": "1234567890",
  "name": "John Doe",
  "iat": 1516239022
}

لماذا يُعلَّم توقيع JWT الخاص بي على أنه غير صالح؟

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

• سر أو مفتاح غير صحيح. اختلاف حرف واحد في سر HMAC يُنتج توقيعًا مختلفًا كليًا. تأكد أن متغير البيئة JWT_SECRET في خدمة التحقق يطابق ما في المُصدِر.
• اختلاف الخوارزمية. لا يمكن التحقق من رمز موقَّع بـ HS256 باستخدام RS256. راجع المطالبة alg في الرأس وتأكد من إعداد المُحقِّق بنفس الخوارزمية.
• رمز منتهٍ. حتى JWT الموقَّع بشكل صحيح يفشل التحقق حين يمضي وقت exp. يُظهر ملخص المطالبات الزمنية ذلك بوضوح بعد فك الترميز.
• فرق ساعات (clock skew). nbf (لا قبل) في المستقبل القريب مع انحراف ساعة الخادم يسبب أخطاء "الرمز غير صالح بعد". اسمح بهامش بسيط (مثلاً 60 ثانية) في المُحقِّق.
• مسافات في الرمز المُلصق. قد يحتوي النسخ واللصق على مسافة في البداية أو سطر جديد في النهاية. يجب أن يكون JWT تمامًا header.payload.signature بلا مسافات محيطة.
• alg: none. إذا ورد في الرأس "alg": "none" فالرمز غير موقَّع. ارفض ذلك في المُحقِّق — لا تعتبره صالحًا أبدًا.

هل يمكن لهذه الأداة التحقق من توقيع JWT؟

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

ماذا يوجد في كل من شرائح JWT الثلاث؟

JWT هو header.payload.signature. الرأس JSON يصف الخوارزمية (alg) ونوع الرمز. الحمولة JSON تحوي مطالبات مثل sub وiat وexp. التوقيع هو ناتج توقيع الشريحتين الأُوليين بالسر أو المفتاح الخاص مُرمَّزًا بـ base64url. الشريحتان الأوليان مُرمَّزتان فقط، وليستا مُشفَّرتين.

انتهى JWT الخاص بي — كيف أتأكد؟

انظر إلى المطالبة exp في الحمولة. هي طابع زمني Unix بالثواني. إذا كان Date.now() / 1000 أكبر من exp فالرمز منتهٍ. تعرض الأداة exp وiat وnbf تحت الحمولة كتواريخ مقروءة لتلحظ الأمر بنظرة واحدة دون حساب يدوي.

ما معنى alg: none ولماذا هو خطير؟

alg: none ميزة في JWT يكون فيها التوقيع فارغًا ولا يُفحص. قبلت كثير من المكتبات تاريخيًا مثل هذه الرموز، مما مكّن المهاجمين من تزوير JWT ببناء حمولة وتعيين alg إلى none. إن رأيت هذه القيمة في الرأس فالرمز غير موقَّع — لا تثق بأي خادم يقبله.

هل تحفظون JWT التي ألصقها هنا؟

لا. لا نحفظ أي رمز تلصقه في الفاكّ. ما تُدخله يُحذف عند إغلاق علامة التبويب أو تحديثها — لا سجلات، ولا أي أثر لدينا للرموز التي فحصتها. مع ذلك، يمنح JWT وصولًا حتى exp: عامله كأنه كلمة مرور وبدّل أي رمز إنتاجي تُصحِّحه.

يعرض قسم التوقيع كتلة غير مقروءة — هل هذا طبيعي؟

نعم. التوقيع ناتج ثنائي من HMAC أو RSA/ECDSA مُرمَّز بـ base64url. ليس مقصودًا أن يُقرأ — إنما يخدم كتحقق تشفيري. ما تتعامل معه هو الرأس والحمولة بعد فك الترميز كـ JSON. توقيع فارغ يعني أن الرمز غير موقَّع (alg: none).