لا تحب الإعلانات؟ يذهب خالية من الإعلانات اليوم 

مُنشئ / مُشفّر JWT

مطورحماية

إعلان · حذف؟

مدخل

عملية تلقائية

انتاج

جانب العميل

إعلان · حذف؟

مرشد

مُنشئ / مُشفّر JWT

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

كيفية استخدام

تعديل العنوان (JSON) الحقل لتشمل typ وأي حقول مخصصة مثل kid. القيمة alg مُستَبدَلة من خلال مُختَار الخوارزمية أدناه.
تعديل محتوى (JSON) الحقل مع بيانات معيارية مثل iss, sub, iat, exp، بالإضافة إلى أي بيانات مخصصة تحتاجها خدمةك.
اختر خوارزمية: HS256, HS384، أو HS512.
ألصق السر المُشاركاستخدم سلسلة عشوائية على الأقل تساوي طول المخرج المُستخدم لتناسب مستوى الأمان لكل خوارزمية.
انسخ التوقيع الناتج من مربع الناتج، أو انسخ أجزاء العنوان أو المحتوى أو التوقيع بشكل منفصل.

خصائص

ثلاث خوارزميات HMAC – HS256، HS384، وHS512 تغطي كل حالة استخدام شائعة لتوقيع JWT باستخدام HMAC.
توقيع فوري – يتم توليد التوقيع تلقائيًا عند تعديل أي حقل، لذا ترى تأثير كل تغيير فورًا.
التحقق من صحة JSON في الوقت الفعلي – تظهر رسالة خطأ واضحة عند وجود بيانات غير صحيحة في العنوان أو المحتوى قبل أن يصبح التوقيع مُتضررًا.
نسخ جزئي – يمكنك نسخ التوقيع الكامل أو استخلاص العنوان أو المحتوى أو التوقيع بتنسيق base64url بشكل منفصل.
من جانب العميل فقط – يتم تنفيذ التوقيع داخل المتصفح باستخدام واجهة برمجة SubtleCrypto. لا تُرسل أسرار أو بيانات التوقيع إلى خادم.
مُزَوَّد مع أداة تحليل JWT – تُستخدم توكينات مُعاد توليد بين مُعدّ التوقيع وأداة تحليل JWT الموجودة لدينا لتأكيد البيانات.

متى تستخدم هذه الأداة

اختبار نقطة واجهة برمجة تُتوقع فيها توكين بيرر مع بيانات محددة.
إعادة إنتاج حالة فشل التحقق من الهوية باستخدام توكين معروف.
تعليم أو تعلُّم كيفية بناء توقيعات JWT.
إنشاء توكينات مؤقتة للتطوير المحلي دون الحاجة إلى تطبيق تحقق من الهوية.

 التعليمات

ما هو JWT وما السبب وراء توقيعه؟

يُعد التوقيع المبني على JSON (JWT) سلسلة مختصرة وآمنة للإستخدام في المواقع، تتكوّن من عنوان، محتوى، وتوقيع. يسمح التوقيع للطرف المُستقبل بتأكيد أن العنوان والمحتوى تم إنتاجهما باستخدام سر مُشارك، ولم يُعدل أثناء النقل. بدون توقيع صالح، يمكن لأي شخص تزييف البيانات، ولذلك يتم توقيع كل توكين مُستخدم في التحقق من الهوية أو التصريح.
كيف يعمل التوقيع باستخدام HMAC مع HS256، HS384، وHS512؟

يُدمج التوقيع المبني على الهاش (HMAC) بين مفتاح سر ودالة هاش. يستخدم HS256 دالة SHA-256 لإنتاج مفتاح مُعتمد بطول 256 بت، ويستخدم HS384 دالة SHA-384، ويستخدم HS512 دالة SHA-512. يُحسب التوقيع HMAC على العنوان والبيانات المُختصرة المُجمعة بـ نقطة، ثم يُضاف التوقيع المُختصر بتنسيق base64url. يمكن لأي شخص يملك نفس المفتاح إعادة حساب التوقيع ومقارنته للتحقق من صلاحيته.
لماذا تستخدم JWT base64url بدلًا من base64 المعياري؟

تستخدم base64 المعياري الرموز + و/ و= التي يجب تشفيرها بـ % عند استخدامها في عناوين URL، وقد تؤدي إلى مشاكل عند نقل التوقيع كمُدخلات في عناوين URL أو في عناوين HTTP. يُستبدل + بـ - و/ بـ _ ويُزال التعبئة النهائية =. ينتج هذا سلسلة آمنة للإستخدام مباشرة في عناوين URL، عناوين HTTP، وملفات التخزين دون الحاجة إلى تشفير إضافي.
ما الذي يجعل السر كافيًا لاستخدامه في التوقيعات المبنية على HMAC؟

لـ HS256 يجب أن يكون السر على الأقل 32 بيت عشوائي (256 بت)؛ ولـ HS384 على الأقل 48 بيت؛ ولـ HS512 على الأقل 64 بيت. تكون كلمات السر المختارة من قبل الإنسان ضعيفة أمام هجمات التكرار لأن المهاجم الذي يُستلم توكين واحد يمكنه تخمين السر خارج النظام. يجب إنشاء السر من مصدر عشوائي مُعتمد، وتخزينه خارج شجرة المصدر، وتحديثه عند أي احتمال للاختراق.