فك JWT

JSON Web Token أو اختصاراً JWT (يُلفظ «جوت») هو معيار مفتوح موصوف في RFC 7519 صدر عام 2015. الفكرة بسيطة: تمثيل مجموعة من المعلومات (تُسمّى claims) داخل سلسلة نصّية مدمجة موقّعة رقمياً، بحيث يمكن نقلها بسهولة بين الخدمات والتحقّق من سلامتها دون الحاجة للرجوع إلى قاعدة بيانات.

أكثر استخدام شائع لـ JWT هو المصادقة (Authentication): عندما يسجّل المستخدم دخوله، يُصدر الخادم توكيناً يحتوي على هويّته. يرسل العميل هذا التوكين مع كل طلب لاحق، والخادم يتحقّق من توقيعه ويثق بمحتواه دون الحاجة إلى Session مخزّنة.

أيّ JWT يتكوّن من ثلاثة أجزاء مفصولة بنقاط:

eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxMjMifQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

الجزء الأوّل هو Header ويصف نوع التوكين وخوارزمية التوقيع، الجزء الثاني هو Payload ويحتوي على البيانات (claims)، والجزء الثالث هو Signature الذي يضمن أن الجزأين السابقين لم يُعبَث بهما.

الجزأن الأوّلان مرمَّزان بـ Base64URL (نسخة من Base64 آمنة في URLs) وليسا مشفّرَين. أي شخص يستطيع فكّ ترميزهما وقراءة محتواهما — ولا تضع فيهما بيانات حسّاسة مثل كلمات المرور أو أرقام البطاقات.

هو كائن JSON صغير يحتوي عادةً على حقلَين:

• alg: خوارزمية التوقيع (مثال: HS256 أو RS256 أو ES256).
• typ: نوع التوكين، شبه دائماً JWT.

أحياناً يحتوي على kid (Key ID) لتحديد المفتاح المستخدم عند وجود عدّة مفاتيح، أو cty (Content Type) إذا كان Payload يحتوي على JWT آخر متداخل.

مثال Header مفكوك: { "alg": "HS256", "typ": "JWT" }

Payload هو قلب التوكين. يحتوي على ما يُسمّى «Claims» — تأكيدات حول المستخدم أو السياق. هناك ثلاث فئات:

Claims مسجّلة (Registered) — اختياريّة لكنّها قياسية ومحجوزة في RFC 7519:

• iss (Issuer) — جهة الإصدار، مثلاً auth.example.com.
• sub (Subject) — الموضوع، عادةً معرّف المستخدم.
• aud (Audience) — الجهة المستهدفة للتوكين.
• exp (Expiration) — توقيت Unix لانتهاء الصلاحية.
• nbf (Not Before) — التوكين غير صالح قبل هذا التوقيت.
• iat (Issued At) — وقت الإصدار.
• jti (JWT ID) — معرّف فريد للتوكين (يفيد في إبطاله).

Claims عامّة (Public) — يحدّدها مطوّر الخدمة لكن يُفضَّل تسجيلها في IANA لتجنّب التضارب.

Claims خاصّة (Private) — يتّفق عليها الطرفان (مثلاً role، tenant_id، plan).

ملاحظة مهمّة: قيم exp و iat و nbf هي أرقام بالثواني منذ 1970-01-01 (Unix epoch)، وليست بالميلّي ثانية. هذا خطأ شائع في الكود.

التوقيع يُحسب بهذه الصيغة:

HMACSHA256( base64url(header) + "." + base64url(payload), secret )

أي أن الخادم يأخذ Header و Payload المرمَّزَين، يدمجهما بنقطة، ثمّ يحسب HMAC SHA-256 باستخدام المفتاح السرّي. الناتج يُرمَّز Base64URL ويُضاف كجزء ثالث.

عند استلام التوكين، يكرّر الخادم العمليّة نفسها ويقارن النتيجة بالتوقيع المرفق. لو تطابقا، فالتوكين سليم ولم يُعبَث به. لو غُيِّر حرف واحد في Payload، فإن التوقيع لن يتطابق.

