كيف تفك ترميز JWT وتفحص وقت انتهاء صلاحيته

يصل JSON Web Token المضغوط غالباً كسلسلة طويلة يصعب فحصها داخل سجل أو عميل API أو مساحة تخزين المتصفح. يحمل الجزءان الأولان ترويسة JSON ومجموعة مطالبات JSON مرمّزتين بصيغة Base64URL. يحول فك هذين الجزأين القيمة غير الواضحة إلى حقول يمكن قراءتها، مثل اسم الخوارزمية في الترويسة وموضوع الحساب والجمهور المستهدف ووقت الانتهاء في الحمولة. يفيد ذلك خصوصاً عندما تختلف الواجهة الأمامية وAPI حول ما إذا كان يجب أن تبقى الجلسة نشطة.

تبدو المطالبات الزمنية بسيطة حتى تختلط الوحدات والحدود. تحسب قيم NumericDate في JWT الثواني منذ 1970-01-01T00:00:00Z، بينما تستخدم الطوابع الزمنية في JavaScript المللي ثانية عادة. تحدد `exp` اللحظة التي يجب بعدها عدم قبول الرمز، وتحدد `nbf` أبكر وقت يمكن استخدامه فيه، وتسجل `iat` وقت الإصدار. تفصل أداة الفك الجيدة بين هذه المعاني، وتعرض الرقم الأصلي، وتقدم تاريخاً محلياً لتسهيل القراءة. كما يجب أن تعرض وقت الجهاز المستخدم في الفحص لأن الساعة غير الدقيقة قد تغير النتيجة قرب الحد الزمني.

أزل بادئة `Bearer` الاختيارية ثم اقسم القيمة المضغوطة عند النقاط. يتكون الإدخال المعتاد لهذه الأداة من ثلاثة أجزاء. تحقق من كل جزء غير فارغ وفق أبجدية Base64 الآمنة للرابط، وأعد فقط الحشو اللازم للفك، ثم اقرأ تسلسلي البايتات الأولين ككائني JSON صارمين بترميز UTF-8. يجب أن تحتوي الترويسة على قيمة نصية غير فارغة في `alg`. وفي الحمولة يجب أن تكون `iss` و`sub` و`jti` نصوصاً، ويمكن أن تكون `aud` نصاً أو مصفوفة نصوص، بينما يجب أن تكون `exp` و`nbf` و`iat` أرقام JSON منتهية. قارن الوقت الحالي مع `exp` و`nbf` بالثواني. يسمح RFC 7519 بمهلة بسيطة لاختلاف الساعة، لذلك طبّق المهلة المحدودة نفسها على جانبي الفترة. تعامل مع `iat` المستقبلية كتنبيه مفيد، لا كقاعدة مماثلة لـ`nbf`.

يعرّف RFC 7519 مجموعة مطالبات JWT والمطالبات المسجلة `iss` و`sub` و`aud` و`exp` و`nbf` و`iat` و`jti`. وتشترط قاعدة الانتهاء بقاء الوقت الحالي قبل exp، وتشترط قاعدة وقت البدء وصول الوقت الحالي إلى nbf، وتسمح القاعدتان بمهلة بسيطة لاختلاف الساعة. كما يعرّف NumericDate بالثواني منذ Unix epoch ويصف iat بأنها وقت الإصدار. ويعرّف RFC 4648 أبجدية Base64 الآمنة للرابط التي تستخدمها أجزاء JWT المضغوطة. تتبع الأداة قواعد الأنواع والوقت هذه، وتترك قرارات المطالبات الخاصة بكل تطبيق خارج النتيجة العامة.

افترض أن وقت الجهاز يساوي تماماً `1,800,000,000`، وأن الحمولة تحتوي على `iat: 1,799,999,400` و`nbf: 1,799,999,970` و`exp: 1,800,000,120`، وأن المهلة صفر. يقع الرمز داخل فترته المعلنة لأن الوقت الحالي بعد nbf وما زال قبل exp. عند `1,800,000,120` تتغير نتيجة الانتهاء إلى منتهي الصلاحية. وإذا كررت فحص الحد مع مهلة 60 ثانية، ينتقل وقت الانتهاء إلى `1,800,000,180`. هذا التأخير مهلة مقصودة، ولذلك يجب تسجيلها في تقرير الاختبار. استبدل `exp` الآن بالأرقام نفسها مخزنة كنص JSON. قد يبدو التاريخ قابلاً للفهم للبشر، لكن نوع JSON خاطئ ويجب الإبلاغ عن مطالبة الانتهاء كقيمة غير صالحة.

