فك رموز JWT

أدخل أي رمز JWT وشاهد على الفور الترويسة والحمولة بعد فك تشفيرهما كملف JSON منسق.

أداة فك التشفير الخاصة بنا:

• تحدد خوارزمية التوقيع المستخدمة
• تعرض جميع المطالبات القياسية والمخصصة
• تسهل حساب الوقت عبر تحويل طوابع Unix الزمنية إلى تواريخ سهلة القراءة

يساعد العرض الملون في التمييز بسهولة بين أجزاء رمز JWT الثلاثة.

صحح أخطاء رموز JWT من خلال التحقق من أوقات انتهاء الصلاحية، وطوابع وقت الإصدار، وقيم المطالبات.

توضح أداتنا ما إذا كانت الرموز منتهية الصلاحية، وتتيح حساب عدد الساعات والدقائق المتبقية على انتهائها، وتسليط الضوء على المشكلات المحتملة. إذا كنت تتساءل كيف احسب ساعات العمل للجلسات النشطة، فإن أداتنا توفر لك ذلك.

أداة أساسية لـ:

• تطوير واجهات برمجة التطبيقات (APIs)
• تصحيح أخطاء المصادقة
• تدقيق الأمان الرقمي

إن رمز JSON Web Token (JWT) هو وسيلة مدمجة وآمنة للاستخدام في عناوين URL لتمثيل المطالبات المتبادلة بين طرفين، وهو محدد بموجب المعيار RFC 7519 الصادر عن IETF.

يتكون رمز JWT من ثلاثة أجزاء تفصل بينها نقاط، وكل جزء منها مشفر بترميز Base64URL وفقاً للمعيار RFC 4648:

• ترويسة (header) تصرح عن خوارزمية التوقيع ونوع الرمز باستخدام تنسيق JSON (RFC 8259)
• حمولة (payload) تحمل المطالبات — وهي عبارات حول كيان معين مثل المستخدم، بالإضافة إلى بيانات وصفية مثل تاريخ انتهاء الصلاحية
• توقيع (signature) يربط الترويسة بالحمولة معاً بحيث يمكن اكتشاف أي تلاعب بهما

تتيح هذه البنية للخدمات التحقق من الهوية دون الحاجة للرجوع إلى قاعدة البيانات، ولهذا السبب تشيع رموز JWT في عمليات المصادقة عديمة الحالة (stateless) وتدفقات بروتوكول OpenID Connect.

لفك تشفير رمز JWT، قم بتقسيم الرمز عند النقطتين إلى ثلاثة أقسام، ثم قم بفك تشفير القسمين الأولين باستخدام ترميز Base64URL.

يمنحك القسم الأول ترويسة JSON، بينما يمنحك القسم الثاني حمولة JSON، وكلاهما قابل للقراءة كنص عادي وفقاً للمعيار RFC 8259.

يستبدل ترميز Base64URL (المعيار RFC 4648، القسم 5) علامة '+' بـ '-' وعلامة '/' بـ '_' ويتجاهل الحشو (padding)، لذا قد يفشل برنامج فك تشفير Base64 القياسي دون تعديل. تتعامل أداتنا مع هذا تلقائياً وتعرض النتيجة بتنسيق سهل القراءة.

أما القسم الثالث، وهو التوقيع، فلا يتم فك تشفيره إلى نص لأنه قيمة تشفيرية خام.

وكما تشير وثائق MDN Web Docs، فإن فك التشفير لا يعني التحقق من الصحة — فقراءة الحمولة لا تؤكد أبداً أن الرمز موثوق ومصادق عليه.

لا — رمز JWT القياسي الموقع (JWS) هو رمز مُرمّز وليس مُشفّراً، لذا يمكن لأي شخص يمتلك الرمز قراءة حمولته.

ترميز Base64URL (المعيار RFC 4648) هو عملية عكسية ولا توفر أي سرية؛ بل تجعل النقل الآمن للبيانات الثنائية ممكناً فقط. يحمي التوقيع الموضح في RFC 7515 (توقيع JSON Web) السلامة والموثوقية، وليس السرية.