HS256 (HMAC + SHA-256): الأبسط والأسرع. يستخدم مفتاحاً سرّياً واحداً مشتركاً بين كل الأطراف. ممتاز عندما يكون مُصدِر التوكين هو نفسه المُتحقِّق منه (تطبيق واحد).

RS256 (RSA + SHA-256): يستخدم زوج مفاتيح: خاص وعام. الخادم يوقّع بالمفتاح الخاص، وأيّ خدمة تستطيع التحقّق بالمفتاح العام. مثالي عندما يكون التوكين سيُتحقَّق منه في عدّة خدمات (Microservices) — لا داعي لمشاركة السرّ.

ES256 (ECDSA + SHA-256): مثل RS256 لكن باستخدام تشفير المنحنيات الإهليلجية. التوقيع أقصر بكثير والأداء أسرع. الخيار الحديث المفضّل في المعايير الجديدة (OpenID Connect، WebAuthn).

القاعدة العمليّة: إن كان كل شيء داخل تطبيق واحد، استخدم HS256. إن كنت توزّع التحقّق على خدمات متعدّدة أو على أطراف خارجية، استخدم RS256 أو ES256.

• Authentication بدون حالة (Stateless): APIs، تطبيقات الموبايل، Single Page Apps.
• Single Sign-On (SSO): توكين موحَّد يُقبل عبر عدّة خدمات.
• Authorization بين خدمات: service-to-service mTLS أو OAuth2 client credentials.
• تبادل معلومات موقّعة: روابط إعادة تعيين كلمة مرور، تأكيد بريد، دعوات بفترة صلاحية.
• OpenID Connect: ID Token هو JWT قياسي يصف هويّة المستخدم.

ليس هناك «أفضل» مطلق. الفرق الجوهري:

Session تقليدية: الخادم يخزّن حالة الجلسة في قاعدة البيانات أو في Redis، والمتصفّح يحمل فقط معرّف الجلسة داخل Cookie. لإبطال الجلسة، تحذف السجلّ من المخزن. التحقّق يتطلّب طلب قاعدة بيانات في كلّ مرّة.

JWT: كل المعلومات داخل التوكين. الخادم لا يخزّن شيئاً — مجرّد التحقّق من التوقيع. سريع، قابل للتوسّع، ممتاز للـ APIs. لكنّ إبطال التوكين قبل انتهاء صلاحيّته صعب — تحتاج آليّة قائمة سوداء أو تقصير العمر مع استخدام Refresh Token.

القاعدة: للتطبيقات Monolithic مع جلسات طويلة، Session أبسط وأكثر أماناً. للـ APIs الموزّعة وتطبيقات الموبايل، JWT خيار طبيعي — مع التزام صارم بتقصير المدّة.

في 2015 اكتُشف أنّ كثيراً من مكتبات JWT كانت تقبل توكينات بـ alg: "none" — أي بدون توقيع — وتعتبرها صحيحة. المهاجم يستطيع ببساطة أخذ توكين موجود، تغيير الـ Header إلى { "alg": "none" }، تعديل Payload (مثلاً جعل role = admin)، وحذف التوقيع. النتيجة: تصعيد صلاحيّات كامل.

الحماية: اقفل قائمة الخوارزميات المقبولة صراحةً في الكود (whitelist). لا تثق بحقل alg القادم من Header. مثلاً في Node.js عبر jsonwebtoken: مرّر { algorithms: ['RS256'] } دائماً.

ثغرة ثانية مشهورة: خلط HS256 و RS256. لو كان الخادم يقبل HS256 و RS256، يستطيع المهاجم أخذ المفتاح العام (متاح للجميع) واستخدامه كـ «مفتاح سرّي» لـ HS256 — فيقبل الخادم توقيعه. الحل: قائمة بيضاء واحدة فقط.