عند استخدام مهلة `L` بالثواني تكون قاعدة الانتهاء `منتهي عندما now >= exp + L`. وتكون قاعدة وقت البدء `لم يبدأ عندما now + L < nbf`. تتبع المهلة الصفرية حدود NumericDate الدقيقة. ويجب أن يكون الترتيب الداخلي منطقياً أيضاً؛ فالقيمة `exp < iat` تعني أن الانتهاء المسجل يسبق الإصدار، والقيمة `exp < nbf` تصف فترة تغلق قبل أن تبدأ. يختلف غياب `exp` عن وجود `exp` غير صالحة؛ ففي الحالة الأولى لا يوجد حد انتهاء يمكن فحصه، وفي الثانية توجد قيمة من النوع الخطأ. يجب أن تبقى هذه النتائج منفصلة في الحالة والتفاصيل.

تكون القيمة المكونة من خمسة أجزاء عادة JWE مشفرة ولا تستطيع هذه الأداة قراءتها من دون عملية فك التشفير المناسبة. ويجب أن تفشل القيمة ذات الجزأين أو النقاط الزائدة أو UTF-8 غير الصالح أو JSON غير الصالح أو المصفوفة عندما يكون الكائن مطلوباً أو خلط أحرف Base64 المعيارية مع Base64URL برسالة إدخال محددة. قد تتضمن NumericDate جزءاً من الثانية، وإن كان كثير من جهات الإصدار يستخدم أعداداً صحيحة. وقد تقع الأرقام المنتهية الكبيرة جداً خارج مجال عرض التاريخ في JavaScript، لذلك يجب إبقاء المطالبة الأصلية ظاهرة حتى إذا تعذر إنتاج تاريخ مقروء. لا يلغي غياب `exp` بقية المطالبات؛ تُفك الحمولة مع توضيح عدم وجود حد للانتهاء. أما جهة الإصدار والجمهور والموضوع والإلغاء وحالة الجلسة والحد الأقصى للعمر فتتبع قواعد التطبيق الذي يستهلك الرمز. تفيد قراءة هذه القيم، لكن أداة عامة في المتصفح لا تستطيع تقرير مطابقتها لإعداد API معين.

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

الصق القيمة المضغوطة في أداة فك ترميز JWT وفحص انتهاء الصلاحية من TOOLFINA. يمكنك إبقاء بادئة `Bearer` المنسوخة من حقل Authorization. اترك المهلة صفراً لفحص الحد الدقيق، أو أدخل قيمة بسيطة تطابق النظام الذي تختبره. اضغط فك الترميز وفحص الانتهاء. اقرأ بطاقة الانتهاء أولاً، ثم راجع JSON في الترويسة والحمولة وجدول المطالبات المسجلة وأي تنبيهات زمنية. لكل لوحة JSON زر نسخ مستقل، ويمكنك أيضاً من ترويسة النتيجة نسخ القسمين معاً أو تنزيلهما في ملف JSON واحد. تظهر الأرقام الثانوية في شريط الحالة أسفل الشيفرة. وسع مساحة العمل عندما تكون الحمولة طويلة.

المدخلات: رمز JWT مضغوط واحد أو قيمة Bearer ومهلة اختيارية من 0 إلى 300 ثانية. المخرجات: ترويسة وحمولة مفكوكتان ومنسقتان وبيانات الترويسة والقيم الدقيقة للمطالبات المسجلة والقيم الزمنية المقروءة وحالة الانتهاء وحالة وقت البدء وتنبيهات الإصدار المستقبلي وأخطاء أنواع المطالبات وتحذيرات الترتيب الزمني غير الممكن. تتم المعالجة داخل المتصفح الحالي. لا تجلب الأداة بيانات جهة إصدار ولا تتصل بـAPI ولا تفحص حالة جلسة الخادم ولا تطبق قواعد غير موثقة خاصة بالتطبيق.

يُفك رمز JWT ويُفحص محلياً داخل المتصفح ولا ترفعه TOOLFINA أو تخزنه أو تسجله. يزيل المتصفح بادئة Bearer الاختيارية ويتحقق من أجزاء الرمز كقيم Base64URL دون حشو ويفك كائني JSON بترميز UTF-8 ثم يقارن ثواني NumericDate بوقت الجهاز الحالي مع المهلة المحددة.