TK TaskKit
أدوات المطورين

فك ترميز JWT

افكك ترميز JWT، افحص الـ claims، وتحقّق من انتهاء الصلاحية دون رفع الرمز.

Token
بعد فك الترميز

الصق JWT لفحص الـ header والـ payload والـ claims.

JWT بـ HS256 موقّع بالسر «taskkit-demo-secret» — بدّل لوضع التحقّق والصق السر لتجربه.

إدخالاتك تبقى على جهازك. كل أدوات المطورين في TaskKit تعمل في متصفحك. الرموز والـ payloads وما تلصقه لا يُرسل لخوادم TaskKit ولا لأي طرف ثالث.

نظرة عامة

هذه الأداة تأخذ أي JSON Web Token وتقسمه لأجزائه الثلاثة — header و payload و signature — وتعرض المحتوى بعد فك الترميز مع الـ claims المسجّلة (iss، sub، aud، exp، iat، nbf، jti). مدة الصلاحية تُحسب من exp و nbf لتعرف من نظرة واحدة هل الـ token ساري أم لا.

تدعم كذلك التحقّق من التوقيع بالخوارزميات التي تستخدمها APIs فعلاً: HS256/384/512 بسر مشترك، RS256/384/512 و PS256/384/512 بمفتاح RSA عام، ES256/384/512 بمفتاح EC عام، و EdDSA بمفتاح Ed25519. تقدر تلصق المفتاح العام كـ JWK، أو JWKS كاملة (TaskKit يلتقط المفتاح المناسب بمطابقة kid)، أو كتلة PEM SPKI، أو RSA PEM PKCS#1، أو شهادة X.509 (يُستخرج المفتاح العام تلقائياً)، أو — لـ EdDSA — 64 رمزاً ست عشرياً أو 43 رمزاً base64url. وإذا فيه x5c في الـ header (سلسلة شهادات X.509 مضمّنة)، تُستخدم شهادة الورقة تلقائياً حين يكون حقل المفتاح فارغاً.

متى تحتاجها

  • فحص token راجع من auth server المحلي وقت التطوير.
  • التأكد إن claims token من طرف ثالث تطابق اللي يتوقّعه عميلك.
  • التحقّق إن الـ token المُحدَّث موقّع بنفس المفتاح السابق.
  • فحص الـ expiry لمّا شيء يتعطّل بالضبط عند منتصف الليل UTC.

كيف تشتغل

فك الترميز ما هو إلا Base64URL — مواصفة JWT تستخدم Base64 الآمن للروابط مع تجريد الـ padding. الـ header والـ payload بصيغة JSON؛ التوقيع بايتات خام. التحقّق يستخدم crypto.subtle.verify، يعني WebCrypto المدمج في المتصفح، مع أخذ الخوارزمية من الـ header. EdDSA يمرّ على @noble/ed25519 لأن دعم Ed25519 في WebCrypto لسّه متفاوت بين المتصفحات.

إدخال المفتاح متساهل في الصيغ. مفاتيح HMAC تُستورد كبايتات خام أو JWK. ومفاتيح RSA و PS و ES تُقبل كـ JWK، JWKS (يختار kid المفتاح المناسب — والمجموعات ذات المفتاح الواحد تُستخدم مباشرةً)، PEM SPKI (BEGIN PUBLIC KEY)، PEM PKCS#1 RSA (BEGIN RSA PUBLIC KEY)، أو شهادة X.509 (BEGIN CERTIFICATE) — TaskKit يقرأ الشهادة بقارئ ASN.1 صغير مدمج لاستخراج SubjectPublicKeyInfo المضمّن. ومفاتيح EdDSA تكون JWK، JWKS، SPKI PEM، 64 رمزاً ست عشرياً، أو 43 رمزاً base64url.

ما في شيء يصير على الخادم. الـ token لا يغادر متصفحك، المفتاح لا يغادر متصفحك، وما في تتبّع لأيٍ منهما. لو لصقت token إنتاج لتصحيح خطأ، الـ auditor عندك ما راح يشوف أي طلب لـ taskkit.net يحمل هذا الـ token.

ملاحظات

ليش تُرفض «alg: none» حتى لمّا الـ token يبدو صالحاً؟ لأنه ما في JWT في الواقع يفترض يستخدم alg: none. هذه ثغرة معروفة: لو المتحقّق عندك يقبل none، المهاجم يقدر يجرّد التوقيع ويزوّر أي payload. لهذا نظهرها كخطأ بدل ما نمرّرها بصمت.

أقدر أتحقّق من token من Microsoft أو Google أو Auth0؟ أكيد — اجلب JWKS الخاصة بالـ issuer (مثلاً https://login.microsoftonline.com/common/discovery/v2.0/keys) والصق الوثيقة كاملة في حقل المفتاح. TaskKit يقرأ kid من الـ header ويلتقط الـ JWK المطابق تلقائياً؛ ما في حاجة لبحث يدوي.

HS256 أم RS256 — أيّهما أستخدم؟ RS256 (أو ES256) لأي شيء يتحقّق منه طرف خارجي، لأنه يحتاج المفتاح العام فقط. HS256 مناسب للتواصل بين الخدمات حين الطرفان عندهم نفس السر.

عندي token فيه x5c — هل أنا واثق بالشهادة المضمّنة فيه؟ TaskKit يستخدم شهادة الورقة من x5c للتحقّق من التوقيع لمّا ما تلصق مفتاحاً، عشان تتأكد إن محتوى الـ token ما تم العبث فيه. لكنه لا يتحقّق من السلسلة وصولاً للـ CA — هذا يحتاج جذور ثقة وهو خارج نطاق الأداة. شريط النتيجة يعرض «تم التحقّق بشهادة x5c من الـ header (السلسلة غير متحقَّق منها)» حتى لا تخلطها بحكم ثقة من البداية للنهاية.

أدوات ذات صلة