• وضع بيانات حسّاسة في Payload: الـ Payload مقروء — أي شخص يفكّ التوكين يراه. لا تضع كلمات سرّ، أرقام بطاقات، أرقام هويّة وطنية.
• التوكين طويل العمر بدون آليّة إبطال: توكين عمره 30 يوماً تسرّب = 30 يوماً من الوصول غير المصرّح به. استخدم Access Token قصير (15 دقيقة) + Refresh Token.
• عدم التحقّق من exp و aud و iss: فكّ التوقيع لا يكفي. تحقّق من أن التوكين لم ينتهِ، أنّه صادر من جهتك، وأنّه موجَّه إلى خدمتك.
• تخزين التوكين في localStorage: عرضة لـ XSS. الأفضل HttpOnly Cookie مع SameSite.
• عدم تدوير المفتاح السرّي: اجعل المفاتيح قابلة للتدوير عبر kid، خصوصاً في الإنتاج.
• مفتاح سرّي ضعيف: لا تستخدم «secret123» في HS256. ولّد مفتاحاً عشوائياً بطول 256 بت على الأقل.

ثلاثة خيارات شائعة، لكلّ منها تنازلات:

• HttpOnly Cookie + Secure + SameSite=Lax: الأكثر أماناً ضدّ XSS لأنّ JavaScript لا يستطيع قراءة التوكين. تحتاج حماية CSRF.
• localStorage: سهل لكن أيّ ثغرة XSS تكشف التوكين. غير موصى به للتوكينات الحسّاسة.
• sessionStorage: أفضل قليلاً من localStorage لأنّه يُمسح بإغلاق التبويب، لكنّه ما زال عرضة لـ XSS.

للتطبيقات الويب الحديثة: HttpOnly Cookie مع Refresh Token قصير العمر هي البنية الموصى بها من فِرَق OWASP و Auth0.

الأداة في أعلى الصفحة محلّية بالكامل. تفكّ التوكين باستخدام atob داخل متصفّحك دون إرسال أيّ بايت إلى خادم. آمن أن تفحص توكينات الإنتاج هنا.

مع ذلك، تذكّر أن أيّ موقع آخر يدّعي «فكّ JWT» قد يحتفظ بنسخة من التوكين — فاحرص على فحص توكينات الإنتاج فقط في أدوات تثق بها أو محلّياً في الـ Console.

الأداة تفكّ المحتوى فقط ولا تتحقّق من التوقيع، لأن التحقّق يتطلّب المفتاح السرّي/العام الذي يبقى داخل خوادمك. للتحقّق الفعلي من التوقيع استخدم مكتبة مثل jsonwebtoken أو jose.

هل JWT مشفَّر؟

لا — JWT القياسي موقَّع فقط، أي محميّ ضدّ التعديل لكنّه مقروء. إذا أردت إخفاء المحتوى، استخدم JWE (JSON Web Encryption).

ما الفرق بين JWT و OAuth2؟

OAuth2 إطار عمل للتفويض، و JWT صيغة توكين قد تُستخدم داخله. كثير من تطبيقات OAuth2 تستخدم JWT كـ Access Token، لكن OAuth2 يقبل صيغاً أخرى.

متى ينتهي JWT؟

عندما يصل التوقيت إلى قيمة exp في Payload. لا توجد آليّة إبطال مدمجة قبل ذلك — لذا اجعل عمر Access Token قصيراً (5-15 دقيقة).

هل أحتاج HTTPS مع JWT؟

دائماً. التوكين مكشوف على السلك، وأيّ شخص يلتقطه يستطيع انتحال هويّة المستخدم. HTTPS غير قابل للتفاوض.

ما هو Refresh Token؟

توكين طويل العمر (أيام أو أسابيع) يُحفظ في HttpOnly Cookie، يستخدمه العميل للحصول على Access Token جديد دون إعادة تسجيل الدخول. يُخزَّن مرجعه في قاعدة البيانات لإمكانية إبطاله.

الأداة في أعلى الصفحة تفكّ أي JWT وتعرض Header و Payload بشكل JSON منسَّق، تحسب الوقت المتبقّي حتى انتهاء الصلاحية تلقائياً، وتنبّهك للمشاكل الأمنية مثل alg=none أو غياب exp. كل المعالجة داخل متصفّحك ولا تغادر بياناتك جهازك.