إذا كنت بحاجة إلى إخفاء المحتويات، فاستخدم JWE (تشفير JSON Web، المعيار RFC 7516) بدلاً من ذلك.

يؤكد كل من OWASP و IETF على هذا الاختلاف: لا تضع أبداً كلمات المرور أو أسرار واجهة برمجة التطبيقات (API) أو البيانات الشخصية المحددة للهوية في حمولة JWT الموقعة، لأن أداة فك التشفير هذه تكشف كل مطالبة بنص واضح دون الحاجة لأي مفتاح. تماماً كما تستخدم الحاسبة العلمية لحساب المعادلات بدقة، يجب استخدام الأدوات المناسبة لحماية بياناتك، وتجنب الاعتماد على الترميز لحفظ السرية.

تخضع مطالبات JWT المسجلة لمعايير موحدة بموجب المعيار RFC 7519 لضمان تفسيرها بشكل متسق عبر الأنظمة المختلفة.

وتشمل المجموعة الأساسية ما يلي:

• 'iss' (الجهة المصدرة)
• 'sub' (الموضوع، وهو صاحب الرمز الأساسي)
• 'aud' (الجمهور المستهدف بالرمز)
• 'exp' (وقت انتهاء الصلاحية)
• 'nbf' (ليس قبل)
• 'iat' (وقت الإصدار)
• 'jti' (معرف فريد للرمز)

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

وفقاً للمواصفات، يجب على أدوات التحقق رفض أي رمز انتهت صلاحيته 'exp' أو لا يتطابق جمهوره المستهدف 'aud' مع الجمهور المتوقع، مما يمنع إساءة الاستخدام عبر الخدمات المختلفة.

يتم تعريف خوارزميات توقيع JWT في المعيار RFC 7518 (خوارزميات JSON Web) ويتم تحديدها من خلال قيمة 'alg' في الترويسة.

• خوارزميات HMAC (مثل HS256 و HS384 و HS512) تستخدم سراً مشتركاً واحداً للتوقيع والتحقق على حد سواء، وهو أمر بسيط ولكنه يتطلب من كل جهة تحقق الاحتفاظ بهذا السر.
• خوارزميات RSA (مثل RS256 و RS384 و RS512) و RSASSA-PSS (مثل PS256) تستخدم مفتاحاً خاصاً للتوقيع ومفتاحاً عاماً للتحقق، وهو أمر مثالي للأنظمة الموزعة وبروتوكول OpenID Connect.
• خوارزميات ECDSA (مثل ES256 و ES384 و ES512) توفر أماناً مكافئاً بمفاتيح وتواقيع أصغر حجماً.

ينشر المعهد الوطني للمعايير والتقنية (NIST) معايير SHA-2 و ECDSA الأساسية. تقرأ أداة فك التشفير الخاصة بنا حقل 'alg' حتى تتمكن من تأكيد المخطط الذي يستخدمه الرمز.

تُستخدم رموز JWT على نطاق واسع في المصادقة عديمة الحالة (stateless)، والتفويض، والتبادل الآمن للمعلومات في واجهات برمجة التطبيقات الحديثة.

بعد تسجيل دخول المستخدم، يصدر الخادم رمز JWT موقعًا يعيده العميل في ترويسة تفويض HTTP كـ رمز حامل (Bearer token)، وفقًا للمعيار RFC 6750. ونظرًا لأن التوقيع قائم بذاته، يمكن لخدمات الخلفية التحقق من الرمز دون الاستعلام عن مخزن الجلسات، مما يحسن قابليتها للتوسع.

كما تدعم رموز JWT رموز الهوية الخاصة بـ OpenID Connect وأنماط رموز الوصول في OAuth 2.0.

