تعطّل نظام المصادقة لديك في بيئة الإنتاج للتو. يظهر للمستخدمين خطأ “Invalid Token”، وعليك أن تعرف السبب — وبسرعة. تفتح الرمز JWT، فإذا به يبدو كطلاسم لا معنى لها: ثلاث كتل من الأحرف العشوائية تفصل بينها نقاط. البيانات موجودة في الداخل، لكنك لا تستطيع قراءتها بدون محلل (parser).
محلل JWT (JWT Parser) هو أداة متخصصة تفكّك الأجزاء الثلاثة لرمز JSON Web Token — وهي Header وPayload وSignature — وفقًا لمعيار RFC 7519. بحلول أبريل 2026، تقوم هذه المحللات بفك ترميز البيانات المشفّرة بـ Base64URL والتحقق من التوقيعات باستخدام الأسرار أو المفاتيح العامة لضمان عدم العبث بالرمز، مما يصدّ تهديدات مثل هجوم “alg: none”.
ما الذي يفعله محلل JWT فعليًا
تخيّل محلل JWT كمترجمٍ بين لغتين. يأخذ سلسلة طويلة وغير شفافة ويعيدها إلى كائنات JSON قابلة للقراءة. هذا أمر أساسي لإدارة هويات المستخدمين وتأمين تبادل البيانات في التطبيقات الحديثة.
داخليًا، يبحث المحلل عن النقطتين (.) اللتين تقسمان الرمز إلى ثلاثة أقسام:
| القسم | الغرض | مرمّز؟ | قابل للقراءة بدون مفتاح؟ |
|---|---|---|---|
| Header | بيانات وصفية: خوارزمية التوقيع (HS256، RS256) | Base64URL | نعم |
| Payload | المطالبات (claims): بيانات المستخدم، الانتهاء، الأدوار | Base64URL | نعم |
| Signature | ختم رقمي يثبت الأصالة | HMAC/RSA | لا — يتطلب مفتاحًا |
فك التشفير خطوة بخطوة: ماذا يحدث في الداخل
لنتتبّع رمزًا حقيقيًا. خذ مثال JWT التالي:
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4iLCJpYXQiOjE3MDAwMDAwMDB9.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
الخطوة 1: القسمة على النقاط
[0] eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9
[1] eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4iLCJpYXQiOjE3MDAwMDAwMDB9
[2] SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
الخطوة 2: فك ترميز Base64URL للقسم [0] (Header)
{
"alg": "HS256",
"typ": "JWT"
}
الخطوة 3: فك ترميز Base64URL للقسم [1] (Payload)
{
"sub": "1234567890",
"name": "John",
"iat": 1700000000
}
الخطوة 4: التحقق من القسم [2] (Signature) — يتطلب المفتاح السري
يأخذ المحلل الـ Header المرمّز بـ Base64URL + “.” + الـ Payload، ثم يحسب HMAC-SHA256 باستخدام السر. إذا طابق الناتج القسم [2]، يكون الرمز أصليًا.
ملاحظة أمنية حرجة: Base64URL ليس تشفيرًا
من الشّرَك الشائعة بين المطورين الجدد افتراض أن الـ Header والـ Payload المرمّزَين مشفّران. هذا غير صحيح. كما يشير JustUse.me، فإن ترميز Base64URL يجعل JSON آمنة للإرسال عبر الروابط والترويسات (headers) فقط. يمكن لأي شخص يحوز الرمز أن يفك ترميز الـ Payload دون كلمة مرور أو مفتاح.
لا تُخزِّن أبدًا بيانات حساسة (كلمات المرور، أرقام الضمان الاجتماعي، مفاتيح API) في الـ Payload الخاص بـ JWT. فهي مرئية لأي شخص يلتقط الرمز.
التحقق من التوقيع: بوابة الأمان
رغم أن أي شخص يستطيع قراءة بيانات الرمز، فإن التحقق من التوقيع هو ما يبقي نظامك آمنًا فعلًا. محلل JWT لا يقرأ المعلومات فحسب — بل يُثبت مصدرها.
يعيد المحلل حساب التوقيع باستخدام الـ Header والـ Payload ومفتاح، ثم يتحقق مما إذا كان الناتج يطابق التوقيع الموجود على الرمز. إذا لم يتطابقا، فهذا يعني أنه تم العبث بالرمز.
عائلتا الخوارزميات
| الخوارزمية | نوع المفتاح | آلية العمل | حالة الاستخدام الشائعة |
|---|---|---|---|
| HS256 (HMAC) | متماثل — نفس المفتاح السري للتوقيع والتحقق | يتشارك الطرفان سرًا واحدًا | مصادقة الخدمة الواحدة، الخدمات المصغّرة داخل فريق واحد |
| RS256 (RSA) | غير متماثل — المفتاح الخاص يوقّع، والمفتاح العام يتحقق | يحتفظ المُرسِل بالمفتاح الخاص؛ ويمكن لأي من يملك المفتاح العام التحقق | مزوّدو OAuth2، تكاملات API الخارجية |
| ES256 (ECDSA) | غير متماثل — نفس نموذج RSA لكن بمنحنيات إهليلجية | مفاتيح أصغر، تحقق أسرع | تطبيقات الجوال، الخدمات الحساسة للأداء |
هجوم “alg: none”
هذا أحد أخطر ثغرات JWT. يُعدّل المهاجم الـ Header ليدّعي وجود "alg": "none" ويزيل التوقيع. قد يقبل محلل ضعيف التنفيذ ذلك، معتبرًا الرمز صالحًا دون أي تحقق.
الدفاع: يجب أن يرفض محلّلك صراحةً أي رمز تكون الخوارزمية فيه “none” أو لا تطابق الخوارزمية المتوقعة لديك. يؤكد Stas Persiianenko، مطوّر أداة Apify JWT، أنه رغم شفافية الرموز بتصميمها، فإن أمانها يعتمد على رفض المحلل بصرامة للرموز غير الموقّعة أو المعبث بها.
decoded = jwt.decode(token, key, algorithms=None) # NEVER do this
decoded = jwt.decode(token, key, algorithms=["HS256"])
مطالبات JWT القياسية: ما يعنيه كل حقل
يستخرج محلل JWT “المطالبات” (claims) من الـ Payload. وتتبع هذه المطالبات إطار عمل JOSE (JSON Object Signing and Encryption) لضمان التوافق بين الأنظمة.
| المطالبة | الاسم الكامل | الغرض | قيمة المثال |
|---|---|---|---|
iss |
Issuer | من أصدر الرمز | "auth.example.com" |
sub |
Subject | المستخدم أو الكيان الذي يمثله الرمز | "user:12345" |
aud |
Audience | المستلِم المقصود للرمز | "api.example.com" |
exp |
Expiration Time | متى يصبح الرمز غير صالح | 1700000000 (طابع Unix الزمني) |
iat |
Issued At | متى تم إنشاء الرمز | 1699999999 |
nbf |
Not Before | الرمز غير صالح قبل هذا الوقت | 1699999999 |
jti |
JWT ID | مُعرّف فريد للرمز | "a1b2c3d4" |
عند استخدام التوقيعات غير المتماثلة، تشير المحللات غالبًا إلى JWK (JSON Web Key) — وهي بنية JSON تمثّل مفتاحًا عامًا. يجلب المحلل تلقائيًا الـ JWK الصحيح من نقطة نهاية البيانات الوصفية (metadata endpoint) لمُصدِر الرمز للتحقق منه.
التنفيذ: كود حقيقي لبيئة الإنتاج
PHP مع lcobucci/jwt
المعيار في منظومة PHP هو lcobucci/jwt. تُظهر بيانات Packagist أكثر من 322 مليون عملية تثبيت حتى أبريل 2026، مما يجعله الخيار الأمثل لمشاريع Laravel وSymfony.
use Lcobucci\JWT\Configuration;
use Lcobucci\JWT\Signer\Hmac\Sha256;
use Lcobucci\JWT\Signer\Key\InMemory;
$config = Configuration::forSymmetricSigner(
new Sha256(),
InMemory::plainText('your-secret-key')
);
// Parsing and validating a token
$token = $config->parser()->parse($jwtString);
// Verify constraints: expiration, issuer, etc.
$constraints = [
new \Lcobucci\JWT\Validation\Constraint\IssuedBy('auth.example.com'),
new \Lcobucci\JWT\Validation\Constraint\PermittedFor('api.example.com'),
new \Lcobucci\JWT\Validation\Constraint\SignedWith(
$config->signer(),
$config->signingKey()
),
];
$isValid = $config->validator()->validate($token, ...$constraints);
Hono (Edge/Serverless) مع Web Crypto
للتطبيقات الطرفية (edge) خفيفة الوزن، يوفّر Hono JWT Helper دالة decode() بسيطة مثالية لمنصّات الـ serverless حيث تريد بدايات باردة (cold starts) سريعة وأقل عدد من التبعيات.
import { jwt } from 'hono/jwt'
// Middleware to verify JWT on every request
app.use('/api/*', jwt({ secret: 'your-secret' }))
// Access decoded claims in your handler
app.get('/api/profile', (c) => {
const payload = c.get('jwtPayload')
return c.json({ user: payload.sub })
})
تحليل JWT مدفوع بالذكاء الاصطناعي عبر MCP
بحلول عام 2026، بات بروتوكول Model Context Protocol (MCP) يتيح للمساعدين الذكيين مثل Claude Code أو Cursor التحدّث مباشرةً إلى أدوات JWT. ما عليك سوى إعداد خادم MCP، فيستطيع المطور أن يطلب من الذكاء الاصطناعي: “تحقّق من جميع رموز JWT في هذه السجلات من أخطاء الانتهاء” — ويتولّى الوكيل (agent) التحليل عبر سطر الأوامر.
وفقًا لـ Apify، تبلغ تكلفة المعالجة المجمّعة نحو $11.50 لكل 10,000 رمز اعتبارًا من عام 2026. يتيح هذا الأتمتة لوكلاء الذكاء الاصطناعي العثور على الرموز المنتهية واقتراح إصلاحات برمجية فورية لإعدادات أمان التطبيق.
الخلاصة
محلل JWT ليس مجرد وسيلة تسهّل تصحيح الأخطاء — بل هو نقطة تفتيش أمنية حيوية. يضمن أن الرموز أصيلة عبر فحص التوقيع، وصالحة عبر التحقق من المطالبات. تذكّر القاعدتين الأهم: Base64URL ليس تشفيرًا، فلا تضع أسرارًا في الـ Payload. وتحديدًا دائمًا للخوارزميات المسموح بها صراحةً لمنع هجمات “alg: none”.
للتطبيقات في بيئة الإنتاج، استخدم مكتبات مثبتة مثل lcobucci/jwt أو مساعد Hono للـ JWT بدلًا من كتابة محلّلك الخاص. ولعمليات التصحيح والتحليل المجمّع، تمثّل أدوات MCP المدفوعة بالذكاء الاصطناعي النهج الحديث للحفاظ على تدقيق الأمان مؤتمتًا وشاملًا.
الأسئلة الشائعة
هل من القانوني فك تشفير رمز JWT وجدته في متصفحي؟
نعم، الأمر قانوني تمامًا. صُمّمت رموز JWT لتكون شفافة — فالـ Header والـ Payload مرمّزان لأغراض النقل، وليس مشفّرين للسرية. حيازتك للرمز تعني أنك تملك حق الوصول إلى البيانات في مطالباته. ومع ذلك، التزم دائمًا بقوانين حماية البيانات المحلية مثل GDPR عندما تحتوي الرموز على معلومات شخصية.
لماذا يُظهر محلّل JWT الخاص بي isExpired: true لرمز أنشأته للتو؟
يكون السبب عادةً انحراف الساعة (clock drift) بين الخادم الذي أنشأ الرمز والنظام الذي يحلّله. إذا لم تكن ساعات النظامين متزامنتين (عبر UTC/NTP)، فقد تبدو المطالبات exp أو nbf غير صالحة. أصلح ذلك بضمان استخدام كلا النظامين لـ NTP لمزامنة الوقت، أو بإضافة “هامش سماح” (leeway) صغير (عادة 60 seconds) في مكتبة التحليل لديك لاستيعاب الانحرافات الطفيفة.
هل يمكنني فك تشفير JWT دون امتلاك السر أو المفتاح العام؟
نعم، يمكنك دائمًا فك ترميز وقراءة الـ Header والـ Payload دون مفتاح لأنهما ببساطة JSON مرمّزة بـ Base64URL. لكنك لا تستطيع التحقق من التوقيع أو الوثوق بأن البيانات أصلية دون السر المطابق (لـ HS256) أو المفتاح العام (لـ RS256). دون تحقق، تعامل مع البيانات على أنها غير موثّقة وربما تم العبث بها.
ما هو هجوم “alg: none” وكيف أمنعه؟
يستغل هجوم “alg: none” المحللات التي تقبل الخوارزمية المحدّدة في ترويسة الرمز دون تحقق. يُغيّر المهاجم الـ Header إلى "alg": "none" ويزيل التوقيع، خادعًا محللًا معرّضًا للثغرة ليقبل الرمز كصالح. امنع ذلك بتحديد الخوارزميات المسموح بها صراحةً دائمًا في كود التحقق — لا تقبل أبدًا “none” ولا تسمح للرمز بتحديد الخوارزمية المطلوب استخدامها.