يستخدم المطورون أدوات فك التشفير أثناء تصحيح الأخطاء لفحص المطالبات (claims)، وتأكيد قيم الجمهور والجهة المصدرة، والتحقق من انتهاء الصلاحية (بشكل يشبه أن تقول لنظامك احسب ساعات العمل النشطة للرمز، أو إجراء حساب الوقت المتبقي عبر عد تنازلي لصلاحية الرمز مع حساب عدد الساعات والدقائق بدقة) عندما ترجع واجهة البرمجة أخطاء 401. وكما تصف وثائق MDN Web Docs، فإن هذا التدفق القائم على الرموز يدعم العديد من بنيات تسجيل الدخول الموحد والخدمات المصغرة.

يرتكز الاستخدام الآمن لرموز JWT على التحقق من صحة الخوارزمية، والتحقق من التوقيع، وفرض وقت انتهاء الصلاحية.

تحذر منظمة OWASP من هجوم 'alg: none' الكلاسيكي وهجمات خلط الخوارزميات، حيث يمكن تزوير الرمز إذا خُدع الخادم ليتعامل مع المفتاح العام RS256 كسر HMAC؛ لذا يجب دائمًا تحديد الخوارزمية المتوقعة بدلاً من الوثوق بالترويسة.

الممارسات الأساسية:

• استخدام فترات صلاحية 'exp' قصيرة مع رموز التحديث، مع الاعتماد على حساب الوقت بالدقائق لضبط فترات الصلاحية بدقة، والتحقق من 'iss' و'aud' مع كل طلب.
• عدم تخزين الأسرار أبدًا في الحمولة (payload)، لأنها مشفرة بترميز Base64 فقط.
• نقل الرموز حصريًا عبر بروتوكول HTTPS، والنظر في استراتيجيات الإلغاء لأن رموز JWT القياسية لا يمكن إبطالها بشكل فردي قبل انتهاء صلاحيتها.

إن اتباع توصيات IETF وOWASP هذه يسد الثغرات الأكثر استغلالاً في رموز JWT.

تشمل الأخطاء الأكثر شيوعًا عند العمل مع رموز JWT ما يلي:

• الخلط بين فك التشفير والتحقق: قراءة الحمولة باستخدام أداة فك التشفير لا يثبت شيئًا عن صحتها، حيث يمكن لأي شخص إنشاء رمز غير موقع أو مزور.
• الوثوق الأعمى بقيمة 'alg' في الترويسة، مما يتيح هجمات خلط الخوارزميات التي حذرت منها OWASP.
• الخطأ في حساب الساعات لانتهاء الصلاحية من خلال مقارنة ثواني العصر 'exp' بالملي ثانية (بدلًا من إجراء حساب عدد الساعات بشكل صحيح)، مما يجعل الرموز الصالحة تبدو منتهية الصلاحية.
• استخدام مفكك ترميز Base64 القياسي بدلاً من Base64URL (RFC 4648)، مما قد يؤدي إلى تلف المخرجات بسبب اختلاف الأبجدية وغياب الحشو (padding).
• وضع بيانات حساسة في الحمولة، مما يؤدي إلى تسريبها، لأن الرمز مرمز وليس مشفرًا.

إن التحقق من التواقيع من جهة الخادم باستخدام المفتاح والخوارزمية المتوقعة يتجنب هذه الأخطاء الشائعة.

يعالج برنامج فك تشفير JWT هذا الرموز بالكامل من جانب العميل، وبالتالي لا يغادر رمزك جهازك أبدًا ولا يصل إلى أي خادم.

ونظرًا لأن رمز JWT الموقع يتم ترميزه فقط باستخدام Base64URL (RFC 4648)، فإن فك التشفير لا يتطلب أي اتصال بالشبكة - تمامًا مثل عمل حاسبة الوقت أو الحاسبة العلمية المحلية، حيث يتم ببساطة عكس الترويسة والحمولة من شكلهما المرمز باستخدام لغة JavaScript في متصفحك.

إن الحفاظ على محلية العملية أمر بالغ الأهمية للأمان: فغالباً ما تحتوي الرموز على بيانات اعتماد جلسة نشطة، ولصقها في أداة تعمل من جهة الخادم قد يعرضها للكشف في السجلات أو أثناء النقل. توصي OWASP بتقليل الأماكن التي تنتقل إليها بيانات الاعتماد الحساسة.

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